Create IndyVdrSovDidResolver In AFJ

[TimoGlastra]

Create a Decentralized Identifier resolver for resolving Hyperledger Indy according to the [Indy DID Method Specification
(https://hyperledger.github.io/indy-did-method/#indy-did-method-identifiers) and the legacy Sovrin DID Method Specification.

Although they are similar it is probably best to create two implementations, that leverage the same underlying utils and methods.

1. Create a IndyVdrSovDidResolver in the indy-vdr package. For the implementation you can copy the IndySdkSovDidResolver (from the core pacakge, that is more up to date). and adapt it work with the new IndyVdrPoolService and IndyVdrPool. The utils (such as the didSovUtils can be copied. It should be possible to resolve a did:sov did.
2. Make sure the IndyVdrSovDidResolver is exported from the indy-vdr index file
3. Write tests (TBD)

[genaris]

I'm on it (along with IndyVdrSovDidRegistrar) in a branch based on #1160. I agree it should be handled in different classes like in indy-sdk module.

[genaris]

BTW do you think it does not make any sense to include an IndyVdrSovDidRegistrar? I was thinking on it just to keep the exact same functionality as Indy SDK with shared components, but according to #1192 it seems it wouldn't be needed.

[TimoGlastra]

When interacting with other agents we should support did:sov and unqualified dids for backwards compatiblity. But for users of AFJ I think it's fine to say you should always use did:indy dids when creating objects.

A did:sov is basically a did:indy did and therefore I think you should always create it as one format, and then optionally allow to use it as a did:sov did. However if they can create both did:sov and did:indy I think it'll become more of a mess (can I use did:sov dids as did:indy dids, and can I use did:indy dids as did:sov dids?).

So the only complexity here is that what If i want to use did:sov when creating connections, or issuing (which will be unquflieid dids). In that case we should have some smart logic that knows that did:sov should actually look for did:indy internally. It's a one way migration path instead of having them both in storage.

Makes sense?

[swcurran]

did:sov and did:indy have different “verkey to identifier” algorithms. Does that matter to your discussion?

See: https://hyperledger.github.io/indy-did-method/#nym-transaction-version and the next section on backwards compatibility.

[TimoGlastra]

I would assume all did:sov dids have a direct mapping to an did:indy did right?

[swcurran]

Yes. Given the initial verkey (on the ledger) and ledger of the did:sov, one can calculate the did:indy.

[genaris]

When interacting with other agents we should support did:sov and unqualified dids for backwards compatiblity. But for users of AFJ I think it's fine to say you should always use did:indy dids when creating objects.

A did:sov is basically a did:indy did and therefore I think you should always create it as one format, and then optionally allow to use it as a did:sov did. However if they can create both did:sov and did:indy I think it'll become more of a mess (can I use did:sov dids as did:indy dids, and can I use did:indy dids as did:sov dids?).

So the only complexity here is that what If i want to use did:sov when creating connections, or issuing (which will be unquflieid dids). In that case we should have some smart logic that knows that did:sov should actually look for did:indy internally. It's a one way migration path instead of having them both in storage.

Makes sense?

Yes I think so. I've seen that IndySdkSovRegistrar is already storing created DIDs in a did:indy qualified form, so it will be quite straightforward to just support the new method.

My concern was mainly because, if I understand correctly, to register DIDs using did:indy there are a few changes needed in both client libraries (indy-vdr in this case) and indy nodes that are not available yet (at least not in their main branches), so probably one of the goals was to just match 1:1 indy-sdk features until everything is ready. However it's true that 99% of people are using AFJ in edge/mobile environments and also not so many are creating public DIDs with endpoints, so the impact of not having this would be very low.

BTW do you know if are there any deployed instances of Indy networks supporting all these new did:indy features (i.e. using 1.13.x indy nodes? I've tried resolving the example did:indy DIDs from Universal Resolver but don't seem to be using this new diddocContent field (I guess the indy:did resolver gets endpoints by using the legacy ATTRIB).

[TimoGlastra]

My concern was mainly because, if I understand correctly, to register DIDs using did:indy there are a few changes needed in both client libraries (indy-vdr in this case) and indy nodes that are not available yet (at least not in their main branches), so probably one of the goals was to just match 1:1 indy-sdk features until everything is ready. However it's true that 99% of people are using AFJ in edge/mobile environments and also not so many are creating public DIDs with endpoints, so the impact of not having this would be very low.

All did:sov dids will have a direct mapping to a did:indy did, so in theory the did:indy specification is an extension of the previous did:sov spec. That's why I don't think it's an issue to already start using the new format internally.

I think Andrew wanted to do a new release for indy-vdr soon with did indy support.

BTW do you know if are there any deployed instances of Indy networks supporting all these new did:indy features (i.e. using 1.13.x indy nodes? I've tried resolving the example did:indy DIDs from Universal Resolver but don't seem to be using this new diddocContent field (I guess the indy:did resolver gets endpoints by using the legacy ATTRIB).

I think the nodes are up-to-date (@swcurran is that true?), however there's no clients that support it yet.

[swcurran]

Published indy-vdr artifacts do not support did:indy, but the support is in a dev branch that has not been merged.

Existing indy networks (Sovrin, Indicio, etc.) have just received a release candidate that will allow upgrading to supporting did:indy. I think the networks will be aggressive at moving the networks to the new release, as it is long overdue.