Drafts in progress are not _required_ to retain backwards compatibility with earlier work. While it's often better to do so, sometimes that's not the right call, and it's never a requirement.
-Justin ________________________________ From: Erin Shepherd <[email protected]> Sent: Sunday, May 31, 2026 5:55 PM To: Emelia S. <[email protected]> Cc: [email protected] <[email protected]> Subject: [OAUTH-WG] Re: Client-ID generalisation & sub/aud mixup attacks On Sun, 31 May 2026, at 22:08, Emelia S. wrote: > 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). Backwards compatibiltiy is a worthy goal, but if it were our only goal we'd all be storing NT-hashes of user passwords and authenticating people with NTLM and encrypting things with RC4. I think we'd all agree that the OAuth WG should not be creating multiple specifications that, when used together, create security vulnerabilities. > 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. I don't think that fixes anything; "https://example.com/foo"; is a valid issuer identifier (-> https://example.com/.well-known/oauth-authorization-server/foo, or a different path for OpenID Connect but we will ignore *that* wonkiness for now...). Requiring a ".json" postfix is certainly possible, and in practice probably alleviates issues, but certainly there is no rule that you cannot have dots inside the path components of issuer identifiers; it's not really a solid basis upon which to build. Fundamentally any HTTPS URL without a query or fragment component is a valid OAuth 2 or OpenID Connect issuer identifier, and I don't see a safe way any spec using HTTPS URLs as client identifiers can avoid dealing with potential confusion between the two. - 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]
