That makes sense to me. If other forms of client auth come along later it seems easier to have them add a new property than to figure out how to reuse the generic "client_alternate_id" while somehow indicating what method that is.
On Fri, Feb 20, 2026 at 6:40 PM 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/> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
