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.