Pieter, yes this is the proposal. Using a more explicit naming convention would better highlight the potential 1:N relationship, such as 'canonical_spiffe_id' or 'spiffe_id_prefix'.
Takahiko, I agree that the specification can explicitly allow wildcards and define restrictions; however, I still favor explicit naming. Le mar. 24 févr. 2026 à 13:07, Takahiko Kawasaki <[email protected]> a écrit : > Considering that, in X.509 certificates for websites, hostnames containing > a wildcard (e.g., *.example.com) can be set in the Subject / Common Name > or Subject Alternative Name / dNSName, I do not think it would be > particularly unnatural to allow a wildcard in the final path segment of the > spiffe_id client metadata. > > To support wildcard behavior, X.509 certificates do not define separate > field names such as “Common Name Prefix” or “dNSName Prefix”; instead, they > simply use the existing Common Name and dNSName fields as they are. > > The following two requirements regarding wildcards described in Section > 6.3, "Matching the DNS Domain Name Portion," of RFC 9525 Service Identity > in TLS (https://www.rfc-editor.org/rfc/rfc9525.html#section-6.3) may > serve as useful references: > > - There is only one wildcard character. > - The wildcard character appears only as the complete content of the > left-most label. > > If we align with these requirements, we could define the requirements for > cases where the spiffe_id client metadata contains a wildcard as follows: > > - There is only one wildcard character. > - The wildcard character appears only as the last path segment. > > According to the SPIFFE ID specification ( > https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md), path > segments in a SPIFFE ID "contain only letters, numbers, dots, dashes, and > underscores ([a-zA-Z0-9._-])." However, the wildcard discussed here applies > to the value of the client metadata. > > > On Tue, Feb 24, 2026 at 8:21 PM Pieter Kasselman <[email protected]> > wrote: > >> Thanks Aaron, Eric and Emelia >> >> Aaron, the wildcarding is not a SPIFFE construct, it is meant as a way to >> say "SPIFFE IDs starting with this trust domain and path should be allowed >> to present their credentials when using the client_id", thereby creating a >> one (client_id) to many (instance id) mapping. SPIFFE identifiers are >> hierarchical, and one way in which they can be used to become increasingly >> specific as additional path elements are added (this is deployment >> specific). The choice of how to construct a SPIFFE ID is up to a deployment. >> >> Emelia, Eric, if I understand your proposal correctly, your suggesting >> that instead of using wildcarding (which can also be problematic), create >> an additional metadata item like "spiffe_instance_prefix" for cases where >> that kind of 1:many mapping is desirable/feasible and keep it >> separate from the "spiffe_id" which always provides a 1:1 mapping? >> >> Cheers >> >> Pieter >> >> On Tue, Feb 24, 2026 at 8:54 AM Eric Leleu <[email protected]> >> wrote: >> >>> 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] >> > > > -- > *Takahiko Kawasaki* > Co-Founder > [email protected] > [image: Authlete] > authlete.com <https://www.authlete.com/> |Linkedin > <https://www.linkedin.com/company/authlete/> > -- 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]
