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]> 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]> 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] > To unsubscribe send an email to [email protected] > > > -- *Takahiko Kawasaki* Co-Founder [email protected] [image: Authlete] authlete.com <https://www.authlete.com/> |Linkedin <https://www.linkedin.com/company/authlete/>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
