Any plans to leverage DIDComm v2 Routing Protocol?

[pauldesmondparker]

[!Note] Thank you for this great repository. We were still fixing integration problems between the Hedera SDK and SES when we found your work.

Preamble/Purpose

Identify should have a means of sending and receiving DIDComm messages. This would allow two entities (metamask wallets) accessing identify (not necessarily the same web instance i.e. at different FQDN), to share VCs and VPs with each other through DIDComm.

This could then be extended to Encrypted Data Vault (EDV) DIDComm messages as well.

Reference

Routing Protocol

Problem

[!Note]

1. Requester - the entity sending the DIDComm request from Snap
2. Receiver - the entity receiving the DIDComm request in Snap and responding
3. Mediator - an entity trusted to receive DIDComm messages from the original DIDComm message Receiver and relay them to the original Requester, likely to be the hosted web site.

The Snap context is capable of sending DIDComm messages with ease. However, the channel is by DIF standard, simplex, which means that a reply cannot be expected directly from the requested party. The DIDDoc of the requester is consulted by the receiver, and the service endpoint read and a DIDComm response prepared and sent to it.

In the context of a Snap, there is no standard URL that resolves to the Snap (that I am aware of).

Proposed Solution

The DIF DIDComm Messaging specification v2 allows messages to be relayed through a mediator. This could mean that the Metamask wallet could create a DIDDoc that contains a serviceEndpoint, i.e.:

    "serviceEndpoint": {
        "uri": "mm-snap://some-user-key",
        "accept": [
            "didcomm/v2",
            "didcomm/aip2;env=rfc587"
        ],
        "routingKeys": ["did:example:site-mediator#some-user-key"]
    }

This would require the site or backend package to act as a mediator to forward the encapsulated DIDComm message to the user session and by extension the snap.

[kpachhai]

Sorry it took this long to respond.

Firstly, thank you for the kind words about the repository.

Secondly, we have looked at DIDComm in the past and did have plans to integrate it onto the Identify snap however, with the amount of resources we had and the release schedule for the snap(before the Metamask Snap open beta), it just wasn't a viable option. I do like your proposed solution and I think could work. One thing to mention is that the site and backend packages are just there to serve as examples on how one could integrate the Identify Snap onto a webapp and how one could integrate DID capabilities using Veramo on the backend. They are not really directly related to the main snap package.

With that said, we would be more than happy to talk more about this further if you are interested. Or even better, if you have any code that you could submit as part of a PR, we can discuss there?

[pauldesmondparker]

@kpachhai Veramo was a good steer, they already implement: https://didcomm.org/coordinate-mediation/2.0/ and https://didcomm.org/messagepickup/2.0/

at https://github.com/uport-project/veramo/tree/next/packages/did-comm/src/protocols

Mediator Coordination implements:

mediate-request
mediate-grant
mediate-deny

but doesn't implement the following:

recipient-update
recipient-update-response
recipient-query
recipient

So this looks like a good place for us to contribute to get this into Veramo.