Hi Erin, As I think I mentioned on GitHub when you first reported this, the reason CIMDs don't use .well-known is because we need to support CIMDs that were issued prior to this draft specification (backwards compatibility with Solid OIDC, which is the foundation for the draft). The CIMD client_id URL must also have a non-empty path segment, so it cannot be https://example.com/ instead it would need to be https://example.com/example-client-id.json
> This specification defines the client identifier as a URL with the following > restrictions. Client identifier URLs MUST have an "https" scheme, MUST > contain a path component, MUST NOT contain single-dot or double-dot path > segments So I don't think the attack you're describing is possible within the current draft. We do have an issue open to require a .json extension (I forget where), as well as recommending the usage of /oauth-client-metadata.json as a go-to. However, we need to retain the any-path segment in order to support currently deployed CIMDs and Solid OIDC client identifier documents. Yours, Emelia > On 31 May 2026, at 21:45, Erin Shepherd <[email protected]> wrote: > > As I hope is well known in this group, In various OAuth 2 contexts, the > subject of a token (either a JWT or something introspectable) can be > > A User ID, or > A Client ID > The audience can be > A Client ID (OIDC ID Token) > A Resource Indicator (Access token) > Another AS' Issuer Identifier (Identity Chaining) > Typically resource indicators (or their paths) are pre-registered with an AS. > Typically (though not necessarily) association establishment between two ASes > is also restricted. Regardless `/.well-known/oauth-authorization-server` and > `/.well-known/oauth-protected-resource` can be reasonably said to be within > the same security domain and it could also reasonably be siad that both > represent the same entity. > > Client and User IDs are typically not URIs and therefore there is no risk of > conflict. If they are URIs, typically those URIs would be alocated by the AS. > The Security BCP calls out the need to avoid conflicts between User IDs and > Client IDs, though says nothing about confusion between those resource or > issuer identifiers. > > As I mentioned in issue 76 > (https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/76) > on the CIMD draft, I believe there is a security risk here whereby it > enables confusion between issuer identifiers and client identifiers (there is > perhaps a similar risk of confusion between resource identifiers and client > identifiers, though I am not sure it is feasible): > > The org example.com run an IDP at https://auth.example.com/, with issuer > identifier https://example.com/ > example.com redirects https://example.com/.well-known/* to > https://auth.example.com/.well-known/, to satisfy the OAuth2 / OpenID Connect > Metadata requirements > example.com has established an identity chaining relationship with the IDP at > example.net. example.net also supports CIMD. > An attacker manages to find a vulnerability in the web application at > example.com, and uses it to place a CIMD document at https://example.com/. > The attacker cannot manipulate the .well-known directory, because the > redirection is handled by a (more secure/trusted) reverse proxy or similar. > Such an attack can be largely silent, by distinguishing between web browser & > CIMD fetch requests > The attacker triggers an authentication at example.net with the client ID > https://example.com/, triggering CIMD usage. This results in issuing of an > OIDC ID token with `{"iss": "https://example.net/";, "aud": > "https://example.com/";, "sub": "<user>"}` > The attacker uses this in an identity chaining request at example.com's IDP. > I believe there is a risk of other security vulnerabilities resulting from > confusion between the Client and AS, especially if the identifier gets > serialized to a string and back > > I don't really see a fix unless either (a) the CIMD is put under .well-known, > or (b) a prefix is added to the client-ID-URL (in the same way as OpenID4VP > is doing) > > (I quite like the .well-known option, actually; there are many reasons for an > IDP to be all three of an AS, client and RS and it brings nice symmetry to > the definitions there; but I also realise it may not be the ideal option for > a lot of uses of CIMD does not constrain the URL in this way) > > Additionally, I raise this here on the mailing list because I wonder if there > should perhaps be some kind of informative document to warn people around the > hazards of identifier mixups when extending the protocol. In many ways this > is less a direct CIMD bug and more a result of the haphazard evolution of the > OAuth 2.0 ecosystem, which needs to be considered in future extensions. > > In retrospect I believe we should not have had > "/.well-known/oauth-authorization-server", but instead "/.well-known/oauth" > with an "as" subkey, but that is water under the bridge at this point. OpenID > Federation probably has the right idea with the "federation entity" > terminology... > > - Erin > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
