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

Support for resolving other types of Ledger Objects #288

Open
vpapanchev opened this issue Feb 21, 2022 · 3 comments
Open

Support for resolving other types of Ledger Objects #288

vpapanchev opened this issue Feb 21, 2022 · 3 comments

Comments

@vpapanchev
Copy link

Hello,

Some DID Methods, e.g., Indy DID Method, store other types of objects on their ledgers, such as Credentials Schema and Revocation Registry definitions.
Currently the Universal Resolver does not support such objects. For example, executing the following command returns an error message "Cannot parse DID".
curl -X GET http://0.0.0.0:8080/1.0/identifiers/did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM/anoncreds/v1/SCHEMA/npdb/4.3.4

Have you planned to add support for resolving other types of ledger objects?
If not, is there another DIF project or working group working on this problem?

Cheers,
Vasil Papanchev

@swcurran
Copy link

The plan is to add this for at least "did:indy", but the working is currently active on enabling that. You can follow the work here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification

@vimmerru
Copy link

@swcurran

Do you plan to use dereferencing instead of resolving to achieve this? See https://www.w3.org/TR/did-core/#did-url-dereferencing

Will it be dedicated endpoint?

@swcurran
Copy link

Sorry for the delay in responding -- I've been out of the office.

Our plan for did-indy is to use dereferencing DIDURLs using a path and a DID Method specific dereferencing process. This is outlined here: https://hyperledger.github.io/indy-did-method/#did-urls-for-indy-object-identifiers

We talked about each of the various AnonCred objects having a specific DID, and the object itself being embedded in a DIDDoc. With that, you could just resolve the DID and extract the object from the DIDDoc (or dereference the DID to get the fragment from the DIDDoc that is the object). The nice part of that would be that the approach could be used on different ledgers/DID Methods -- each object is just embedded in a DIDDoc. However, we've were not able to find anyone using that pattern and we're aware that some VDRs/DID Methods (such as sidetree) prevent extensions in the DIDDocs.

I'd love to know if it is possible or considered a good idea to embed such objects in a DIDDoc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants