Hi Pieter, Yes, in another email I suggested defining a few new IANA OAuth parameters to make everything fit together more seamlessly. Specifically, I proposed the following:
*New client metadata:* - spiffe_id - spiffe_bundle_endpoint *New client authentication method identifiers:* - spiffe_jwt - spiffe_x509 With these additions, SPIFFE Client Authentication can work smoothly alongside CIMD and OpenID Federation. Best Regards, Taka @ Authlete On Sat, Feb 21, 2026 at 2:06 AM Pieter Kasselman <[email protected]> wrote: > 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]> > 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]> >> 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] >> > -- *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]
