Omit `client_id` from client metadata document?

[jogu]

Current spec says:

The client metadata document MUST contain a client_id property whose value MUST compare and match the URL of the document using simple string comparison as defined in [RFC3986] Section 6.2.1.

I'm not sure of the reason this text is here, so perhaps there's a good reason?

There's definitely an argument against including client_id in the metadata document though. We've seen that implementations of https://datatracker.ietf.org/doc/html/rfc8414 often just blindly trust the issuer value in the metadata document, without verifying it matches the location they retrieved it from. Omitting client_id (by requiring it is not be present and must be ignored if present) from the metadata document sort of completely removes the possibility to do that.

The only downside I can think of is that if the metadata document is somehow getting exposed at multiple urls (https://example.com/client.json and https://www.example.com/client.json for example) then both would end up being valid client ids. I'm not sure if that's bad though?

[ThisIsMissEm]

This property matching prevents many rehosting attacks or using redirects to mislead users. It is a key requirement in this specification.

[jogu]

This property matching prevents many rehosting attacks or using redirects to mislead users. It is a key requirement in this specification.

Omitting client_id from the metadata document and matching the one in the authorization request to the location the file is retrieved from also prevents those attacks though I think - could you give a specific example of an attack please?

(I'm not sure I understand the problem with redirects - is there a situation where we expect the attacker to be able to create redirects for some particular url but not create a file from that same url? I think the redirects case is actually undefined in the current spec, I don't see anything that says if redirects should be followed or not / if they are followed I'm not sure if it's the original requested url or the final one that should be considered the "url of the document was")

In practice in the OAuth world we've seen similar checks to the one for this value being implemented very poorly or not at all, so if it's a critical security mechanism that's bad. The only slight advantage here is that this value is being checked by the AS so there's at least fewer of them compared to clients...