Team, I quickly want to share epic news, a Mr David Grippman has provided an
opportunity to lay the industry standard in Europe for the regulation, adoption
and DeFi payments in the UK.
My research and roadmap has included Denmark and then Ireland, once the
succesful build and authorisation for the UK is official.
[email protected]
Web Site http://www.fca.org.uk (FCA); http://www.psr.org.uk (the Payment
Systems Regulator Limited)
Regulatory Sandbox & Innovation Pathways
DTI
Kind Regards
Sent from [Proton Mail](https://proton.me/mail/home) for Android.
-------- Original Message --------
On Friday, 02/20/26 at 19:27 Takahiko Kawasaki <[email protected]> wrote:
> Hi Pieter,
>
> Yes, in another email I suggested defining a few new IANA OAuth parameters to
> make everything fit together more seamlessly. Specifically, I proposed the
> following:
>
> New client metadata:
>
> - spiffe_id
> - spiffe_bundle_endpoint
>
> New client authentication method identifiers:
>
> - spiffe_jwt
> - spiffe_x509
>
> With these additions, SPIFFE Client Authentication can work smoothly
> alongside CIMD and OpenID Federation.
>
> Best Regards,
> Taka @ Authlete
>
> On Sat, Feb 21, 2026 at 2:06 AM Pieter Kasselman <[email protected]>
> wrote:
>
>> Thanks for raising this Takahiko.
>>
>> I want to confirm I understand the use case.
>>
>> From what you describe, I think you're suggesting that the desired state is
>> for a client to authenticate with a SPIFFE credential, while using a
>> different client_id (potentially an https:// or other identifier), and that
>> this could potentially be addressed by including additional metadata in CIMD?
>>
>> Cheers
>>
>> Pieter
>>
>> On Fri, Feb 20, 2026 at 4:33 PM Takahiko Kawasaki <[email protected]> wrote:
>>
>>> Hi Emilia,
>>>
>>> Thank you for your response.
>>>
>>> Client IDs and client authentication methods should be orthogonal.
>>>
>>> A CIMD client can have a client ID of "https://example.com/client.json";,
>>> and the client metadata document may contain the following metadata to
>>> indicate that the client uses OAuth SPIFFE Client Authentication with
>>> JWT-SVIDs (assuming that spiffe_jwt represents the client authentication
>>> method):
>>>
>>>> "token_endpoint_auth_method": "spiffe_jwt"
>>>
>>> This is how CIMD and SPIFFE Client Authentication coexist. If we avoid
>>> introducing the requirement that the client ID must start with spiffe://,
>>> we would not need to take the extra step of replacing spiffe:// with
>>> https:// inside the client ID.
>>>
>>> Individual deployments are free to decide to use client IDs that start with
>>> spiffe://, but it is undesirable for a client authentication method to
>>> impose constraints on the format of client IDs. If a mechanism functions
>>> correctly without such a restriction, it is better for a standard not to
>>> impose one.
>>>
>>> Implementer of OpenID Federation, CIMD, various client authentication
>>> methods
>>> Taka @ Authlete
>>> OpenID Federation - https://www.authlete.com/developers/oidcfed/
>>> CIMD - https://www.authlete.com/developers/cimd/
>>> OAuth 2.0 Client Authentication -
>>> https://medium.com/@darutk/oauth-2-0-client-authentication-4b5f929305d4
>>>
>>> On Sat, Feb 21, 2026 at 12:33 AM Emelia S. <[email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> So OAuth SPIFFE Client Authentication does not conflict with OAuth Client
>>>> ID Metadata or OpenID Federation 1.0, since different protocols are used
>>>> https:// vs spiffe://
>>>>
>>>> That allows both to co-exist in an authorization server. It's OAuth Client
>>>> ID Metadata and OpenID Federation 1.0 that conflict (but you almost
>>>> certainly wouldn't deploy them together due to different security/trust
>>>> models), as they both use https:// URIs, so you can't differentiate
>>>> between them without trying to fetch, but they have different fetch
>>>> semantics (iirc).
>>>>
>>>> I'm basing this response on the example in
>>>> https://arndt-s.github.io/oauth-spiffe-client-authentication/draft-ietf-oauth-spiffe-client-auth-00/draft-ietf-oauth-spiffe-client-auth.html#section-3.2.1
>>>>
>>>> An AS can look at the client_id and go "this starts with https://
>>>> therefore I'll use CIMD" or "this starts with spiffe:// so I'll use OAuth
>>>> SPIFFE Client Authentication", just like how you can deploy CIMD and
>>>> DCR/Static Registration on the same AS, as long as DCR would never
>>>> generate a client_id starting with https:// (which should never happen for
>>>> most id generation schemes)
>>>>
>>>> If SPIFFE Client Authentication does not require the spiffe:// protocol
>>>> scheme, and uses https:// then yes, they would be incompatible. I'd
>>>> recommend keeping the spiffe:// scheme — perhaps a resolution step is
>>>> "replace spiffe:// with https:// in the client_id"
>>>>
>>>> Yours,
>>>> Emelia Smith
>>>>
>>>> CIMD Co-author
>>>>
>>>>> On 20 Feb 2026, at 16:04, Takahiko Kawasaki <[email protected]> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> It appears that issues posted to the issue trackers under the management
>>>>> of https://github.com/oauth-wg/ are automatically shared with the OAuth
>>>>> WG mailing list. However, since it is unclear whether issues posted to
>>>>> the OAuth SPIFFE Client Authentication issue tracker under arndt-s's
>>>>> account are also automatically shared with the OAuth WG, I am posting the
>>>>> same content here as well.
>>>>>
>>>>> SPIFFE-CLIENT-AUTH ISSUE 29: Client ID for Client Authentication using
>>>>> X509-SVID
>>>>> https://github.com/arndt-s/oauth-spiffe-client-authentication/issues/29
>>>>>
>>>>> In draft 00 of OAuth SPIFFE Client Authentication, when using Client
>>>>> Authentication with X509-SVID, it requires that the value of the
>>>>> client_id request parameter be the SPIFFE ID. However, I believe this
>>>>> requirement should be removed. The reasons are as follows:
>>>>>
>>>>> - Systems that use the OpenID Federation 1.0 specification cannot use
>>>>> OAuth SPIFFE Client Authentication.
>>>>> - Systems that use the OAuth Client ID Metadata Document specification
>>>>> cannot use OAuth SPIFFE Client Authentication.
>>>>> - Systems in which client IDs cannot be flexibly changed cannot use OAuth
>>>>> SPIFFE Client Authentication.
>>>>>
>>>>> The client authentication method defined in RFC 8705 Section 2.1 works
>>>>> correctly even if the value of the tls_client_auth_san_uri client
>>>>> metadata differs from the client ID.
>>>>>
>>>>> Best Regards,
>>>>> Taka @ Authlete
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list -- [email protected]
>>>>> To unsubscribe send an email to [email protected]
>>>
>>> --
>>>
>>> Takahiko Kawasaki
>>> Co-Founder
>>> [email protected][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][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]
