Hi Pieter,
As of the last time I checked the CIMD specification, including query
parameters in the client ID is discouraged. However, if they are included,
then (unless I am mistaken) they are considered part of the client ID. In
other words, https://example.com/client.json?instance_id=1 and
https://example.com/client.json?instance_id=2 would be recognized as
different clients.
However, if the CIMD specification were slightly revised to state that
query parameters are not considered part of the client ID, it would become
possible to generate different metadata documents for multiple instances of
a single client by using query parameters. In that case, the scalability
concerns you mentioned could be mitigated.
Below is an example implementation (attached: cimd-client-host.rb) of a
Client ID Metadata Document that embeds the value of the instance_id query
parameter as part of the SPIFFE ID.
#!/usr/bin/env ruby
require 'sinatra'
require 'json'
# The endpoint that issues a Client ID Metadata Document
get '/client.json' do
content_type :json
metadata = {
client_id: "https://example.com/client.json";,
spiffe_id: "spiffe://example.org/client/#{params['instance_id']}"
}
JSON.pretty_generate(metadata)
end
If you start this program on your local machine:
./cimd-client-host.rb
and access it as follows:
curl http://localhost:4567/client.json?instance_id=1
you will receive the following response:
{
"client_id": "https://example.com/client.json";,
"spiffe_id": "spiffe://example.org/client/1"
}
On Sat, Feb 21, 2026 at 11:39 AM Takahiko Kawasaki <[email protected]>
wrote:
> Hi Jeff,
>
> My intuition is that, since the OAuth SPIFFE Client Authentication
> specification defines a client authentication method that depends on
> SPIFFE, it is natural to use the spiffe_ prefix for the metadata required
> by that method.
>
> If a generic parameter such as client_alternate_id is needed, I believe it
> would be better to define it in a more abstract specification—at a level of
> abstraction comparable to RFC 7521—rather than within the OAuth SPIFFE
> Client Authentication specification itself.
>
>
> On Sat, Feb 21, 2026 at 4:57 AM Takahiko Kawasaki <[email protected]>
> wrote:
>
>> I have created a diagram illustrating what I am proposing (i.e., how
>> SPIFFE Client Authentication can coexist with CIMD), and I am attaching it
>> to this email. If the attached image is removed by the mailing list system
>> and cannot be accessed, please refer to the diagram that I have posted in
>> the issue tracker.
>>
>>
>> https://github.com/arndt-s/oauth-spiffe-client-authentication/issues/30#issuecomment-3936816934
>>
>>
>> On Sat, Feb 21, 2026 at 3:50 AM Pieter Kasselman <[email protected]>
>> wrote:
>>
>>> Thanks Tako - this looks like a very promising approach.
>>>
>>> I wonder if this can also help with per-instance identifiers.
>>>
>>> With SPIFFE, it is common to assign identifiers at individual workload
>>> level, so you may have one application that have 100 instances (individual
>>> workloads), with each of these having their own unique SPIFFE credential (
>>> "spiffe://example.org/my-oauth-client/1", "spiffe://
>>> example.org/my-oauth-client/2", "spiffe://example.org/my-oauth-client/3",
>>> ... "spiffe://example.org/my-oauth-client/100"). One option is to
>>> publish a CIMD document for each of those workloads, but this has scale
>>> issues, especially. in dynamic environments. Perhaps this can be handled
>>> through some kind of wild-carding in defining the spifffe_id (e.g.
>>> "spiffe://example.org/my-oauth-client/*").
>>>
>>> Cheers
>>>
>>> Pieter
>>>
>>> On Fri, Feb 20, 2026 at 5:35 PM Takahiko Kawasaki <[email protected]>
>>> wrote:
>>>
>>>> Hi Aaron,
>>>>
>>>> Yes, what I expect the Client ID Metadata Document to contain is as
>>>> follows:
>>>>
>>>> "token_endpoint_auth_method": "spiffe_jwt" or "spiffe_x509",
>>>> "spiffe_id": "spiffe://example.org/my-oauth-client",
>>>> "spiffe_bundle_endpoint": "https://example.org/bundle";
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Feb 21, 2026 at 2:17 AM Lombardo, Jeff <jeffsec=
>>>> [email protected]> wrote:
>>>>
>>>>> I concur on this strategy being the one that can rule all the cases
>>>>> [and in the light binds them].
>>>>>
>>>>> When using CIMD, it must become the source of truth for a client_id
>>>>> and all its possible aliases.
>>>>>
>>>>>
>>>>>
>>>>> *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:* Aaron Parecki <[email protected]>
>>>>> *Sent:* February 20, 2026 12:09 PM
>>>>> *To:* Emelia S. <[email protected]>
>>>>> *Cc:* oauth <[email protected]>
>>>>> *Subject:* [EXT] [OAUTH-WG] Re: IANA OAuth Parameters for SPIFFE
>>>>> Client Authentication
>>>>>
>>>>>
>>>>>
>>>>> *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.
>>>>>
>>>>>
>>>>>
>>>>> It sounds like the CIMD would publish the `spiffe_id` in the metadata,
>>>>> that way the SPIFFE-ID in the SVID can be validated against the value in
>>>>> the CIMD? That sounds like it would work.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 20, 2026 at 9:06 AM Emelia S. <emelia=
>>>>> [email protected]> wrote:
>>>>>
>>>>> > SPIFFE Client Authentication with JWT-SVIDs requires the
>>>>> authorization server to ensure that the SPIFFE ID in the SVID matches the
>>>>> registered value, but the specification does not define how this
>>>>> verification is to be performed. If the spiffe_id client metadata is
>>>>> available, the authorization server can satisfy this requirement by
>>>>> comparing the registered metadata value with the SPIFFE ID contained in
>>>>> the
>>>>> SVID.
>>>>>
>>>>> The spiffe_id would mismatch with client_id right? For using it with
>>>>> CIMD?
>>>>>
>>>>>
>>>>>
>>>>> – Emelia
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 20 Feb 2026, at 17:57, Takahiko Kawasaki <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> *SPIFFE-CLIENT-AUTH ISSUE 30: IANA OAuth Parameters for SPIFFE Client
>>>>> Authentication*
>>>>>
>>>>> https://github.com/arndt-s/oauth-spiffe-client-authentication/issues/30
>>>>>
>>>>>
>>>>>
>>>>> I would like to propose the following IANA OAuth Parameters
>>>>> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml>
>>>>> for
>>>>> SPIFFE Client Authentication:
>>>>> OAuth Dynamic Client Registration Metadata
>>>>>
>>>>> - spiffe_id
>>>>> - spiffe_bundle_endpoint
>>>>>
>>>>> OAuth Token Endpoint Authentication Methods
>>>>>
>>>>> - spiffe_jwt
>>>>> - spiffe_x509
>>>>>
>>>>> Rationale for spiffe_id
>>>>>
>>>>> SPIFFE Client Authentication with JWT-SVIDs requires the authorization
>>>>> server to ensure that the SPIFFE ID in the SVID matches the registered
>>>>> value, but the specification does not define how this verification is to
>>>>> be
>>>>> performed. If the spiffe_id client metadata is available, the
>>>>> authorization server can satisfy this requirement by comparing the
>>>>> registered metadata value with the SPIFFE ID contained in the SVID.
>>>>> Rationale for spiffe_bundle_endpoint
>>>>>
>>>>> Because the location of the SPIFFE Bundle Endpoint cannot be inferred
>>>>> from the SPIFFE ID or the SVID, it must be preconfigured. However, the
>>>>> specification does not define how this configuration is to be performed.
>>>>> If
>>>>> the spiffe_bundle_endpoint client metadata is available, the
>>>>> authorization server can use it to store the preconfigured value.
>>>>> Rationale for spiffe_jwt and spiffe_x509
>>>>>
>>>>> The token_endpoint_auth_method client metadata and the
>>>>> token_endpoint_auth_methods_supported server metadata require
>>>>> identifiers representing the new client authentication methods defined by
>>>>> this specification.
>>>>>
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Taka @ Authlete
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list -- [email protected]
>>>>> To unsubscribe send an email to [email protected]
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list -- [email protected]
>>>>> To unsubscribe send an email to [email protected]
>>>>>
>>>>> _______________________________________________
>>>>> 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/>
>>
>
>
> --
> *Takahiko Kawasaki*
> Co-Founder
> [email protected]
> [image: Authlete]
> authlete.com <https://www.authlete.com/> |Linkedin
> <https://www.linkedin.com/company/authlete/>
>
--
*Takahiko Kawasaki*
Co-Founder
[email protected]
[image: Authlete]
authlete.com <https://www.authlete.com/> |Linkedin
<https://www.linkedin.com/company/authlete/>
#!/usr/bin/env ruby
require 'sinatra'
require 'json'
# The endpoint that issues a Client ID Metadata Document
get '/client.json' do
content_type :json
metadata = {
client_id: "https://example.com/client.json";,
spiffe_id: "spiffe://example.org/client/#{params['instance_id']}"
}
JSON.pretty_generate(metadata)
end
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
