Base identifier including a fragment

[pchampin]

Section 2.1.1 says

The returned document's base identifier MUST be the same as the canonical URL; if it is anything else, then the returned document is not an authoritative controlled identifier document and the identifier SHOULD be treated as invalid.

There is a case to be made for situations where the base identifier is of the form canonical_URL + "#" + fragment_identifier. In particular, this is one of the options suggested by [COOLURIS] to avoid the conflation between identifying an arbitrary subject (person, organization) and identifying the HTTP resource describing this subject.

Would it be possible for the next version of this spec to be more flexible in that requirement, namely, to recognize as valid a CID if it follows this pattern?

[kaefer3000]

The conflation was also raised by @melvincarvalho in w3c/lws-protocol#57 (comment) .

[pchampin]

I realize that there is another way to look at this issue: if my CID document lives at https://example.org/my-cid-doc , and its id attribute is https://example.org/my-cid-doc#me, then can I use https://example.org/my-cid-doc#me as the canonical URL of my CID document, i.e., only sharing the URL with the fragment identifier, never the one without it...

Sure, during dereferencing, the fragment identifier will be dropped, but this can be seen as an implementation detail, just like potential redirections.

Question to the editors (and the rest of the WG): is an HTTPS URL with a fragment identifier a valid choice for the canonical URL of my CID document?

edited this actually does not work, see below

[TallTed]

Question to the editors (and the rest of the WG): is an HTTPS URL with a fragment identifier a valid choice for the canonical URL of my CID document?

Yes.

[mwherman2000]

Datapoint: RFC 8141 (URNs) (https://datatracker.ietf.org/doc/html/rfc8141#section-3.2) states that the fragment is not to be considered when comparing 2 URNs for equivalence. ...food for thought.

(From above...)
@iherman I believe your statement is a contravention of the IETF URI/URL RFCs: https://chatgpt.com/s/t_69c6a262f0308191b36929ebf9cf9e39

p.s. There's 3 levels of DID Equivalence and their definitions are missing from the DID spec: https://chatgpt.com/s/t_69c6a50a55e881919ffaff63d9305ffb

This makes DID Equivalence non-deterministic/not trustworthy - unless you to chose to rely on the URI/URL RFC definitions (which you are not doing).

[iherman]

We are in the realm of JSON-LD, ie, Linked Data, ie, RDF, with regard of a URL used as an identifier. In that world, using identifiers with fragment is common practice, ie, different fragments yielding different id values.

[mwherman2000]

@iherman I believe your statement is a contravention of the IETF URI/URL RFCs: https://chatgpt.com/s/t_69c6a262f0308191b36929ebf9cf9e39

p.s. There's 3 levels of DID Equivalence and their definitions are missing from the DID spec: https://chatgpt.com/s/t_69c6a50a55e881919ffaff63d9305ffb

This makes DID Equivalence non-deterministic/not trustworthy - unless you to chose to rely on the URI/URL RFC definitions (which you are not doing).

[kaefer3000]

No it is not a contravention. RDF uses URIs as identifiers, and term equality (i.e. string equality disrespective of networking aspects) counts here, see https://www.w3.org/TR/rdf11-concepts/#dfn-iri-equality . I do not see a contradiction to your prompted source.

[mwherman2000]

The final answer is mixed...it is unfortunate that fragments aren't handled consistently by our current specifications (and IMO CIDs are furthering this inconsistency):

https://claude.ai/share/d39809a1-347d-4072-8d08-3742a3f90508

[mwherman2000]

The final final answer is relatively concise (from a First Principles perspective): https://claude.ai/share/9a791ae5-2d6c-4ca5-8dfc-c5b85dc51fe7

The RFC is actually making one coherent point across both paragraphs:
Fragments are special — they exist outside the server's purview, so they're excluded from retrieval comparison; but they are real syntactic components, so they can't be silently normalized away from identity comparison.

The key variable is what kind of comparison you're doing.

In JSON-LD and VC contexts, IRIs are almost always used as identity tokens, not retrieval instructions. So ¶4's rule dominates:
https://w3id.org/security#proof and https://w3id.org/security are different things — one names the proof property, the other names the vocabulary itself.

A did:drn:abc123#key-1 and did:drn:abc123 are different identifiers — the fragment one names a specific verification method within the DID Document, not the DID subject itself.
An empty trailing # on a context IRI could silently break term resolution in a JSON-LD processor, because the processor uses simple string comparison against the @context map.

So the two paragraphs carve out two non-overlapping domains — network protocol vs. identity semantics — and apply different rules to each. No contradiction; just context-sensitivity

[mwherman2000]

Digging deeper:

1. https://claude.ai/share/9a791ae5-2d6c-4ca5-8dfc-c5b85dc51fe7
2. https://claude.ai/share/9a791ae5-2d6c-4ca5-8dfc-c5b85dc51fe7

[pchampin]

I realize that there is another way to look at this issue: if my CID document lives at https://example.org/my-cid-doc , and its id attribute is https://example.org/my-cid-doc#me, then can I use https://example.org/my-cid-doc#me as the canonical URL of my CID document, i.e., only sharing the URL with the fragment identifier, never the one without it...

Sure, during dereferencing, the fragment identifier will be dropped, but this can be seen as an implementation detail, just like potential redirections.

Question to the editors (and the rest of the WG): is an HTTPS URL with a fragment identifier a valid choice for the canonical URL of my CID document?

Responding to my own question: this actually does not work, because there are places where the canonical URL is computed by trimming the fragment from another URL (e.g. in the Retrieve Verification Method algorithm).

In fact, it seems to be assumed that the base identifier never contains a fragment, for example in Step 3 of the Fragment Resolution algorithm...

Thanks to @acoburn for pointing that out to me. I will try to propose a PR to be considered for a future version a CID.