That is one of option I discussed with Arndt and raised as an AOB point in the last OAuth WG meeting at IETF 124.
Jean-François “Jeff” Lombardo | Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité Principal Solution Architect, Security Specialist Montréal, Canada Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. From: Pieter Kasselman <[email protected]> Sent: February 20, 2026 12:06 PM To: Takahiko Kawasaki <[email protected]> Cc: oauth <[email protected]> Subject: [EXT] [OAUTH-WG] Re: Client ID for Client Authentication using X509-SVID CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. Thanks for raising this Takahiko. I want to confirm I understand the use case. From what you describe, I think you're suggesting that the desired state is for a client to authenticate with a SPIFFE credential, while using a different client_id (potentially an https:// or other identifier), and that this could potentially be addressed by including additional metadata in CIMD? Cheers Pieter On Fri, Feb 20, 2026 at 4:33 PM Takahiko Kawasaki <[email protected]<mailto:[email protected]>> wrote: Hi Emilia, Thank you for your response. Client IDs and client authentication methods should be orthogonal. A CIMD client can have a client ID of "https://example.com/client.json";, and the client metadata document may contain the following metadata to indicate that the client uses OAuth SPIFFE Client Authentication with JWT-SVIDs (assuming that spiffe_jwt represents the client authentication method): "token_endpoint_auth_method": "spiffe_jwt" This is how CIMD and SPIFFE Client Authentication coexist. If we avoid introducing the requirement that the client ID must start with spiffe://, we would not need to take the extra step of replacing spiffe:// with https:// inside the client ID. Individual deployments are free to decide to use client IDs that start with spiffe://, but it is undesirable for a client authentication method to impose constraints on the format of client IDs. If a mechanism functions correctly without such a restriction, it is better for a standard not to impose one. Implementer of OpenID Federation, CIMD, various client authentication methods Taka @ Authlete OpenID Federation - https://www.authlete.com/developers/oidcfed/ CIMD - https://www.authlete.com/developers/cimd/ OAuth 2.0 Client Authentication - https://medium.com/@darutk/oauth-2-0-client-authentication-4b5f929305d4 On Sat, Feb 21, 2026 at 12:33 AM Emelia S. <[email protected]<mailto:[email protected]>> wrote: Hi all, So OAuth SPIFFE Client Authentication does not conflict with OAuth Client ID Metadata or OpenID Federation 1.0, since different protocols are used https:// vs spiffe:// That allows both to co-exist in an authorization server. It's OAuth Client ID Metadata and OpenID Federation 1.0 that conflict (but you almost certainly wouldn't deploy them together due to different security/trust models), as they both use https:// URIs, so you can't differentiate between them without trying to fetch, but they have different fetch semantics (iirc). I'm basing this response on the example in https://arndt-s.github.io/oauth-spiffe-client-authentication/draft-ietf-oauth-spiffe-client-auth-00/draft-ietf-oauth-spiffe-client-auth.html#section-3.2.1 An AS can look at the client_id and go "this starts with https:// therefore I'll use CIMD" or "this starts with spiffe:// so I'll use OAuth SPIFFE Client Authentication", just like how you can deploy CIMD and DCR/Static Registration on the same AS, as long as DCR would never generate a client_id starting with https:// (which should never happen for most id generation schemes) If SPIFFE Client Authentication does not require the spiffe:// protocol scheme, and uses https:// then yes, they would be incompatible. I'd recommend keeping the spiffe:// scheme — perhaps a resolution step is "replace spiffe:// with https:// in the client_id" Yours, Emelia Smith CIMD Co-author On 20 Feb 2026, at 16:04, Takahiko Kawasaki <[email protected]<mailto:[email protected]>> wrote: Hello, It appears that issues posted to the issue trackers under the management of https://github.com/oauth-wg/ are automatically shared with the OAuth WG mailing list. However, since it is unclear whether issues posted to the OAuth SPIFFE Client Authentication issue tracker under arndt-s's account are also automatically shared with the OAuth WG, I am posting the same content here as well. SPIFFE-CLIENT-AUTH ISSUE 29: Client ID for Client Authentication using X509-SVID https://github.com/arndt-s/oauth-spiffe-client-authentication/issues/29 In draft 00 of OAuth SPIFFE Client Authentication, when using Client Authentication with X509-SVID, it requires that the value of the client_id request parameter be the SPIFFE ID. However, I believe this requirement should be removed. The reasons are as follows: - Systems that use the OpenID Federation 1.0 specification cannot use OAuth SPIFFE Client Authentication. - Systems that use the OAuth Client ID Metadata Document specification cannot use OAuth SPIFFE Client Authentication. - Systems in which client IDs cannot be flexibly changed cannot use OAuth SPIFFE Client Authentication. The client authentication method defined in RFC 8705 Section 2.1 works correctly even if the value of the tls_client_auth_san_uri client metadata differs from the client ID. Best Regards, Taka @ Authlete _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Takahiko Kawasaki Co-Founder [email protected]<mailto:[email protected]> [Authlete] authlete.com<https://www.authlete.com/> |Linkedin<https://www.linkedin.com/company/authlete/> _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
