Indy DID Method spec (NYM transaction version 2) is not supported by ACA-Py

[JoLuPuma]

First, it’s know that for the self-certifying Did’s, the namespace identifier or DID identifier is derived from the public key (Verkey). So for a same SEED value the DID identifier is different if we use the did:sov or did:indy approach (the Verkey remains the same in both cases). https://hyperledger.github.io/indy-did-method/#nym-transaction-version

For example , for a given SEED I generated this:
did:indy approach
DID: NLe9bFbaNs1Eareg4eCXky and Verkey: 2EDa4DdtBVSVthbjP7S4p6u8tPZpasV9ywc9xLn1SkpA

did:sov approach
DID: 3FfZB8jq8kch5qddakysA2 and Verkey: 2EDa4DdtBVSVthbjP7S4p6u8tPZpasV9ywc9xLn1SkpA

My use case:

1. I created a did:indy from a SEED, so I got a DID identifier and a Verkey
   DID: NLe9bFbaNs1Eareg4eCXky and Verkey: 2EDa4DdtBVSVthbjP7S4p6u8tPZpasV9ywc9xLn1SkpA
2. I registered the DID identifier and Verkey in the Ledger
3. I started an ACA-Py agent using the initial SEED
4. In the connection process with the Ledger (and other stuff that ACA-Py does while provisioning), ACA-Py generates a DID identifier and a Verkey from the SEED. But the DID identifier is generated using the did:sov approach. So, this DID identifier (did:sov) is different for the DID identifier (did:indy) published in the Ledger.
5. And then I got this error : indy_vdr.error.VdrError: Request failed: client request invalid: could not authenticate, verkey for 3FfZB8jq8kch5qddakysA2 cannot be found
6. And is logical because there is no 3FfZB8jq8kch5qddakysA2 published in the ledger

Is it planned to replace did:sov by did:indy in ACA-Py or support both as described here?

[PatStLouis]

Something I'd like to clarify

• 3FfZB8jq8kch5qddakysA2 is not a DID
• did:sov:3FfZB8jq8kch5qddakysA2 is a DID

The same way that:

• www.linkedin.com is not a DID
• did:web:www.linkedin.com is a DID

There's the concept of qualified/unqualified DID, but I strongly disagree with this as the did core specification has a strict representation that a DID MUST be a URI:
https://www.w3.org/TR/did-core/#did-syntax

Unqualified DIDs are NOT DIDs, they are just an identifier. This term is misleading.

Now with this out of the way, what is the difference between did:sov and did:indy when resolving?

DID sov is just this, the did prefix did:sov: and the did identifier 3FfZB8jq8kch5qddakysA2.
This method requires the resolver to know in advance against which network to resolve it. This is not covered by the sovrin did method. The did doesn't contain sufficient information in itself to be resolved.

DID indy adds the concept of namespaces in the did prefix:
did:indy:<network>:<identifier>

This sort of addresses the issue, but the problem still remains that the resolver will need to have a list (or directory structure) of known Indy networks. Both of these DID methods require a resolver which has existing knowledge of which networks it knows and their labels.

I started an ACA-Py agent using the initial SEED

There's currently no way to provision aca-py with a seed resulting in something else than a sov provisioned identifier. However, a resolver will still be able to resolve this DID registered on the network using a did:indy: syntax because they are essentially the same thing.

What the did indy method adds is a specified method to refer to other published objects such as anoncreds object through paths.

@JoLuPuma my first question would be, what do you look to achieve by using the did:indy: method to refer to your dids? For operating the agent, it won't change much unless I'm missing something.

For the backwards compatibility part, yes I think this is something that should be included in aca-py. Is this something your team can look into?

[JoLuPuma]

@PatStLouis
I think I didn't explain myself well. I was not talking about resolving a did:indy but the generation of the IDENTIFIER using the spec Indy Did Method . AFAIK for security reasons the spec Indy DID Method (https://hyperledger.github.io/indy-did-method/#nym-transaction-version) has changed or has added a new way to generate the IDENTIFIER (what it is called the did:indy approach):

• NYM Transaction Version 1 (did sov approach or the old Indy SDK convention) did = Base58(Truncate_msb(16(publicKey)))
• NYM Transaction Version 2 (did:indy approach) did = Base58(Truncate_msb(16(SHA256(publicKey))))
  The problem is that ACA-Py does not respect or does not support the NYM Transaction Version 2 of the spec indy DID Method.
  In my case I use the NYM Transaction Version 2 for generating the IDENTIFIER and Verkey, then I register them in the ledger. So when I start/provision my agent ACA-PY, by default, it generates un IDENTIFIER and Verkey from the SEED, but as it uses the did sov approche (NYM Transaction Version 1 ) the IDENTIFIER generated by ACA-Py is very different from the one I published in the ledger. Then the identifiers dont match and ACA-py does not start.
  Error from the original post: indy_vdr.error.VdrError: Request failed: client request invalid: could not authenticate, verkey for 3FfZB8jq8kch5qddakysA2 cannot be found

[PatStLouis]

This makes sense yes, so theres 2 things I could see happening:

• Define a new did registration method for indy:
  • We are currently in the process of restructuring the did registration methods, if you would like to tackle this it would be a welcome addition. It should be as simple as copying the current sov method and use the new identifier algorithm. However this still won't allow you to provision the startup seed using this new method unless further changes are made.
• Implement the backwards compatibility function as you described into aca-py's codebase whenever it interacts with the ledger.