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/>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
