feat(indy-sdk)!: move to did:indy with limited support

[TimoGlastra]

Adds full did:indy support for the indy-sdk package, while still keeping support for did:sov dids in interactions with other agents.

The IndySdkAnonCredsRegistry now supports resolving both did:indy and legacy unqualified anoncreds objects. I wasn't sure on making it two separate classes due to the duplication. I think it's okay that they're combined for now, but it may be nice to split them up at some point so users could choose to e.g. not support the legacy identifiers anymore.

In addition a new IndySdkIndyDidRegistrar has been added. This doesn't support the diddocContent. The IndySdkSovDidRegistrar has been removed. From now on you can create did:indy dids, which contain the namespace, but you can keep on using the did:sov resolvers.

For registering anoncreds object you can now only use did:indy identifiers as this will contain the namespace, but you can still use the unqualified ones in using the legacy indy credential format services.

There's some additional work needed to the indy sdk issuer/holder/verifier services to make sure we can handle but qualified and unqualified dids and can also use them interchangeably.

Note
I don't think we're able to support did:indy using the indy-sdk as the identifiers are part of the credential meaning the identifiers in the credentials always must be unqualfiied as indy-sdk doesn't allow qualified input. I still think primarily supporting did:indy when creating objects is a good choice, as it allows us to prevent a lot of the ambiguity around which ledger to use.

I'll make a similar PR for the indy-vdr package so they'll be in feature parity.

BREAKING CHANGE: The IndySdkSovDidRegistrar has been removed in favour of the new IndySdkIndyDidRegistar. you can register the same dids as you could do with the IndySdkSovDidRegistrar, but now with less ambiguity on which ledger should be used as that's encoded in the did itself.

[codecov-commenter]

Codecov Report

Merging #1347 (b90e41a) into main (7795975) will decrease coverage by 15.06%.
The diff coverage is 81.13%.

@@             Coverage Diff             @@
##             main    #1347       +/-   ##
===========================================
- Coverage   86.65%   71.60%   -15.06%     
===========================================
  Files         778      694       -84     
  Lines       18476    16692     -1784     
  Branches     3163     2861      -302     
===========================================
- Hits        16011    11952     -4059     
- Misses       2458     4737     +2279     
+ Partials        7        3        -4     

Impacted Files	Coverage Δ
packages/indy-sdk/src/dids/didSovUtil.ts	90.90% <ø> (-6.07%)	⬇️
...sdk/src/anoncreds/services/IndySdkIssuerService.ts	22.91% <28.57%> (+1.98%)	⬆️
...sdk/src/anoncreds/services/IndySdkHolderService.ts	8.54% <33.33%> (ø)
...k/src/anoncreds/services/IndySdkVerifierService.ts	21.87% <33.33%> (ø)
packages/indy-sdk/src/anoncreds/utils/transform.ts	48.38% <33.33%> (-0.19%)	⬇️
...ackages/indy-sdk/src/dids/IndySdkSovDidResolver.ts	68.42% <50.00%> (-17.30%)	⬇️
...kages/indy-sdk/src/dids/IndySdkIndyDidRegistrar.ts	72.72% <72.72%> (ø)
...ckages/indy-sdk/src/dids/IndySdkIndyDidResolver.ts	80.00% <80.00%> (ø)
packages/indy-sdk/src/ledger/IndySdkPoolService.ts	95.03% <92.30%> (-0.42%)	⬇️
...ckages/indy-sdk/src/anoncreds/utils/identifiers.ts	95.00% <94.59%> (-5.00%)	⬇️
... and 308 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[genaris]

Pretty interesting work here. Really like the usage of regex with named groups. Certainly very useful for DID and AnonCreds object parsing!

Even if I'm not so convinced about the needs of indy-sdk-based did:indy registrar and resolver considering its limited capabilities, I do see value on it for leveraging everyone to move to this new concept and move away from legacy did:sov.

My remarks are mainly some warnings regarding the importance of documenting well about these limitations and maybe recommending everyone to switch to indy-vdr as soon as possible to fully support did:indy. BTW, this PR's name suggested me that it would bring a true full support for did:indy (with diddocContent and everything), and now I feel like I fell into a marketing trap 😆.

[genaris]

So indy-sdk has a 'ver' field hard-coded to 1?

For the moment, I think it's OK to leave this comment only internal, but once indy-vdr and indy-node officially supports it I think we'll need to add transactionVersion to DidCreateOptions for both implementations, making explicit that only '1' is allowed for indy-sdk while 0, 1 and 2 will be possible for indy-vdr.

[TimoGlastra]

Not sure what you mean. I mean the 1 from here: https://hyperledger.github.io/indy-did-method/#nym-transaction-version

[genaris]

Yes, I'm referring to that too! When I've read that before implementing IndyVdr did:indy classes, I understood that it would be possible for an app to indicate whether to use 0, 1 or 2 when creating a DID, so I imagined having an extra parameter in the DidRegistrar that would allow us to specify the transactionVersion.

So, in case of IndyVdr, we could set transactionVersion=1 if we wish to register a did:sov and transactionVersion=2 if we want to register a brand-new did:indy. Even a transactionVersion=0 would be possible (for super legacy ledgers I think... not sure why it was added).

Do you think this transaction version will be always hard-coded on the indy library? (i.e. 1 for indy-sdk and probably 2 for indy-vdr with did:indy support?)

[TimoGlastra]

I understand. Yeah we should probably make that configurable and default to transactionVersion=1. However we can't set the transaction version I think with the indy-sdk?

[genaris]

Yeah, for indy-sdk will be always 1. We just need to make clear about this limitation either in docs or by adding this transactionVersion to DidCreateOptions whose only possible value is '1'. This is of course not for this PR.

[genaris]

This is a very important note. Surely it will need to be published in the module README. I'm not sure if it will be possible to get the diddocContent field from the GET_NYM response using the indy-sdk as it is right now. If that will be the case, it could be a bit misleading to have an IndyDidResolver class that is not able to parse a did:indy that conforms to the specification.

[TimoGlastra]

Yeah good point. I think it should just return it in the JSON. The NYM transaction is stored as stringified JSON on the ledger. We may not be able to use the parse method from the indy-sdk, but we should be able to extract the diddocContent property. If we get to this point, we can look into it again. But I think before we have did:indy dids takes written to the ledger will take a while, and I'm not particularly keen to wait for it...

[genaris]

I agree! I had the same doubts when implementing it for indy-vdr and did some assumptions as a result. The time will tell 😆

[TimoGlastra]

Not sure how to fix the revocation registry regex issue. It's just the regex that ACA-Py also uses. Should we impose a character limit on the id length?