Hi, I agree with Emelia, if the metadata document has to provide a base URI for the spiffe identifiers it may be more appropriate to name it explicitly.
Regards, Eric ps: This is the first time I publish a comment in the mailing list, sorry if I'm not following the good practices. Le lun. 23 févr. 2026 à 18:55, Emelia S. <emelia= [email protected]> a écrit : > 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/*" > } > > This allows any client instance to use their credentials (e.g. spiffe:// > example.org/client/1 or spiffe://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]> 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 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/#{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/> >> <cimd-client-host.rb> >> >> >> > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Eric LELEU Staff Software Engineer / AM Teach Lead E [email protected] <[email protected]> Hold Nothing Back <http://youtube.com/c/Graviteesource?sub_confirmation=1> <https://www.linkedin.com/company/gravitee-io>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
