Hi Taka, Thank you for the feedback. I understand your point and I agree that reaching consensus is the priority here.
Given the alignment with RFC 9525, I am fine with using spiffe_id and allowing wildcards if that is the preferred direction of the community. Best regards, Eric Le jeu. 26 févr. 2026 à 21:41, Takahiko Kawasaki <[email protected]> a écrit : > Hi Eric, > > Sometimes, it is not logically possible to determine a single definitive > name for client or server metadata, and in such cases the choice may be > made based on preference. > > My preference is to use a single spiffie_id field to support both 1:1 and > 1:N mappings. This approach follows the precedent established by X.509 > certificates, specifically the use of Common Name and dNSName as described > in RFC 9525. > > Even if we discuss this further, my personal preference is unlikely to > change, so it may be appropriate to seek consensus from other experts. For > my part, I would vote in favor of allowing a wildcard in spiffie_id. > > Taka > > On Fri, Feb 27, 2026 at 2:17 AM Eric Leleu <[email protected]> > wrote: > >> 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> >> > > > -- > *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]
