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.

[jandrieu]

This feels like an odd layer violation that really isn't applicable to how we use CID documents.

@pchampin wrote

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

I don't think that is correct, and probably not usable in the context that CIDs were invented: verifiable credentials.

VC proofs have a property verificationMethod that

references, via a URL, the location of the public key that can be used to verify the proof. This public key data is stored in a controlled identifier document, which contains a full description of the verification method."

(from the VC Data Integrity spec https://www.w3.org/TR/vc-data-integrity/#proofs)

In practice, that's a URL like this (from the CID spec)

   "verificationMethod": "https://university.example/issuers/14#key-1",

So, if your cannonical URL is https://example.org/my-cid-doc#me and it is only referenced in that manner, then how can you construct the URL that references a verification method in that document, e.g., #key-1.

Either you go with https://example.org/my-cid-doc#me#key-1 which is an invalid URL because there are two fragments
or you go with https://example.org/my-cid-doc#key-1 which violates the premise that you only use the #me full DID URL.

Which means I don't think this can work as proposed.

On the other hand, if you really want to use https://example.org/my-cid-doc#me, you can just add a node to the DID document with the id of "me" and that node in the JSON-LD will be correctly referred to, although we don't really have a standard property for you to place such a statement. So, I'm not sure that works either; it just surfaces the HTTPRange14 problem more clearly.

The problem is #me necessarily references the JSON node in the CID document with the ID #me. If you want to use that as a URI, that's fine, but if you dereference it, it refers to a node in the CID, not the CID document itself, which is what the cannonical URL, IMO, is supposed to do. Dereference the canonical URL, you get the CID document entire... not just a portion of it.

So, after thinking through how we might be able to make this usage pattern work, I just don't see how you. If you want to use it as URI, go ahead. But as soon as you dereference it, it is not going to be what I think you want.