Comments (4)
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.
from did-resolver.
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
- Resolve a DID Document from the DID included on the DID URL to dereference
- Browse the resulted DID Document and search for the specific
VerificationMethod
orServiceEndpoint
withid
=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 thedereference
function of the same DID Method, it may end in an infinite loop
from did-resolver.
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:
- 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 likedereference(didDocument, didUrl, options)
that would also be called internally by thedereference(didUrl, options)
function. - Some DID Documents use
publicKey
instead ofverificationMethod
, so this corner case also needs to be addressed. - Some DID Documents use only the
#fragment
part of the URL for element IDs, so a simple string comparisonid === 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 theresolve()
method.
from did-resolver.
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.
- 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.
- Agree
- 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
andservice
. But maybe I misunderstood something here
https://www.w3.org/TR/did-core/#relative-did-urls
from did-resolver.
Related Issues (20)
- [proposal] Add cosmosAddress Property in verificationMethod like a ethereumAddress HOT 10
- [BUG] Incorrect did matcher regex HOT 1
- [bug] private member `registry` leads to typescript compiler errors HOT 1
- JsonWebKey Interface only for a public key? Missing private key parameter. HOT 2
- Exporting the JsonWebKey interface HOT 2
- [BUG] ServiceEndpoint interface does not match DID Spec HOT 1
- [BUG] `types` are not exported correctly in `package.json` HOT 1
- [proposal] Allow query of a key fragment as a document HOT 3
- [proposal] Add list of known implemented methods with reference HOT 1
- further parameter for resolving HOT 5
- Authentication interface: publicKey in DidDoc an Array but string in type HOT 2
- Why owner instead of controller? HOT 2
- `@context` data type is defined too narrowly, causing issues with typescript projects HOT 1
- Action Required: Fix Renovate Configuration HOT 1
- How to verify DID Document returned from Resolver? HOT 6
- Add support for didResolutionMetadata and didDocumentMetadata HOT 5
- How to build this project with an example? HOT 1
- The automated release is failing 🚨
- Dependency Dashboard HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from did-resolver.