DIDcomm service-endpoint in example DID Docs

[c2bo]

This is kind of related to #46: When looking through the example in Aries RFC 0067, I got a bit confused where the second context (identity.foundation/didcomm-messaging/service-endpoint) in the example DID Docs is coming from:

"diddocContent" : {
  "@context" : [
      "https://www.w3.org/ns/did/v1",
      "https://identity.foundation/didcomm-messaging/service-endpoint/v1"
      ...
  ]

The examples in the linked aries RFC do not use that context. The only other example of a context for the didcomm service I found was in did-spec-registries.

The DIDcommv2 spec adds an additional (optional) attribute called accept that is also used in Aries RFC 0067 used to signal protocol version support: https://identity.foundation/didcomm-messaging/spec/#did-document-service-endpoint. This attribute was also in the initial iteration of the Sovrin DID Method and I guess the additional context comes from there?

Example service entry in Aries RFC 0067:

{
  "service": [{
    "id": "did:example:123456789abcdefghi#did-communication",
    "type": "did-communication",
    "priority" : 0,
    "recipientKeys" : [ "did:example:123456789abcdefghi#1" ],
    "routingKeys" : [ "did:example:123456789abcdefghi#1" ],
    "accept": [
      "didcomm/aip2;env=rfc587",
      "didcomm/aip2;env=rfc19"
    ],
    "serviceEndpoint": "https://agent.example.com/"
  }]
}

There also seems to be some discussion on the usage of "accept" within a service description: https://github.com/decentralized-identity/didcomm-messaging/issues/294.

I think it would be best to find a common understanding how to signal protocol support in a DIDcomm endpoint via didcommv2 spec and Aries RFC 0067 and leave things out of did:indy for the time being (no context and no accept in the examples).

[domwoe]

It's definitely confusing :)

I'd agree that we should at least remove the context from the ATTRIB example 10.1.5. Since, as far as I understand the spec, we'll produce a JSON DID document if there's no diddocContent with a @context present.

In order to produce valid JSON-LD, there should be a context that defines the terms and the type of the service, but I haven't seen any resolvable context so far.

Btw, there's a similar issue with the base verificationMethod. Type Ed25519VerificationKey2018 and property publicKeyBase58 are not defined in the DID core context, and we'd need to add https://w3id.org/security/v1 to produce a proper JSON-LD document.

[paulbastian]

Yes, since writing the did:indy spec the publicKeyBase58 is already deprecated again :)

[c2bo]

The proposed alterntive publicKeyMultibase seems to be not fianlized yet: https://datatracker.ietf.org/doc/draft-multiformats-multibase/

[swcurran]

@TelegramSam have these issue been resolved in the DIDComm WG at DIF? I thought the context at DIF had been created and was resolvable, but the URL above (https://identity.foundation/didcomm-messaging/service-endpoint/v1) 404s.

[c2bo]

I will create a PR draft so we can discuss what our DID Doc examples should look like. My current approach would be to start with w3c did-core and try to create a valid json-ld (resolvable) with minimal information for the time being (while the specs are still moving).

[brianorwhatever]

I believe this is the correct context url is https://didcomm.org/messaging/contexts/v2

[c2bo]

That would be for didcommv2, we need a context for didcommv1 according to https://github.com/hyperledger/aries-rfcs/blob/main/features/0067-didcomm-diddoc-conventions/README.md (type did-communication instead of DIDCommMessaging)

[brianorwhatever]

ah yes sorry ignore me