Add dereference function

[awoie]

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]

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.

[GravityID]

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]

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]

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