Hi Aaron, Yes, a JWT-SVID’s sub claim is a SPIFFE ID that starts with spiffe://, which is different from the client ID in the CIMD context. While this may not be ideal, SPIFFE Client Authentication using JWT-SVIDs is still implementable.
We know that implementations of the client_secret_jwt and private_key_jwt client authentication methods compare the sub claim in the client assertion with the client ID. This comparison model does not work for SPIFFE Client Authentication. However, thanks to the newly introduced client assertion type, urn:ietf:params:oauth:client-assertion-type:jwt-spiffe, implementations can recognize that the sub claim in the client assertion should be compared with the preregistered SPIFFE ID rather than the client ID. Therefore, the fact that the sub claim differs from the client ID will not be an issue. On Sat, Feb 21, 2026 at 1:44 AM Aaron Parecki <[email protected]> wrote: > Hi Taka, > > What perfect timing, I was actually just thinking about this yesterday. I > was hoping to find a way to use SPIFFE Client Authentication with clients > that have a CIMD. The goal would be to enable clients to authenticate to > remote services without prior registration or coordination, while still > being able to leverage the useful SPIFFE Client Authentication mechanism > and DNS-resolvable client IDs. > > The same issue exists with the JWT-SVID method as well, a client that uses > an https URL as its client ID would ideally be able to present a JWT-SVID > with a `sub` value of its own client ID. I realize this is kind of at odds > with the fundamental nature of SPIFFE-IDs which are explicltly not part of > a global namespace, but I was hoping to be able to take advantage of the > SPIFFE mechanism when there *is* a global namespace of client IDs like CIMD > enables. > > The reason the OAuth mailing list doesn't track Arndt's repo is because it > is not yet moved to the OAuth GitHub and is still an individual draft. The > adoption call ended successfully in November but I haven't seen a new > version posted since then, and we still need to move the repo to the > OAuth-WG GitHub. > > Aaron > > > On Fri, Feb 20, 2026 at 8:33 AM 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]
