DIDComm V2 service type, format and context not aligned to spec
Opened this issue · 1 comments
In Resolver DID Document Format section of the specification, it refers to DIDComm V2 endpoint entries in endpoint ATTRIB as those whose type is DIDComm
, and also states to render a service object in the resulting DID Document using that type.
However, according to DIDComm Messaging v2.0 specification, service endpoint type must be DIDCommMessaging
. This would prevent DIDComm V2 Agents to properly DIDComm V2 messaging services in a DID Document resolved by a did:sov resolver following this spec.
Another inconsistency between this spec and DIDComm Messaging v2.x is the service block mentioned as example:
{
"id": "did:sov:HR6vs6GEZ8rHaVgjg2WodM#didcomm-1",
"type": "DIDComm",
"serviceEndpoint": "https://example.com/endpoint",
"accept": [
"didcomm/v2"
],
"routingKeys": []
}
Is not compliant, as serviceEndpoint should be a list of objects. So the resulting service block should be:
{
"id": "did:sov:HR6vs6GEZ8rHaVgjg2WodM#didcomm-1",
"type": "DIDCommMessaging",
"serviceEndpoint": [{
"uri": "https://example.com/endpoint",
"accept": [
"didcomm/v2"
],
"routingKeys": []
}]
}
Finally, related to this is that the spec states that https://didcomm.org/messaging/contexts/v2
must be added to @context
array and it is currently returning 404. That's maybe an issue on didcomm.org side (decentralized-identity/didcomm.org#70).
To make things even more confusing, this would be the current Aries convention regarding service endpoint: https://github.com/hyperledger/aries-rfcs/tree/main/features/0067-didcomm-diddoc-conventions#service-conventions
{
"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/"
}