Re: [w3ctag/design-reviews] WG New Spec: DID Resolution (Issue #1157)

wip-abramson left a comment (w3ctag/design-reviews#1157)

Hi @lolaodelola, apologies for the delay. We have addressed all but two of the points raised by @jyasskin. See below.

Some of the comments led the group to make extensive changes to the DID URL Dereferencing algorithm. These changes are still ongoing and we will let you know as soon as it is complete. It has not yet had TAG review. Thanks.

## Abstract

- Nit in the [Abstract](https://www.w3.org/TR/did-resolution/#abstract): there's a fairly grand description of what DIDs are meant to do, but mechanically, I think they're just a kind of URL that's guaranteed to resolve/dereference to a DID Document ... and this specification defines how that dereferencing works. Would it make sense to keep the abstract a little more grounded?
- There are references to both DID v1.0 and v1.1. The document should probably pick just one.

Both addressed here: https://github.com/w3c/did-resolution/pull/270

## [Introduction](https://www.w3.org/TR/did-resolution/#introduction):

- The use of "resolution" here seems inconsistent with other uses. In particular, I don't think it's "the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI" from https://www.rfc-editor.org/rfc/rfc3986.html#section-1.2.2, and it's not "the process of resolving a URI reference within a context that allows relative references so that the result is a string matching the <URI> syntax rule" from https://www.rfc-editor.org/rfc/rfc3986.html#section-5 (which is also used in https://www.w3.org/TR/did-1.1/#relative-did-urls). Is it the right term? Perhaps you're just defining how to "dereference" both DIDs and DID URLs?

Addressed: https://github.com/w3c/did-resolution/pull/318.

- There's a note that 'The difference between "resolving" a DID and "dereferencing" a DID URL is being thoroughly discussed', but the link doesn't point to a comment that discusses it. This should be resolved before publication.

Addressed: https://github.com/w3c/did-resolution/pull/245

## [Implementer Overview](https://www.w3.org/TR/did-resolution/#implementer-overview):

- This says "resolve did:example:123?versionTime=2021-05-10T17:00:00Z", but that's a DID URL, not a [DID](https://www.w3.org/TR/did-1.1/#did-syntax) (because DIDs don't contain ? characters), so it's not in the domain of the resolution function.

Addressed: https://github.com/w3c/did-resolution/pull/266

## [Terminology](https://www.w3.org/TR/did-resolution/#terminology):

- It would be ideal if this didn't duplicate definitions from other specs like https://www.w3.org/TR/did-1.1/#terminology. But I think there are technical reasons you have trouble deduplicating, perhaps that webref can't distinguish DID-ish terms from web platform terms well enough.

Addressed: https://github.com/w3c/did-resolution/pull/285

## [DID Parameters](https://www.w3.org/TR/did-resolution/#did-parameters):

- Should this live in DID-core? It seems to set new requirements on all DID Methods, that they don't define conflicting meanings for these parameters, which aren't currently reserved in the definition of Methods.

Response: No, the parameters are part of the DID URL and impact DID Resolution and Derferencing. Different DID Methods and DID URLs may use different parameters, this spec defines how to process them consistently. Therefore we moved this section from DID Core to DID Resolution during this WG.

- "MUST use percent-encoding for certain characters" is vague: which characters?

Addressed: https://w3c.github.io/did-resolution/#percent-encoding-normalization

"MUST be normalized to UTC 00:00:00" isn't an operation I recognize. Does this mean that it must have a timezone offset of 00:00?

Addressed: https://w3c.github.io/did-resolution/#datetime

- [HASHLINK] is an Internet-Draft, so might violate https://www.w3.org/guide/process/tilt/normative-references.html. There has been work on content digests since 2021, in particular in https://datatracker.ietf.org/doc/html/rfc9530 and https://www.ietf.org/archive/id/draft-ietf-httpbis-unencoded-digest-01.html. Consider if the &hl parameter needs to incorporate ideas from one of those.

Removed hl parameter from spec: https://github.com/w3c/did-resolution/pull/262

This says "use the DID Document Properties Extensions mechanism", which seems like a Registry sort of thing, but it's not using the W3C or IANA registry mechanisms. Should it?

Response: The group discussed making this a W3C Registry and in an ideal world we probably would. However, we determined it was not top priority and given the available resources have not managed to do so. In a future WG we will revist this.

"DID parameters might be used if there is a clear use case where the parameter needs to be part of a URL that references a [resource](https://www.w3.org/TR/did-resolution/#dfn-resources) with more precision than using the [DID](https://www.w3.org/TR/did-resolution/#dfn-decentralized-identifiers) alone." is hedgy ... this should probably be a SHOULD, and I think the note below this is a good description of what should be recommended.

Unaddressed, tracking: https://github.com/w3c/did-resolution/issues/341

## [DID Resolution](https://www.w3.org/TR/did-resolution/#resolving):

- This refers to 'the "Read" operation of the applicable [DID method](https://www.w3.org/TR/did-resolution/#dfn-did-method-s) as described in [Method Operations](https://www.w3.org/TR/did-core/#method-operations)', but https://www.w3.org/TR/did-core/#method-operations doesn't mention the word "Read". What's the signature of that operation?

Addressed: https://github.com/w3c/did-resolution/pull/271. Note: there is no signature of the now "Resolve" operation. The purpose of the DID Resolution spec is to create a common abstraction over many different method specific Resolve operations.

- It would be ideal if the definition of didDocument referred to https://www.w3.org/TR/did-1.0/#data-model, which actually defines DID documents.

Addressed: https://github.com/w3c/did-resolution/pull/249

- "match" is a yellow flag in specifications. Does this mean that it must be the same string, or does it use some other matching algorithm?

Addressed: https://github.com/w3c/did-resolution/pull/249

- didDocument says "MUST be a DID document that is capable of being represented", but https://www.w3.org/TR/did-resolution/#did-resolution-options says "The DID resolver implementation SHOULD use this value to determine the representation of the returned didDocument", which implies that the resolver is returning a serialized document rather than a parsed one. Which is it?

Addressed: https://github.com/w3c/did-resolution/pull/257

## [DID Resolution Metadata](https://www.w3.org/TR/did-resolution/#did-resolution-metadata):

- The definition of proof includes, "the value MUST be a [set](https://infra.spec.whatwg.org/#sets) where each item is a [map](https://infra.spec.whatwg.org/#maps) that contains a proof". Maps hold key/value pairs, so it doesn't make sense for a map to "contain a proof". I also don't see a definition of the proofs these maps are supposed to hold.
[DID Document Metadata](https://www.w3.org/TR/did-resolution/#did-document-metadata)

Addressed: https://github.com/w3c/did-resolution/pull/250

- "A conforming [DID method](https://www.w3.org/TR/did-resolution/#dfn-did-method-s) specification MUST guarantee" <- Requirements on DID methods ought to live in DID core, not this document.

Tracking: https://github.com/w3c/did/issues/911

- Same problem with the proof field as in the Resolution Metadata.

Addressed: https://github.com/w3c/did-resolution/pull/250

## [DID Resolution Algorithm](https://www.w3.org/TR/did-resolution/#resolving-algorithm):

- "against the input [DID](https://www.w3.org/TR/did-resolution/#dfn-decentralized-identifiers)'s [verifiable data registry](https://www.w3.org/TR/did-resolution/#dfn-verifiable-data-registry)" is probably unnecessary. If it is necessary, you'll need to specify how to find the "verifiable data registry".

Addressed: https://github.com/w3c/did-resolution/pull/263

- "This result MUST be represented in a [conformant representation](https://www.w3.org/TR/did-core/#representations) that corresponds to the accept input [DID resolution option](https://www.w3.org/TR/did-resolution/#did-resolution-options)." conflicts with the definition of that accept option, which only says it "SHOULD use this value to determine the [representation](https://www.w3.org/TR/did-resolution/#dfn-representations)".

Addressed: https://github.com/w3c/did-resolution/pull/257

- "Iterate over all [services](https://www.w3.org/TR/did-core/#services), [verification methods](https://www.w3.org/TR/did-core/#verification-methods), and [verification relationships](https://www.w3.org/TR/did-core/#verification-relationships)" <- Does this need to also iterate over any [extensions](https://www.w3.org/TR/did-1.0/#extensibility) in the document?

Yes, addressed: https://github.com/w3c/did-resolution/pull/299

[Resolver Architectures](https://www.w3.org/TR/did-resolution/#resolver-architectures):

- "This inclusion can potentially enable a [client](https://www.w3.org/TR/did-resolution/#dfn-client) to independently verify the results of a [DID Resolution](https://www.w3.org/TR/did-resolution/#dfn-did-resolution) process, as long as it trusts the [DID resolver](https://www.w3.org/TR/did-resolution/#dfn-did-resolver-s)." doesn't sound like much of a proof if it requires the resolver to be trusted.

Addressed: https://github.com/w3c/did-resolution/pull/295





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1157#issuecomment-4693142784
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1157/4693142784@github.com>