Authentication of a CID

[silverpill]

In the subjects section:

Dereferencing the canonical URL MUST return the current authoritative controlled identifier document. 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.

"the identifier SHOULD be treated as invalid" sounds ambiguous. The base identifier of a retrieved document may be valid (we can retrieve it again and may get a matching CID). In this case only canonical URL is invalid.

Also, I think this SHOULD need to be replaced with a MUST. If the base identifier doesn't match the canonical URL (especially if they have different web origins), that may be an impersonation attempt.

[msporny]

The base identifier of a retrieved document may be valid (we can retrieve it again and may get a matching CID). In this case only canonical URL is invalid.

Note that the language says that "dereferencing the canonical URL" has to result in a document with the canonical URL in there. This was done to ensure that a redirect is possible, and a re-attempt (as you mention) can be performed. However, once that re-attempt is made for what is believed to be the canonical URL, that final check MUST succeed. That is, the second you stop getting redirect hints through whatever protocol you're using (like 301 redirects), and once you believe you're at the final document, you need to ensure you're dealing w/ a canonical URL.

Also, I think this SHOULD need to be replaced with a MUST. If the base identifier doesn't match the canonical URL (especially if they have different web origins), that may be an impersonation attempt.

We considered that, but felt like the spec is too new to do that sort of hard enforcement and that we wanted to depend on implementer experience over the next couple of years before we lock it down. There might be legitimate reasons to not throw an error (like you know the document is out of date, but you've deemed that to be ok for some reason).

All this said, I don't think we'd change the normative text at this point for the reason above.

Can you suggest some text that might address your concern?

[silverpill]

That is, the second you stop getting redirect hints through whatever protocol you're using (like 301 redirects), and once you believe you're at the final document, you need to ensure you're dealing w/ a canonical URL.

Thank you for clarification. I think the bit about redirects is important to get right and additional text would help implementers understand this requirement:

The returned document's base identifier MUST be the same as the canonical URL (the final URL in the chain of redirects);

However, I still don't understand what "the identifier" refers to at the end of the sentence:

if it is anything else, then the returned document is not an authoritative controlled identifier document and the identifier SHOULD be treated as invalid.

Perhaps it was meant to be "and the document SHOULD be treated as invalid", or "and the base identifier SHOULD be treated as invalid"?

We considered that, but felt like the spec is too new to do that sort of hard enforcement and that we wanted to depend on implementer experience over the next couple of years before we lock it down.

ActivityPub protocol is very similar in this regard. AP documents have an id property, and when document URL is dereferenced, software must verify that the final location in the chain of redirects matches the document id. Failure to do so leads to severe vulnerabilities, see GHSA-3fjr-858r-92rw for example.

There might be legitimate reasons to not throw an error (like you know the document is out of date, but you've deemed that to be ok for some reason).

My experience with ActivityPub tells me that such legitimate reasons don't exist, but if they do exist, they should probably be listed.

[selfissued]

Since this is a security validation process, the current "MUST" is appropriate. I'm OK adding additional text describing conditions when the MUST might not be satisfied, but I'm not OK for the document to be considered valid when it is not.

[iherman]

The issue was discussed in a meeting on 2025-01-22

• no resolutions were taken

View the transcript

2.2. Authentication of a CID (issue cid#141)

See github issue cid#141.

Ivan Herman: the next is on CID.
… manu, this is probably another one for you.

Manu Sporny: this issue is related to fediverse and ActivityPub use.
… JoeAndrieu you added something about base identifier and canonical identifier.
… when you get a CID value back it has an id value. That is supposed to match the URL you got the document from.
… we say that if that is not the case, then the document should be treated as invalid.
… the request is to make that a MUST.
… we did not do that earlier because there may be cases where it is valid for them not to match.
… such as the document being retrieved from cache even when the document is gone.
… or if query parameters, etc.
… so we avoided MUST language and used SHOULD language.
… so a further suggestion was to describe those cases.
… for the group: do we want to make this a MUST?
… if not, do we want to describe cases where these may not match?

Michael Jones: this is a security validation feature, so those should be MUSTs.
… we could informatively describe where that MUST would not be enforced.
… or we could say MUST...UNLESS...

Dave Longley: I think that MUST...UNLESS... construct is what is in there now, actually...just with different words.
… it is conditional.
… in the unless case we say you should treat it as invalid.

Michael Jones: that sounds like it's already addressed then.

Manu Sporny: I agree, this is already addressed.
… do we want to describe the scenarios where it might be OK for them not to match?
… like trusting a cache?

Ivan Herman: is it a major amount of work?

Manu Sporny: it's about a paragraph.

Ivan Herman: well in that case!!

Manu Sporny: I'll raise that PR.

Ivan Herman: and everyone will be absolutely happy.

[iherman]

The issue was discussed in a meeting on 2025-02-06

• no resolutions were taken

View the transcript

4.2. Authentication of a CID (issue cid#141)

See github issue cid#141.

Brent Zundel: might just be a small editorial change.

Manu Sporny: you're just waiting on me to raise a PR.

Brent Zundel: that's it. the rest are tracking issues.

[msporny]

PR #149 has been raised to address this issue. This issue will be closed once PR #149 has been merged.