Description
Current extension properties such as https://www.w3.org/TR/did-extensions-properties/#linkedresource specify particular parsing of DID URLs.
In linkedResources, a did URL with a path part, e.g., did:abc/path
is taken to be a URL that is intended to be retrieved while did:abc#fragment
is taken refer to a node in the DID Document's JSON object. Both are defined in the linkedResource property.
Whereas, in did-linked resources (a CCG work item led by Cheqd), https://w3c-ccg.github.io/did-linked-resources/, they use a path to indicate a resource, followed by the id of that resource, e.g., did:example:entity123/resources/41c0f0fe-cd4e-45aa-aec5-754db4a63865
In contrast, folks working on did:webvh are proposing that did:abc/whois refer to a service endpoint for looking up verifiable credentials about the DID subject.
Unfortunately, there is no restriction on adding these properties to various DID methods, which makes it almost impossible to have a uniform parsing of DID URLs across DID methods.
I'd like to see convergence on the meaning of different DID-URL components so that, e.g., a path part in one method is expected to operate similarly to path parts in other DID URLs.
My proposal:
DID Document | DID URL | Description |
---|---|---|
{"path" = "/path"} |
did:example/path |
intended to download as a resource. look up node in DID document graph with the path property in did doc == path value in DID URL |
{"id" = "#fragment" }` |
did:example#fragment |
intended to refer to the JSON node containing an id property equal to the fragment part of the DID URL |
{"service" : [{ "id" : "myserviceID"}]} |
did:example?serviceID |
intended to invoke a particular service endpoint as described in the service section of the DID doc. |
This is just a strawman. I realize this is incompatible with both Cheqd and did:webvh's use.
Hence my interest in finding a way to align these different efforts (and see if there are others we need to incorporate).