Maybe instead of `spiffe_id` which I think should be singular, you'd instead have like a spiffe_issuer or spiffe_origin (I don't know the right language here), which would be explicit in the "all spiffe_id's with this prefix are valid for this client_id"
Would that make sense? — Emelia > On 23 Feb 2026, at 17:31, Pieter Kasselman <[email protected]> wrote: > > Thanks Taku and Emelia > > Taku, that is an interesting idea - I did not think of that approach! Emelia, > thanks for sharing the context on why query parameters could get an > implementer into trouble. > > I was thinking that the URL would represent the client_id of a class of > clients (no need for query parameters), but that each instance of that class > could have its own SPIFFE ID (which represents an instance). If there are 100 > instances of the client, you would still use the same client_id with CIMD, > but then allow each instance of the client to authenticate using their SPIFFE > credential, which contain its own unique identifier. The idea was to extend > from a 1:1 mapping between client_id and SPIFFE Id to a 1:many mapping, where > the SPIFFE IDs would instance identifiers. > > I was thinking that the CIMD URL would indicate a class of client, while the > SPIFFE credentials would represent individual instances. > > metadata = { > client_id: "https://example.com/client.json";, > spiffe_id: "spiffe://example.org/client/ <http://example.org/client/>*" > } > > This allows any client instance to use their credentials (e.g. > spiffe://example.org/client/1 <http://example.org/client/1> or > spiffe://example.org/client/2 <http://example.org/client/2> etc). The AS can > accept the credentials as valid, and also use the additional information for > other purposes (audit logs, or perhaps adding it as claims to a token or > expose it through a introspection point etc). > > This way the client_id URL represents a class of clients, and the SPIFFE ID > specific instances by allowing wildcard mapping (the alternative is > publishing hundreds, maybe thousands of CIMD documents that is identical, > except for the SPIFFE ID). > > Cheers > > Pieter > > On Sat, Feb 21, 2026 at 4:53 AM Emelia S. <[email protected] > <mailto:[email protected]>> wrote: >> 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] >>> <mailto:[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]
