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]

Reply via email to