You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Requester - the entity sending the DIDComm request from Snap
Receiver - the entity receiving the DIDComm request in Snap and responding
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.:
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.
The text was updated successfully, but these errors were encountered:
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?
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
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.:This would require the
site
orbackend
package to act as a mediator to forward the encapsulated DIDComm message to the user session and by extension the snap.The text was updated successfully, but these errors were encountered: