[Community Coordinated Update] Migrating to fully qualified dids

[TimoGlastra]

As been discussed in the Aries WG calls lately we want to move away from usage of unqualified dids. This issue focuses on usage of unqualified dids in didcomm, not in lower level objects (such as indy attachment formats).

Currently two did methods have been identified that would need custom handling by agents to update them to fully qualified dids, namely legacy did peer dids and unqualified indy/sov dids.

I've written a draft for a community coordinated update RFC: https://hackmd.io/0PP3vrq7Qb2oD5wja8kLcQ?view. It still needs a lot of wording and context added, but the foundation is ready.

When writing the RFC and tinkering around with the possibilities in Aries Framework JavaScript I encountered a few issues that I would like some input on.

did:peer
We should decide on a numAlgo to use for moving to did:peer dids. If both sides need to be able determine the new did based on the old did we would need to lock the numAlgo.
- The limitation of enforcing did:peer:2 is that the did document will be static
- The limitation of enforcing did:peer:1 is that it is impossible to determine the old did based on the did.

In addition for both numAlgo's its basically impossible to deterministically generate the new did from the did document as the peer did method spec doesn't use a canonicalization scheme.

We could use a protocol that would share the transformed did document with the new did, but that would make the whole process way more complex, and not very different form the connection protocol itself.

[TimoGlastra]

Another approach would be to wait for DIDComm v2 to arrive and use the native did rotation method https://identity.foundation/didcomm-messaging/spec/#did-rotation. We could either allow the legacy dids as is, or prefix it with something like did:legacypeer:<identifier>

[andrewwhitehead]

For peer DIDs, I'm not really interested in trying to 'upgrade' DIDs without a numalgo or converting qualified DIDs into any other format. I think that upgrading to qualified peer DIDs will require establishing a new connection, at least while we are using DIDComm v1 envelopes and connection protocols. In ACA-Py my current suggestion is to keep using the 0.1 version of peer DIDs in the connection protocol, and to use qualified 1.0 peer DIDs in the did-exchange protocol when the api-2 flag is enabled at startup, and possibly if the other party sends a did-exchange request using a 0.1 peer DID.

For DIDComm v2, I don't really understand at the moment how the other party is meant to resolve the DID document when did:peer method 1 is used. I suppose if method 2 is used then all the details are in the DID itself, but also get sent with every message?

[TimoGlastra]

As I understand it, for did:peer:1 dids you could use the initialState param https://github.com/decentralized-identity/did-spec-extensions/blob/main/parameters/initial-state.md.

See also https://github.com/decentralized-identity/didcomm.org/blob/main/site/content/book/v2/whatsnew.md#special-handling-of-peer-dids-eliminated

I think that upgrading to qualified peer DIDs will require establishing a new connection, at least while we are using DIDComm v1 envelopes and connection protocols.

This is useful feedback. One of the things I would like to get out of this issue is feedback whether we want/need this. If I hear from implementors this is not desired and we need to create new connections instead, that is a good outcome.

[TelegramSam]

Discussed WG 202211207. We concluded that nobody knows the state of adoption in the codebases.