did:tdw resolver

[jamshale]

• Uses the trustdidweb-py library to implement the resolver.
• Plugs the resolve endpoint and library into the base_resolver class for caching and future other resolution.

[jamshale]

There's going to be an update to the spec so I'm not going to work on this until it gets approved and the library gets updated.

[swcurran]

I don’t think the update to the spec will impact what is in this PR. AFAIK, it is making a call to a library. The call will not be impacted by the spec change, which is just some details around the DID Log format.

OK to leave if you think best — just noting that the spec change should not impact this.

[jamshale]

OK. Sounds good. I can continue on this. I'm kind of blocked by bot getting it published. There's a pr in trustdidweb-py repo to do it but hasn't got completed yet.

[swcurran]

Just as a matter of interest — if the DID to be resolved was a DID URL, could/should this code return the object that is referenced instead of the DIDDoc? For example if what was to be resolved was did:tdw:1234567:example.com/whois, the resulting object would be a Verifiable Presentation. Or maybe did:tdw:1234567:example.com/OCA/ocabundle.json?

[jamshale]

Maybe that does make sense. After verifying and resolving the did it could get the response from the endpoint and return that. The way it is now, that responsibility would fall on the controller.

[swcurran]

Perhaps not needed yet, but I think we want that in the future. It gives the controller the choice, without having to get its hands dirty with the rules of DIDs and DID Resolution. Either it gets a valid object back that it can use, or it gets an error that something is broken with its request.

[dbluhm]

Perhaps not needed yet, but I think we want that in the future. It gives the controller the choice, without having to get its hands dirty with the rules of DIDs and DID Resolution.

I am all for continuing to push for controller simplicity and keeping the controllers concerns focused on business logic and not DID and Key minutia (except in circumstances where business requirements dictate being picky about those things).

I think there's a place for a dereference endpoint alongside the resolve endpoint. Having it be separate would help the caller be certain they won't unintentionally get a did document when they expected a verification method or vice versa.

It is notable however that I don't think there's generally a reason for the controller to resolve/dereference DIDs and DID URLs directly. The only time I've done this from a controller was when working around bugs or features not yet supported in ACA-Py. Which is perhaps a fair reason to justify their existence alone but, all going well, I think it would generally be unnecessary to call them.

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[PatStLouis]

+1 for what @dbluhm is suggesting, we should have a resolve endpoint that will return a did document and use a de reference endpoint for any other resources represented by a did url.

@jamshale are you planning to do any verification as part of the resolving?

Did log processing is part of the resolving section in the spec.

[jamshale]

@PatStLouis The library does the verification. I haven't gone over the spec with the code in detail, but basic testing seemed to be correct.

[PatStLouis]

Sounds good, I wasn't aware how much of the process the library was covering. This is great!

[jamshale]

Removed the did url usage in the resolver.

I think a did url dereference ticket should be created next as a separate task. Maybe with a similar pattern to the resolver.

[dbluhm]

@jamshale heads up on the conflict in the poetry.lock

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
96.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud