Allow for fragment identifier in document.id

[pchampin]

This PR addresses #164 , and extends the current spec without any breaking change (any valid document remains valid).

As outlined in #164, the current spec does not allow the subject identifier to contain a fragment identifier, e.g. https://example.org/my-cid#me. This PR extends the conditions under which a Controlled Identifier Document is considered valid:

• before: the canonical URL of the Controlled Identifier Document must be equal to document.id
• after: the canonical URL of the Controlled Identifier Document must be equal to the document.id without fragment identifier

This is especially important for HTTP(S) based CIDs, where the use of a fragment identifier is common practice for distinguishing the document's identifier from the subject's identifier.

With this change, the following CID document, living at https://example.org/my-cid, would be valid (while currently it is not).

{
  "@context": "https://www.w3.org/ns/cid/v1",
  "id": "https://example.org/my-cid#me",
  "authentication": [{
      "id": "https://example.org/my-cid#authn-key-123",
      "type": "Multikey",
      "controller": "https://example.org/my-cid#me",
      "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}

cc @uvdsl

---

Preview | Diff

[uvdsl]

This is good. Backwards-compatible, minimal changes to the existing specification document, and easing adoption of CIDs in existing not-yet-CID-based systems. 👍

[w3cbot]

iherman marked as non substantive for IPR from ash-nazg.

[w3cbot]

pchampin marked as substantive for IPR from ash-nazg.

[TallTed]

@iherman @pchampin — Your (non)substantive switches are in conflict. Human-friendly notes would probably help move this in whatever is the correct direction.

[iherman]

@iherman @pchampin — Your (non)substantive switches are in conflict. Human-friendly notes would probably help move this in whatever is the correct direction.

I made a mistake, that is all. Furthermore, the original ash-nazg reaction has become moot, since @pchampin has officially joined the WG.

[iherman]

This was discussed during the vcwg meeting on 20 May 2026.

View the transcript

w3c/cid#168

Manu: one that is ready that Pierre-Antoine opened trying to qualify what the primary identifier is, one where I would appreciate more reviews on PR before merging. Don't think it harms anything, would also address one or two issues there

Manu: this PR is about allowing for fragment identifier in DID Document ID
… we are introducing this new term "primary identifier" and the primary identifier in a controlled identifier document, needs to be something without a fragment
… url of document, document ID must not contain a fragment
… primary identifier must be the same as the canonical
… don't put a fragment in document ID, want to make sure other people think algorithms make sense
… think it was confusing in previous working group

<Zakim> JoeAndrieu, you wanted to say it sounds backwards

<dlongley> +1 to Joe

JoeAndrieu: manu, seems like what you said is opposite of this PR
… okay to have fragment

Manu: think you are right, that would be bad

Ivan: so, I can fully understand where he is coming from, whether we like it or not, using fragment ID has been around and used for last 25 years, very often can even see formal ID of TBL
… presume request came from solid working group (name today?) looking at CID as a tool for themselves, use case community that would like to use fragments. Whether we answer it or not is a different case

Brent: with the realization we were looking at this backwards, what are comments? We have the Issue, believe Issue links to conversation, I'm not super familiar with conversation in LWS

<Zakim> JoeAndrieu, you wanted to say it feels off

<dlongley> +1 to Joe ... i think this just needs careful consideration ... and comparison against what the DID spec does for compatibility, etc.

JoeAndrieu: I think this feels a bit off, part of hesitation is simply not having had time to understand if there is something deeply wrong with why it feels off
… confusing if there there a fragment that is not #me, don't know how that even works in a JSON-LD framework
… naive solution would be to take ID and append secondary fragment, now we have two fragments and that fees wrong

Manu: apologies, totally misrepresented PR, read through it twice
… http range 14 conversation that never dies, reading through with that understanding
… do admit that it is going to be hard to justify not allowing a fragment identifier in the CID document
… Joe, agree it feels off, always fall on other side of range 14 conversation
… type of resource tells you what it is point toward
… but group of people that will never agree, fear is that we get pulled into a range 14 discussion
… don' think this breaks anything, but need to be very very careful with this PR
… now three different terms we use in spec to talk about URLs for document itself
… base identifier, primary identifier, canonical URL, and each of those means something a bit different

<dlongley> needs a little security analysis for things like how comparing controllers when resolving verification methods changes, etc.

Manu: just a warning it is HTTPRange 14 territory, keep in mind while reviewing. But to agree with Ivan, that community agrees that there should be hash identifiers on these IDs
… don't know if there is any big problem adding this feature, but ramifications are pretty broad

Benjamin: I don't think I'd be quite as HTTP range 14, think it is clarifying something that isn't clarified now
… its permitted now, can put fragment identifiers in all of these URLs

Joe: not permitted now

bigbluehat: in CID spec, fragment identifier can appear?

Manu: no, specifically banned that

Manu: long discussion, fragment IDs not allowed
… think that as always range 14 issues seem simple, but not
… allows a different level of attacks, made us not feel great about security attack surface

<Zakim> manu, you wanted to note it's not as straightforward as it seems.

Manu: if we are going to allow people to use fragment idenfiers, how does it change ??? could it be used as an attack vector to use key or object mix-ups, all these things come up when we allow this

<dlongley> +1 it might end up being ok, but requires more analysis.

Manu: may be okay, but need to look at Data Integrity spec and se how it it is used
… never really used CID spec directly, they would be the first ones really using the spec

Bigbluehat: I think one of the things triggering the range 14 bits is the section using hash me, but that could be any identifiable thing with a fragment, is a JSON-LD document
… so I think it is maybe okay, but we should dig into whether it is actually before we do the wrong thing

<Zakim> manu, you wanted to note it is not always a JSON-LD document.

<ivan> +1, it is also used that way in my own foaf file

Manu: just to highlight why this seems simple - not always JSON-LD document, people who worked on this spec wanted to be able to use it without JSON-LD, so algorithms are not always straightforward

<Zakim> JoeAndrieu, you wanted to ask where in the spec is the fragment outlawed

Brent: that is PR 168, let's look at our Issues now
… did someone just go through and put a bunch of class II and Class IV from these?

Manu: yes

---