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

[jakubkoci]

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]

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]

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)?