Re: Idea for a Proposal: Notation for resolving a DID identifier directly to the underlying object or collection of objects associated with the DID identifier

On Thu, 30 Dec 2021 14:51:54 +0000
"Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net> wrote:

> RE: then when a resolver calls the associated VDR using that DID URL,
> the VDR returns the identified digital resource, not the DID document.
> 
> Charles, I'm surprised someone hasn't jumped in n this sooner: what
> type of resolver are you referring to?

I was quoting from the resource parameter specification [1]. I think it must refer to a DID URL Dereferencer [2]. A DID resolver as such only resolves DIDs [3], while a DID URL Dereferencer dereferences DID URLs [4]. If a DID resolver is being referred to as taking DID URLs as input, I think it must be understood as both a DID resolver and a DID URL dereferencer, i.e. a single piece of software implementing both a DID resolution interface and a DID URL dereferencing interface - and handling a DID URL as part of DID URL dereferencing.

> [...] if the resolver is a DID Resolution specification compliant
> resolver, the resolver can only return DID Document compliant
> resources (or portions of a DID Document compliant resource). ... if
> the above is true, supporting a TOIP query string parameter that can
> return arbitrary JSON structures will break interoperability of the
> DID ecosystem.
> Your thoughts? ...my knowledge of the DID Resolution spec may be
> out of date.  

DID URL dereferencing can return an arbitrary content resource. DID Core says (in §7.2 DID URL Dereferencing [4]) that contentStream (the part of the DID URL dereferencing result other than the metadata) "MAY be a resource such as a DID document that is serializable in one of the conformant representations, a Verification Method, a service, or any other resource format that can be identified via a Media Type and obtained through the resolution process". 

On Thu, 30 Dec 2021 17:34:01 +0000
"Michael Herman (Trusted Digital Web)" <mwherman@parallelspace.net> wrote:

> I don't think extensions that violate the DID specifications should
> be accepted into the registry IMO. For example, the DID Resolution
> specification doesn't allow a resolver to return an arbitrary JSON
> structure.

I think the DID Resolution draft specification is consistent with DID Core in allowing DID URL Dereferencing to return a resource of an arbitrary Media Type.
The dereference function from DID Core is present in DID Resolution, with contentStream in the return type (along with the dereferencing metadata and content metadata) [5], although those terms are not discussed, they are specified in DID Core, and they can be understood here as the return values from the dereferencing algorithm [6]. The allowance for an arbitrary resource can be seen in the last step of Dereferencing the Secondary Resource [8] (which is the third and last step of Dereferencing a DID URL): "3) Otherwise, dereference the secondary resource as defined by the media type ([RFC2046]) of the primary resource"; that occurs after §4.2 Dereferencing the Primary Resource [7] (the second step of Dereferencing a DID URL) returns something other than a DID document; e.g. "3.1) The applicable DID method MAY specify how to dereference the input DID URL." The discretion given there to DID Methods for dereferencing DID URLs is, I think, consistent with DID Core which says "DID URL dereferencing implementations might map the dereference function to a method-specific internal function to perform the actual DID URL dereferencing process." [4].

> It's very specific about what can be in a returned DID
> Resolution Result:
> https://w3c-ccg.github.io/did-resolution/#did-resolution-result

The DID Resolution HTTP(S) Binding [9] returns that DID Resolution Result data structure when a DID URL dereferences to a DID document. The HTTP(S) Binding currently defines how to return a DID URL dereferencing result over HTTP(S) that dereferences to a DID Document, a service endpoint URL, and/or certain error cases. Perhaps the binding and/or that data structure could be expanded to support any DID URL dereferencing result - or maybe an additional data structure and/or binding would be needed for that. I've opened an issue about this, for the DID Resolution Result data structure at least [10]. In any case, other kinds of DID URL dereferencing results could be obtained via other concrete interfaces than the HTTP(S) binding. There are also examples of DID URL dereferencing results containing different kinds of things, in the DID Test Suite [11], which I've referenced in that issue [10].

Regards,
Charles E. Lehner

P.S. Is this discussion of sufficient relevance to Credentials, or should it be continued on another list, e.g. public-did-wg?

[1] https://wiki.trustoverip.org/display/HOME/DID+URL+Resource+Parameter+Specification#DIDURLResourceParameterSpecification-TheResourceParameter
[2] https://www.w3.org/TR/did-core/#dfn-did-url-dereferencers
[3] https://www.w3.org/TR/did-core/#did-resolution
[4] https://www.w3.org/TR/did-core/#did-url-dereferencing
[5] https://w3c-ccg.github.io/did-resolution/#dereferencing
[6] https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm
[7] https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm-primary
[8] https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm-secondary
[9] https://w3c-ccg.github.io/did-resolution/#bindings-https
[10] https://github.com/w3c-ccg/did-resolution/issues/69
[11] https://github.com/w3c/did-test-suite/tree/main/packages/did-core-test-server/suites/implementations

Received on Thursday, 30 December 2021 22:13:07 UTC