shifts from resolving "DIDs" to "DID URLs" #324
Conversation
…T propagate and clients may make errors.
| " > | ||
| <figcaption> | ||
| Overview of DID URL dereference | ||
| Overview of DID URLk resolution and dereferencing |
There was a problem hiding this comment.
| Overview of DID URLk resolution and dereferencing | |
| Overview of DID URL resolution and dereferencing |
peacekeeper
left a comment
There was a problem hiding this comment.
-1 to changing the input of DID Resolution from a DID to a DID URL. This is an enormous change that would not be backward-compatible with DID 1.0 and break pretty much every existing deployment of DIDs out there.
| <p> | ||
| The top left part of the diagram contains a rectangle with black outline, labeled "DID". | ||
| The left part of the diagram contains a single rectangle with | ||
| black |
There was a problem hiding this comment.
| black |
I think
| a <a>DID resolver</a>. | ||
| <p>[=DID resolution=] is the process of obtaining a <a>DID document</a> for a given <a>DID URL</a> (all <a>DIDs</a> are DID URLs). | ||
| Relying on [=DID resolution=], <a>DID URL dereferencing</a> is the process of applying a representation | ||
| of a resource for a given <a>DID URL</a> to the current computational context. Software and/or hardware that is able to execute [=DID resolution=] is called a <a>DID Resolver</a>. Software and/or hardware that is able to call [=Resolve=] on a DID resolver as part of dereferencing a DID URL are called DID URL clients. |
There was a problem hiding this comment.
| of a resource for a given <a>DID URL</a> to the current computational context. Software and/or hardware that is able to execute [=DID resolution=] is called a <a>DID Resolver</a>. Software and/or hardware that is able to call [=Resolve=] on a DID resolver as part of dereferencing a DID URL are called DID URL clients. | |
| of a resource for a given <a>DID URL</a> to the current computational context. | |
| Software and/or hardware that is able to execute [=DID resolution=] is called a <a>DID Resolver</a>. | |
| Software and/or hardware that is able to call [=Resolve=] on a DID resolver as part of | |
| dereferencing a DID URL are called DID URL clients. |
Split into lines.
Also, I am unsure if [=Resolve=] is intended as a reference to a term. Currently, there is no Resolve term defined in terms.html.
| If not, the <a>DID resolver</a> MUST return the following result: | ||
| <ol class="algorithm"> | ||
| <li><b>didResolutionMetadata</b>: <var>error object</var> with type set to <code><a href="#INVALID_DID">https://www.w3.org/ns/did#INVALID_DID</a></code></li> | ||
| <li><b>didResolutionMetadata</b>: <var>error object</var> with type set to <code><a href="#INVALID_DID_URL">https://www.w3.org/ns/did#INVALID_DID_URL</a></code></li> |
There was a problem hiding this comment.
Noting this collapses two different error states into one error code.
- The DID itself is invalid per either the DID core or DID method spec
- The URL part of the DID is invalid, e.g. query params are wrong time
I understand that a DID is a DID URL, but still these do fee different enough to distinguish to me.
If we do want to just use INVALID_DID_URL, then this PR should also remove the INVALID_DID error code as it is no longer used by the spec.
|
Chair hat off - I am fine with this change, I think it simplifies the API and makes sense to me. I like that with this change - Resolve Chair hat on. I hear Markus's point:
There are normative statements in DID 1.0 that define the Resolve API - https://www.w3.org/TR/did-1.0/#resolution. This change is breaking. Are there implications in relation to our charter - with DID being in maintenance mode - that we need to consider here? Also @peacekeeper will you FO if this PR goes into the spec? |
|
I agree with this change and think it is worth effort to understand the backwards compatibility and try to make the change palatable. Whether we say it in the spec or not, I think it is what happens so addressing it sooner than later is a good thing. |
Yes, especially since I haven't heard any explanation for this change that made sense to me... |
|
@jandrieu It seems the updated image |
since query parameters MUST propagate and clients may make errors.
This address two of the line items in #311
Pass a full DID URL to resolution, since the resolver may need DID URL parameters that the dereferencer is unaware of. This is especially true for method-specific extensions where resolvers know the special magic, e.g., BTCR, but the resolving client just wants to get back the right DID document, without needing to parse the incoming URL.
Updated the DID resolution image to clarify that resolution always returns a DID document and that dereferencing always presents a resource (which might mean display or serialized output), noting that the resource returned from dereferencing can be the DID document
Handling 2 without 7 would have left the document inconsistent.
Preview | Diff