Open c2bo opened 2 years ago
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.
Yes, since writing the did:indy spec the publicKeyBase58
is already deprecated again :)
The proposed alterntive publicKeyMultibase
seems to be not fianlized yet: https://datatracker.ietf.org/doc/draft-multiformats-multibase/
@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.
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).
I believe this is the correct context url is https://didcomm.org/messaging/contexts/v2
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
)
ah yes sorry ignore me
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:
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:
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).