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

Add dereference function #90

Open
awoie opened this issue Jun 21, 2021 · 4 comments
Open

Add dereference function #90

awoie opened this issue Jun 21, 2021 · 4 comments
Labels
pinned an issue that may take a while to fix and should not be closed automatically.

Comments

@awoie
Copy link
Member

awoie commented Jun 21, 2021

DID Core distinguishes between resolving a DID and dereferencing a DID URL. Resolving a DID is already covered but it would be good have support for dereferencing a DID URL as well as defined in the DID Core spec here.

Interface looks as follows:

dereference(didUrl, dereferenceOptions) →
   « dereferencingMetadata, contentStream, contentMetadata »
@stale
Copy link

stale bot commented Aug 30, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Aug 30, 2021
@mirceanis mirceanis added the pinned an issue that may take a while to fix and should not be closed automatically. label Aug 30, 2021
@stale stale bot removed the stale label Aug 30, 2021
@GravityID
Copy link
Contributor

Because dereferencing is about extracting a specific resource from a DID Document, and given the fact that

This process depends on DID resolution of the DID contained in the DID URL

what do you think of the following

  1. Resolve a DID Document from the DID included on the DID URL to dereference
  2. Browse the resulted DID Document and search for the specific VerificationMethod or ServiceEndpoint with id = didUrl

I am concerned about two things in this algorithm:

  • Resolving the entire DID Document to get only a part sounds like an overkill. Also not really sure there is an alternative
  • If for some reason the driver specific resolve function calls the dereference function of the same DID Method, it may end in an infinite loop

@mirceanis
Copy link
Member

The steps that you outlined are exactly what should happen for dereferencing a DID URL.

As for the concerns, in my experience DID documents are relatively small so optimizing all resolvers to provide only partial documents seems premature. Since this library doesn't perform the actual DID resolution, this kind of optimization would have to be implemented by each DID method driver.
The infinite loop situation should be a concern of the DID driver that would use a pattern like this, not this library.

That being said, there are a few design decisions that can be made to make this extra useful:

  1. It might be desirable for some users to call a dereference method on an already resolved DID Document. This is especially true in situations where a lot of entries need to be dereferenced at the same time, possibly leading to multiple calls to resolve().
    Therefore, I think it would be wise to create and export a function like dereference(didDocument, didUrl, options) that would also be called internally by the dereference(didUrl, options) function.
  2. Some DID Documents use publicKey instead of verificationMethod, so this corner case also needs to be addressed.
  3. Some DID Documents use only the #fragment part of the URL for element IDs, so a simple string comparison id === didUrl would not be enough.
    This last bit is a problem for many other situations, so it makes sense to fix this as a separate line of work, since it can also be applied to the resolve() method.

@GravityID
Copy link
Contributor

Indeed the infinite loop situation does not concern this library but a disclaimer mentioning the fact that this situation can occur depending how drivers are implemented is necessary in my opinion.

  1. After a DID Document has already been resolved using this library, it should be in the cache so maybe we can use that to address the situation you mention. Then using the cache has some drawbacks like what if we already have a DID Document resolved / retrieved from a foreign source, what if the provided cache is not persistent or what if the expected result is present on a representation of the DID Document that is not is the cache.
  2. Agree
  3. Not sure I understand well. The use of relative DID URL is only possible "to reference a resource in the same DID document". So from what I understood, the complete DID URL must be provided on verificationMethod and service. But maybe I misunderstood something here
    https://www.w3.org/TR/did-core/#relative-did-urls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pinned an issue that may take a while to fix and should not be closed automatically.
Projects
None yet
Development

No branches or pull requests

3 participants