search

hyperledger / aries-rfcs

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions
https://hyperledger.github.io/aries-rfcs/
Apache License 2.0
326 stars 217 forks source link

Offering, selecting, and/or changing the envelope protocol version #478

Open swcurran opened 4 years ago

swcurran commented 4 years ago

The aries-framework-go team (@Baha-sk and @llorllale) has been working on the implementation of a new encryption envelope format RFC 0334, as has the DIDComm group at DIF. While it would be best if those efforts merge, it raises a separate question:

How will the community enable collaboratively evolving the encryption envelope version to use for connections?

Just as the OOB invitation makes it possible for agents to offer new versions of a connection establishment protocol, we will need a way for agents to offer and select the envelope protocol to use for a new connection, as well as a way to propose and accept a change to the envelope protocol in use for a long lasting connection.

Should we extend the OOB now to enable that? Do we need to think about adding a connection management protocol along the lines of the proposed sync-connection protocol (RFC 0030) but extended to cover this requirement? Note that while 0030 is focused on peer:dids, this aspect of connection management needs to cover other than did:peer DID methods.

llorllale commented 4 years ago

@swcurran I agree with declaring the supported envelope versions in OOB.

Do we need to think about adding a connection management protocol along the lines of the proposed sync-connection protocol (RFC 0030) but extended to cover this requirement?

You mean transition existing connections from one envelope version to the other? Maybe phase 1) receiver responds with a problem_report with the old envelope format, then phase 2) remove support for old format completely. Obviously requires community coordination.

TimoGlastra commented 2 years ago

I think part 1 (we will need a way for agents to offer and select the envelope protocol to use for a new connection) has been solved but part 2 (Do we need to think about adding a connection management protocol along the lines of the proposed sync-connection protocol (RFC 0030) but extended to cover this requirement?) is still to be resolved.

I think we'll be able to solve 2. in DIDComm v2 without need for additional protocols. For non peer dids you can add a new service item to the did document indicating you support didcomm v2 envelopes. For peer dids you can add a signed patch on the did to update the services entry. This would allow to first add the didcomm v2 service, allowing the other agent to update to the didcomm v2 endpoint, while later removing the didcomm v1 endpoint.

Is this something we can mark as won't fix for DIDComm v1?

swcurran commented 2 years ago

Could you clarify what won't be fixed -- what you mean by "this"? I think you are saying we will not add a way to remove the DIDComm v1 envelope from a DID. Is that right? Or something more?