We deliberately have them as part of the client ID and discouraged, because we want to prevent people from doing not quite what you're doing but very similar: it's quite easy to foot-gun oneself with like "oh but I want to vary redirect_uris by query param", and now boom, you've got the same client ID and any random app can impersonate you because you've created an open-redirector effectively.
Their CIMD no longer has a fixed set of redirect_uris so an attacker can override to their evil.example domain and the end-user would think the authorization request legitimate. Sadly, I've seen people try and do dynamically generated CIMDs like that, and getting all sorts of nasty security issues. By discouraging query parameters, we encourage use of "stable URIs", so like http://cimd-service.fly.dev <http://cimd-service.fly.dev/> can generate CIMD documents, but each has a CID (a hash) of the document contents as the path component, so it will always be the same doc for same client_id, and my server there is actually storing client_id => doc mapping. Sure, someone could recreate query parameters in the path component, but it's much less intuitive to do than just using query components. — Emelia > On 21 Feb 2026, at 04:31, Takahiko Kawasaki <[email protected]> wrote: > > 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/ > <http://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 <http://example.org/client/1>" > } > > > On Sat, Feb 21, 2026 at 11:39 AM Takahiko Kawasaki <[email protected] > <mailto:[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] >> <mailto:[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 >>>> <http://example.org/my-oauth-client>/1", >>>> "spiffe://example.org/my-oauth-client >>>> <http://example.org/my-oauth-client>/2", >>>> "spiffe://example.org/my-oauth-client >>>> <http://example.org/my-oauth-client>/3", ... >>>> "spiffe://example.org/my-oauth-client >>>> <http://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 >>>> <http://example.org/my-oauth-client>/*"). >>>> >>>> Cheers >>>> >>>> Pieter >>>> >>>> On Fri, Feb 20, 2026 at 5:35 PM Takahiko Kawasaki <[email protected] >>>> <mailto:[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 >>>>> <http://example.org/my-oauth-client>", >>>>> "spiffe_bundle_endpoint": "https://example.org/bundle"; >>>>> >>>>> >>>>> >>>>> On Sat, Feb 21, 2026 at 2:17 AM Lombardo, Jeff >>>>> <[email protected] >>>>> <mailto:[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] >>>>>> <mailto:[email protected]>> >>>>>> Sent: February 20, 2026 12:09 PM >>>>>> To: Emelia S. <[email protected] >>>>>> <mailto:[email protected]>> >>>>>> Cc: oauth <[email protected] <mailto:[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. >>>>>> <[email protected] >>>>>> <mailto:[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] >>>>>> <mailto:[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] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]>_______________________________________________ >>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]> >>>>> >>>>> >>>>> >>>>> -- >>>>> Takahiko Kawasaki >>>>> Co-Founder >>>>> [email protected] <mailto:[email protected]> >>>>> authlete.com <https://www.authlete.com/> |Linkedin >>>>> <https://www.linkedin.com/company/authlete/> >>>>> _______________________________________________ >>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>> >>> >>> >>> -- >>> Takahiko Kawasaki >>> Co-Founder >>> [email protected] <mailto:[email protected]> >>> authlete.com <https://www.authlete.com/> |Linkedin >>> <https://www.linkedin.com/company/authlete/> >> >> >> >> -- >> Takahiko Kawasaki >> Co-Founder >> [email protected] <mailto:[email protected]> >> authlete.com <https://www.authlete.com/> |Linkedin >> <https://www.linkedin.com/company/authlete/> > > > > -- > Takahiko Kawasaki > Co-Founder > [email protected] <mailto:[email protected]> > authlete.com <https://www.authlete.com/> |Linkedin > <https://www.linkedin.com/company/authlete/> > <cimd-client-host.rb>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
