Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 0434: Ambiguous description of Peer DID numalgo 2 service encoding #728

Open
jakubkoci opened this issue Apr 6, 2022 · 2 comments
Open

Comments

@jakubkoci
Copy link
Contributor

jakubkoci commented Apr 6, 2022

There is the following statement in the OOB spec:

by encoding the key and endpoint of the service block in a Peer DID numalgo 2 and using that DID instead of a service block

I'm not sure what is supposed to be the key? Is it a recipient key? What if the recipientKeys array contains more keys?

Also, does it mean that we should take just serviceEndpoint from the service block? Let's say this is the service block from OOB invitation:

{
  "id": "#inline",
  "type": "did-communication",
  "recipientKeys": ["did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"],
  "routingKeys": [],
  "serviceEndpoint": "https://example.com:5000"
}

Then CORRECT inputs into Peer DID encoding numalgo2 will be the following:

  • "each public key to be included": did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
  • "JSON structure for your service":
{
  "serviceEndpoint": "https://example.com:5000",
}

The service MUST NOT contain other attributes, right? This is an example of INCORRECT service, because it does not contain only serviceEndpoint:

  • "JSON structure for your service":
{
  "type": "did-communication",
  "routingKeys": [],
  "serviceEndpoint": "https://example.com:5000"
}
@TelegramSam
Copy link
Contributor

Also, does it mean that we should take just serviceEndpoint from the service block?

No. It means everything relevant from the service block, not just the serviceEndpoint.

The service MUST NOT contain other attributes, right?

No. Not sure where this came from.

The key portion is as specified in your example: did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH

That key must be a keyAgreement key. Other keys may be present as allowed in did:peer numalgo 2, but there must be at least one keyAgreement key.

Your service block (prior to numalgo 2 encoding) could be:

{
  "type": "did-communication",
  "serviceEndpoint": "https://example.com:5000"
}

The routingKeys array was not needed as it was empty.

I reviewed the instructions in the did:peer spec and found them to be clear. What suggestions do you have for updates to either that spec or the OOB RFC to clarify?

@TimoGlastra
Copy link
Member

Thanks for answering @TelegramSam. What’s still unclear to me is how to go from key to keyAgreement. If you’re using the did:key from the example above it includes both a ed25519 and x25519 key. Should we add the ed25519 key to the keyAgreement array (can’t use ed25519 for keyAgreement, only x25519)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants