Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 0067: Service Conventions - inline keys #117

Closed
mitfik opened this issue Jul 10, 2019 · 2 comments
Closed

RFC 0067: Service Conventions - inline keys #117

mitfik opened this issue Jul 10, 2019 · 2 comments
Labels
question Further information is requested

Comments

@mitfik
Copy link
Contributor

mitfik commented Jul 10, 2019

When DID resolver resolves DID url with service query it provides the block for whole service with keys references.

Does it make sens that DID resolver can already compile all keys inline so the requester does not have to resolve each key separately?

Keep in mind that did resolver does not necessary need to run remotely it could run locally which resolve did document according DID resolution spec

@peacekeeper
Copy link
Member

I think this is a great idea, perhaps you also want to raise this as an issue on the DID Resolution spec so we can track it there? I can imagine this to be specified as an option for the resolution/dereferencing algorithm.

There may be features in JSON-LD that support this already. In terms of the underlying RDF graph model, selecting a service from a DID Document comes down to selecting a subgraph.

@swcurran
Copy link
Member

swcurran commented Sep 7, 2019

This question belongs, as @peacekeeper notes, in the DID Resolution spec., with Aries implementing that spec. as appropriate. Closing this issue as complete from an Aries perspective.

Please reopen if appropriate.

@swcurran swcurran closed this as completed Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants