Use qualified DIDs

[mirgee]

Currently, we are generating and storing method-less, unqualified DIDs both when creating a pairwise peer DID and an issuer DID, and then passing the values around as strings. This may be fine for now, as did:sov is the only method supported by aries-vcx, but as we are already planning to introduce support for did:indy and more, we should start qualifying DIDs to avoid ambiguity in the future. We should use mutually convertible types for qualified and unqualified DIDs (as perhaps we can still use unqualified DIDs in places and situations where the method can be inferred, like when dealing with a specific ledger transactions).

A simple-minded experiment conducted to see the downstream consequences of the switch done by simply passing a method value instead of None to create_and_store_my_did shows that this will lead to different ledger primitive (credential definition, schema, revocation registry definition) IDs, regardless of whether generated by libvdrtools or credex - both use slightly different logic when dealing with qualified DIDs.

This will also require creating a migration tool for wallets of clients who have been using the current version of aries-vcx for some time and need to continue using their connections, issuer DIDs and ledger primitives.

[swcurran]

We’re working on this in ACA-Py as well. Are you familiar with the discussions in the Aries community on dealing with the two types of unqualified DIDs we have — those on an Indy ledger (converted to did:sov for now), and Peer DIDs. For the Peer DIDs, we’re currently planning on migrating them to did:peer:2 and did:peer:3.

Happy to discuss further and to make sure there is alignment across Aries in this conversion.

[mirgee]

I was not aware of related discussions, thanks for pointing them out, @swcurran ! I found (and will keep tracking) this and this issue. Any other conversations we should be plugged into?

[swcurran]

The one other to mention is trying to come up with a mobile wallet-friendly, scalable mediator. We’re going to be talking about that at the next weekly Aries WG meeting — next Wednesday at 7:00 Pacific / 16:00 Central Europe.