w3c
Address reference to internet draft [HASHLINK]
[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 https://github.com/w3ctag/design-reviews/issues/1157#issuecomment-3439062470
This is in the query parameters table for the hl parameter - https://www.w3.org/TR/did-resolution/#did-parameters
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.
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."?
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://
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://
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.
Consensus from the group is to remove this parameter and add it to the extensions if it isn't already there.
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.