Unqualified DID Community Coordinated Update #793
Conversation
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
| ## Summary | ||
|
|
||
| Historically, Aries use of the Indy SDK's wallet included the use of 'unqualified DIDs' or DIDs without a did: prefix and method. | ||
| This transition documents the process of migrating any such DIDs still in use to fully qualified DIDs. |
There was a problem hiding this comment.
This should reference both public and peer DIDs, since there are examples of both in Aries. Unqualified public DIDs are (presumably) transitioned to be “did:sov” DIDs.
| Historically, Aries use of the Indy SDK's wallet included the use of 'unqualified DIDs' or DIDs without a did: prefix and method. | ||
| This transition documents the process of migrating any such DIDs still in use to fully qualified DIDs. | ||
|
|
||
| The transition from unqualified DIDs to peer:did:2 is described here: https://github.com/TimoGlastra/legacy-did-transformation |
There was a problem hiding this comment.
I think there are a couple of open issues on this, and the README itself has open questions. What about merging that into this document as an appendix, instead of in a Timo’s account?
|
To complete this, we need to get an idea of the dates that the major libraries -- Aries Cloud Agent Python, Aries Framework JavaScript (@TimoGlastra , @berendsliedrecht, et al. ), Aries VCX (@Patrik-Stas, et. al. ) and Aries Framework Go (@troyronda ?) are willing to get this into their Aries implementation and promoted amongst their deployers. Definitely interested in their feedback. Each implementation needs to do a single implementation for steps 2 and 3:
Once that handling is in place, any deployment using that code can accomplish step 2 and can transition to step 3 by changing a configuration flag. Do the various Aries implementations have a target date for completing the work on this? |
|
Wait!! ** blu3beri** has disappeared??? What? |
| - Verify transisiton plan and code. | ||
| - **Step 1**: Agent builders MUST update all agent code bases and deployments to accept DIDs in the old (unqualified) and new (transitioned) forms. During this step, agents MUST continue the use of unqualified DIDs in all cases where they are currently being used. | ||
| - Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the [implementations](#implementations) accordingly. | ||
| - **Step 2**: Agent builders MUST update all agent code bases and deployments to use only fully qualified DIDs in all communication. Unqualified DIDs received are matched by the receiving agent to the associated fully qualified DID. |
There was a problem hiding this comment.
How will this work for legacy protocols? I'm thinking whether we should even update those. Rather provide a way for connections created using the legacy protocol to uograde their dids to a qualified format
There was a problem hiding this comment.
Not sure what you mean. Do you mean specifically RFC 0160 Connection as the legacy protocol for establishing connections (should we update or drop that protocol), or something else?
There was a problem hiding this comment.
I think under certain situations it could be a bit contradictory to use fully qualified DIDs in all communication and still support the reception of unqualified DID. If the first message of a protocol includes an unqualified DID, are we going to reply producing fully qualified DIDs even if it is likely that the other agent won't support it? (currently this is what happens when using DID Exchange between ACA-Py and AFJ, where the latter is sending a Request using a method 1 did:peer that will be rejected by ACA-Py due to the usage of an unsupported qualified DID).
May it make sense to leave RFC 0160 using unqualified DIDs and marking it as "deprecated" at this step, entirely dropping it in Step 3?
| - Verify transisiton plan and code. | ||
| - **Step 1**: Agent builders MUST update all agent code bases and deployments to accept DIDs in the old (unqualified) and new (transitioned) forms. During this step, agents MUST continue the use of unqualified DIDs in all cases where they are currently being used. | ||
| - Each agent builder SHOULD notify the community they have completed Step 1 by submitting a PR to update their entry in the [implementations](#implementations) accordingly. | ||
| - **Step 2**: Agent builders MUST update all agent code bases and deployments to use only fully qualified DIDs in all communication. Unqualified DIDs received are matched by the receiving agent to the associated fully qualified DID. |
There was a problem hiding this comment.
I think under certain situations it could be a bit contradictory to use fully qualified DIDs in all communication and still support the reception of unqualified DID. If the first message of a protocol includes an unqualified DID, are we going to reply producing fully qualified DIDs even if it is likely that the other agent won't support it? (currently this is what happens when using DID Exchange between ACA-Py and AFJ, where the latter is sending a Request using a method 1 did:peer that will be rejected by ACA-Py due to the usage of an unsupported qualified DID).
May it make sense to leave RFC 0160 using unqualified DIDs and marking it as "deprecated" at this step, entirely dropping it in Step 3?
| The transition from the unqualified to qualified DIDs will occur in four steps: | ||
|
|
||
| - **Pre-work**: where we agree on the transition plan outlined in this RFC. | ||
| - Finalize did:peer:3 details, including feature discovery support of did:peer:3. |
There was a problem hiding this comment.
The 'feature discovery' part seems quite important to me but couldn't find further explanations about how it should be achieved, since DIDs are used from the start on connection protocols. And we have to consider that not only did:peer:3 support must be discovered but also did:peer:2 (and did:peer in general I would say), as AFAIK not every framework out there supports it at the moment.
Can be discovered by using an extra field on Out of Band invitation messages (or an existing one like accept)?
Could it be done using a recursive strategy where the Agent first tries to send a DID Exchange Request using a did:peer:2 and:
- If connection is successfully established, use Discover Features protocol to ask for did:peer:3 support (a
feature-typemust be created for that purpose) and both parties will use did:peer:3 if so - If the request is rejected (Problem Report sent with
request_not_accepted) try again using a did:peer:1 (and eventually unqualified DID if the error persists)
Could be done by sending did:peer:3 right from the start (passing also the entire DIDDoc) and if the request is accepted simply use did:peer:3 from then (and if not follow the recursive strategy falling back to other DID methods?)
There was a problem hiding this comment.
Just a few more questions after today's Aries WG call: using Discover Features V2 feature-type to discover did:peer:3 variant support seems quite straightforward in existing connections but It's still not clear to me how to handle the Aries community transition cases for establishing new DIDComm relationships in some situations:
- OOB invitation messages that contain a public DID, or direct interactions to a public DID (in DIDComm V2). How do we know we can use a
did:peer:2to interact with it? - OOB invitation messages including a
from(2.0) orservices(1.1) field that has adid:peer:2. This is good for the invitee to know beforehand the inviter supports did:peer:2 so this problem is solved. But... what if the invitee does not supportdid:peer:2? Do we need to create different invitation messages for legacy agents and the new ones?
I guess at a first step we can start all interactions using unqualified DIDs and do the feature discovery, so we'd use the legacy invitation message for everyone until we are sure everybody transitioned to did:peer support. From then on we start using the new fancy invitations with did:peer:2 (or 3?) from the start.
However, I would not assume that every agent out there is still using unqualified DIDs for establishing connections. In AFJ for instance we are using did:peer:1 in DID Exchange.
There was a problem hiding this comment.
The idea is for the transition is that ASAP, all the libraries be able to handle receiving either unqualified p2p DIDs (old style we have been using for years) or did:peer:2 DIDs for establishing a connection, and unqualified or did:peer:3 DIDs for interactions using the connection. In doing this, a did:peer:3 should be defined for every unqualified DID. During this period, all deployments are expected to initiate new connections with the current unqualified p2p DIDs.
After a set date TBD, all deployments get updated to send out only did:peer:2 for establishing connections, and only send did:peer:3 for interactions using the connections. Obivously, the “ASAP” in the previous paragraph MUST be completed by all deployments by this magic date.
On your later point about — what if the invitee does not support did:peer:2? When creating a new connection, there is no way to know, as you can’t run discover-features without a connection. That is why the community coordinated update is done. “All” deployments MUST support handling did:peer:2 by the date and so all deployments assume they will. If the deployments haven’t been updated — that’s unfortunate.
So legacy invitation before the date, anytime after, switch the “new fancy invitations” with did:peer:2 (can’t be did:peer:3 because the invitation must include the needed DIDDoc information). Once the connection is established, everyone can use the equivalent did:peer:3.
Does that clarify it?
There was a problem hiding this comment.
Thanks, I guess it clarifies me a lot of things. For AFJ I think it's more or less clear to me how to proceed... we'll discuss about it in our next WG call.
Just hope that magic date will come soon (RFC 0496 is still in Step 1 😛)
Signed-off-by: Sam Curren <[email protected]>
Signed-off-by: Sam Curren <[email protected]>
No description provided.