Address reference to internet draft [HASHLINK]

[wip-abramson]

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

From w3ctag/design-reviews#1157 (comment)

[wip-abramson]

This is in the query parameters table for the hl parameter - https://www.w3.org/TR/did-resolution/#did-parameters

[wip-abramson]

The hl parameter section states that is is non-normative. However, it does use normative language after that statement, we may want to clean that up:

A resource hash of the DID document to add integrity protection, as specified in [HASHLINK]. This parameter is non-normative. If present, the associated value MUST be an ASCII string.

[TallTed]

This parameter is non-normative.

I don't know what this was meant to say.

The description of this parameter might be non-normative, in which case, yes, the normative RFC2119 language that follows should be changed.

Perhaps it was meant to say "This parameter is OPTIONAL."?

[w3cbot]

This was discussed during the #did meeting on 06 November 2025.

View the transcript

w3c/did-resolution#229

ottomorac: This is related to hash link.

<Wip> https://www.w3.org/TR/did-resolution/#did-parameters

wip: We reference hash link for the hl query parameter, but it's not part of the spec, so I don't think we can reference it.

Ivan: In 3.2.1 of DID Core, it explicitly says that DID parameter is non-normative. I think that it refers to the fact that hash link is a moving target.

wip: I think maybe that didn't get copied across.

<ivan> see https://www.w3.org/TR/did-1.0/#did-parameters, the table with "Parameter Name Description"

wip: We moved it to DID Resolution, it shouldn't exist in DID Core.

JoeAndrieu: One of the problems of this section is that one part says it's non-normative, but include normative language.
… I think the response to Jeffrey is that it's a non-normative section and should be rewritten.

wip: I'll do that.

---

[wip-abramson]

Consensus from the group is to remove this parameter and add it to the extensions if it isn't already there.

[w3cbot]

This was discussed during the #did meeting on 11 November 2025.

View the transcript

w3c/did-resolution#229

wip: we have discussed this - I want to clarify this is about hash link when we discuss this before we caviat this the base parameter is non-normative. Every single did parameter is optional in the spec

wip: we explicitly this is a non-normative parameter so what do we say

JoeAndrieu: this is more about culture and style of W3C I don't have a problem referencing standards not by formal standards organization - so we can't reference bitcoin primatives - I don't know how we deal with this

manu: I should drop the parameter - I don't think we have the time to figure out hashlink... - I don't think any one is using it.

TallTed: I believe there is a way to cite and RFC draft from a rec but I would have to dig a lot to find it. I'm pretty sure a group I am involved with did it - given it was an optional parameter and no one was fighting to use it - no reason folks can't use it without in the spec.

manu: not fully baked - not implementations - not tests - lets cut it.

<TallTed> My original point was that "This parameter is non-normative" is nonsensical.

markus_sabadello: agree with feature found useful in conversations - this topic comes up - sometimes. Yes this exists as possibility. in practice it is not implemented

phila: you can refer to whatever you like - just don't make it "normative" "one way to do this might be to look at this document over here" just can't make it normative.

JoeAndrieu: As currently implemented our extensions registry gets around this - we have extensions not referenced anywhere

JoeAndrieu: move into extensions registry - optional - is it normative.

wip: this is good because there is another issue

wip: who wants to do this

manu: I will do this

wip: thank you everyone.

---

[msporny]

PR #262 has been raised to address this issue. This issue will be closed if that PR is merged.