Add normative DID URL Dereferencing section.

[msporny]

This adds the normative text related to DID URL Dereferencing.

This is a WIP, do not merge.

---

Preview | Diff

[philarcher]

Same comment as for PR 263. This:

"The general process of DID URL dereferencing is described in § 10.2 DID URL Dereferencing . The details of implementing a DID URL dereferencer are described in the DID Resolution specification [DID-RESOLUTION]."

is out of order IMO. From a normative POV, the DID-RESOLUTION doc does not exist. I know it does and I dearly wish it were in scope of the WG - that would make life a lot easier, but it isn't. So we can't treat it as if it is.

Again, write the normative sections without any ref to DID-RESOLUTION, then create one simple, short informative section in the doc, somewhere, pointing to it.

[jandrieu]

IMO, dereferencing is out of scope. Resolving a DID to a DID Document is one thing--that's the whole point of the architecture: separating the identifier from associated cryptographic material.

However, once the spec moves into how we use that DID Document to dereference a specific resource OTHER than the DID Document, it extends beyond the minimum necessary for decentralized identifiers, with privacy implications that I believe are currently underexamined or dismissed to date.

[jricher]

Suggest changes to terms and some pieces of content.

[jricher]

Suggested change

	<code>dereference ( did-url, input-options ) -> ( content, did-document-metadata, did-dereference-metadata )</code>
	<code>dereference ( did-url, input-metadata ) -> ( resource, did-document-metadata, did-dereference-metadata )</code>

[jricher]

Suggested change

	inputs to this function.
	inputs to this function but MAY define additional functions with different input and output definitions.
	Specification of such additional functions is outside the scope of this document.

[jricher]

Suggested change

	The <code>content</code> of this function's output is a byte stream of data. This byte stream MAY
	The <code>resource</code> of this function's output is a byte stream of data. This byte stream MAY

[TallTed]

If this gets revived somewhere, The <code>resource</code> of this function's output ... would read better as The <code>resource</code> output by this function ....

[jricher]

Suggested change

	If the returned <code>content</code> is a <a>DID document</a>, the <a>DID URL dereferencer</a> MAY
	If the returned <code>resource</code> is a <a>DID document</a>, the <a>DID URL dereferencer</a> MAY

[iherman]

Same comment as for PR 263. This:

"The general process of DID URL dereferencing is described in § 10.2 DID URL Dereferencing . The details of implementing a DID URL dereferencer are described in the DID Resolution specification [DID-RESOLUTION]."

@philarcher where did you find this quote in this PR? The "style" of this PR text is something like this quote:

The DID resolution function resolves a DID into a DID document by using the "Read" operation of the applicable DID method. (See § 9.2.2 Read/Verify .) The details of how this process is accomplished is outside the scope of this specification, but all implementations MUST implement a function in the form:

resolve ( did, input-metadata ) -> ( did-document, did-document-metadata, did-resolution-metadata )

Which sounds perfectly fine for me in separating what is normative and what is not.

[iherman]

However, once the spec moves into how we use that DID Document to dereference a specific resource OTHER than the DID Document, it extends beyond the minimum necessary for decentralized identifiers, with privacy implications that I believe are currently underexamined or dismissed to date.

The only logical conclusion from this is that the spec MUST NOT include the DID URL as a notion. This is a consistent view but, at this moment, we do have this notion. If we have, then we are supposed to define what it is...

[peacekeeper]

@jandrieu are you also objecting to having DID URLs in the spec? Or are you fine with having DID URLs, but you just object to talking about dereferencing them?

[jandrieu]

@peacekeeper That's a great question.

My preference would be a much stripped down spec, with a MVP that cleanly and clearly supports decentralized proof of control of identifiers. The mapping of those identifiers to resources and verification methods is, IMO, better handled at a different level, mainly because of concerns over privacy implications of current approaches.

That said, I expect that some way to go from a DID to a particular resource (treating a DID as a URL) is going to be important to too many participants and we should figure that out. I just don't think we've figured it out yet. In particular, I believe the fragility caused by merging parameters to be so confusing to most developers that many who experiment with DIDs will find they don't work very well--in the same sense that XHTML didn't work very well because it was overfragile.

So, clarifying that resolution means returning a DID Document, to me, is absolutely in scope.

What is done with that DID Document to get to a non-DID Document resource is a bigger problem that we have not yet figured out and many of the proposed solutions give me considerable pause because of layer violations, such as multiple service endpoints and embedding resources in the DID Document.

IMO, we don't need these features to ship a viable solution for DIDs that enable cryptographic proof of control without relying on a trusted third party.

So, IMO, resolution is in scope for DID-Core, but I'm struggling to see how dereferencing is--AND I see more problems than consensus in the myriad of options currently under discussion.

[peacekeeper]

@jandrieu to follow up on this thread, sorry it took so long to respond

That said, I expect that some way to go from a DID to a particular resource (treating a DID as a URL) is going to be important to too many participants and we should figure that out. I just don't think we've figured it out yet.

I completely agree that we haven't figured out all the details of what a DID URL can potentially dereference to, but I also think that there is overwhelming support for having DID URLs per se (at a minimum, super-simple DID URLs such as did:ex:123#key-1). Therefore, I think it is only logical that we define the dereferencing contract in addition to the resolution contract, would you agree?

However, having said that..

What is done with that DID Document to get to a non-DID Document resource is a bigger problem

I agree with your concerns that we haven't fully understood what types of non-DID document resources a DID URL can potentially dereference to, if any at all. The PR currently says this:

"This content MAY be a DID document, a portion of a, a service endpoint, or some other data. The details of the implementation of this function are outside the scope of this specification"

Is there perhaps some way to rephrase this part to address your concerns? I do think we need to define dereferencing for the reasons stated above, but perhaps we can do that in a way that avoids the "other data" language?

[OR13]

I'd rather not be tackling dereferencing and resolution at the same time, I feel like we should focus on PRs not marked as Draft that address DID Resolution first.

[jandrieu]

To my mind, what we absolutely need to specify is the expectation (aka contract) regarding the retreival of a DID Document given a DID. That's resolution.

How one then processes that DID Document further, is, IMO, out of scope. First, because we don't need to solve the DID URL problem to solve the decentralized identifier problem. So let's solve the simple, required use first, then see if there is consensus to build further capabilities.

Second, because dereferencing is still an unsolved puzzle. How do we aggregate DID URLs with service endpoints when both have multiple query and path parts? There is no consensus on this.

Third, all of the dereferencing conversations I've been in to-date have serious privacy implications as they turn DID Ledgers into directories with insufficient controls for privacy and regulatory compliance. I've stated before I believe the directory problem is fundamentally at a different layer than decentralized proof of control over an identifier. And it is this decentralized proof of control that is fundamentally what is new in this work. Directories aren't new and I've heard no concrete proposals about how such directories would handle the range of issues that are particular to their function.

So, strong +1 for leaving de-referencing to a future work item. What we MUST have is resolution. Anything more is not only risky, today we don't have consensus on how to approach it.

[peacekeeper]

@jandrieu

Second, because dereferencing is still an unsolved puzzle.

I would say it's a partially unsolved puzzle. We see a lot of DID URLs such as did:ex:123#keys-1 out there. Resolving the DID, and looking up the public key by fragment, that is dereferencing. So I don't think the simple fact that there are DID URLs that can be dereferenced, or the contract for doing that, should be problematic. But I do agree that certain parts of dereferencing, e.g. when it involves paths or query strings, could be problematic.

Just wanted to make this distinction.

[msporny]

Closing since the group is now converging on attempting to get PRs #295, #296, #297, #298, #299, and #300 into the spec.

[jricher]

PRs #295, #296, #297, #298, #300, and #299 do not cover or include this material.

[msporny]

PRs #295, #296, #297, #298, #300, and #299 do not cover or include this material.

Hmm, right... overzealous closing of PRs in an attempt to streamline to yours.

I'm going to leave this closed as your other PR that you have requested be left open has Dereferencing in it, and we don't need two separate PRs (at this point) doing so.