did:tdw resolver #3237
did:tdw resolver #3237
Conversation
jamshale
commented
Sep 16, 2024
•
jamshale
commented
- 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.
|
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. |
|
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. |
|
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. |
jamshale
force-pushed
the
did_tdw_resolver
branch
from
a3bfe32
to
d9c703d
Compare
aries_cloudagent/did/tdw/routes.py
Outdated
| class DidTdwResolveResponse(OpenAPISchema): | ||
| """Response schema for create DID endpoint.""" | ||
|
|
||
| did_doc = fields.Dict( |
There was a problem hiding this comment.
I'm thinking about just returning the diddoc dict here instead of inside this key.
jamshale
force-pushed
the
did_tdw_resolver
branch
from
d9c703d
to
e582674
Compare
|
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 |
|
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. |
|
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. |
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 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. |
jamshale
force-pushed
the
did_tdw_resolver
branch
from
e582674
to
671558e
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
+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. |
|
@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. |
|
Sounds good, I wasn't aware how much of the process the library was covering. This is great! |
jamshale
force-pushed
the
did_tdw_resolver
branch
3 times, most recently
from
11cd60f
to
72520aa
Compare
Signed-off-by: Jamie Hale <[email protected]>
Signed-off-by: Jamie Hale <[email protected]>
jamshale
force-pushed
the
did_tdw_resolver
branch
from
72520aa
to
e77aa8a
Compare
|
| @@ -56,7 +56,9 @@ async def _resolve( | |||
| if isinstance(did, DID): | |||
| did = str(did) | |||
| else: | |||
| DID.validate(did) | |||
| if not DID.is_valid(did) and not DIDUrl.is_valid(did): | |||
There was a problem hiding this comment.
This allows for the DIDUrl to be resolved. I admittedly don't have a lot of knowledge here.
| # Did or DidUrl regex | ||
| PATTERN = re.compile( | ||
| "^did:([a-z0-9]+):((?:[a-zA-Z0-9._%-]*:)*[a-zA-Z0-9._%-]+)(#\w+)?$" | ||
| ) |
There was a problem hiding this comment.
Changes the pattern to allow did url pattern. Couldn't figure out how to do it with the pydid library.
