Skip to content

Address incompatible entries in extensions registry #150

Open
@jandrieu

Description

@jandrieu

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions