[Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification
Aaron Parecki
aaron at parecki.com
Mon Sep 29 15:14:11 UTC 2025
Great. Like I said in my first email, I'm not comfortable with even a first
draft of an adopted OpenID document containing the current language, so
would like to see this revised before adoption.
On Mon, Sep 29, 2025 at 7:58 AM Dick Hardt <dick.hardt at gmail.com> wrote:
> That is the intent, and we plan to improve the language.
>
> On Mon, Sep 29, 2025 at 3:31 PM Aaron Parecki <aaron at parecki.com> wrote:
>
>> If that is your intent, the language in the draft should be updated to
>> make that explicit. I pointed out all the places in the text that could
>> lead to a misinterpretation of your intent. These are the sections that
>> will likely cause people to use ID tokens to access resources and justify
>> it based on the text provided.
>>
>>
>> On Mon, Sep 29, 2025 at 7:27 AM Dick Hardt <dick.hardt at gmail.com> wrote:
>>
>>> A bearer token does not imply accessing a resource.
>>>
>>> We are using the term "bearer token" to contrast it with the security
>>> features of key binding.
>>>
>>>
>>>
>>>
>>> On Mon, Sep 29, 2025 at 2:14 PM Aaron Parecki <aaron at parecki.com> wrote:
>>>
>>>> | "The draft does not suggest using the ID Token as a bearer token."
>>>>
>>>> Here are the instances where it does. In the intro:
>>>>
>>>> > When an RP wants to prove to another system that it has authenticated
>>>> a user, it may present the ID Token as a bearer token.
>>>>
>>>> and
>>>>
>>>> > This transforms the ID Token from a vulnerable bearer token into a
>>>> proof-of-possession token that provides stronger security guarantees.
>>>>
>>>> In the Security Considerations:
>>>>
>>>> > Public key bound ID Tokens provide a higher level security than
>>>> bearer ID Tokens by using proof of possession rather than bearer
>>>> authentication.
>>>>
>>>> and
>>>>
>>>> > If bearer token authentication is desired, bearer ID Tokens should be
>>>> used instead.
>>>>
>>>> | "The draft does not suggest using ID Tokens across domains."
>>>>
>>>> The term "domain" doesn't appear in the draft, but the language
>>>> "another system" could easily be interpreted as across domains, since it is
>>>> not actually defined in the draft as a same-domain system.
>>>>
>>>> On Mon, Sep 29, 2025 at 4:28 AM Dick Hardt via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>>> Aaron, thanks for your feedback. I want to make sure we’re aligned on
>>>>> what the draft actually says.
>>>>>
>>>>> You mention not supporting adoption because:
>>>>>
>>>>> > The problematic language is the non-normative suggestion of using
>>>>> an ID token as a bearer token to access resources at other domains. We
>>>>> should not be encouraging this behavior even if it exists in the wild.
>>>>>
>>>>> > I do not believe the draft should be adopted as is, because of the
>>>>> language suggesting it is okay to use ID tokens directly across domains.
>>>>>
>>>>> To clarify:
>>>>>
>>>>>
>>>>> -
>>>>>
>>>>> Neither the word *resource* nor *domain* appears in the draft.
>>>>> -
>>>>>
>>>>> The draft does *not* suggest using the ID Token as a bearer token.
>>>>> -
>>>>>
>>>>> The draft does *not* suggest using ID Tokens across domains.
>>>>>
>>>>> If there is specific text that suggests otherwise, please point it out
>>>>> so we can correct it.
>>>>>
>>>>> We will add additional non-normative text that instructs readers to
>>>>> not use the ID Token for access, as well as to not use the same keys for
>>>>> signing other objects.
>>>>>
>>>>> It sounds like you agree with Karl (co-author of *Identity Assertion
>>>>> Authorization Grant*) that normative language around key binding is
>>>>> useful. I hope with the clarifications above—and with the additional
>>>>> non-normative guidance—we address your concerns about adoption.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 26, 2025 at 11:33 PM Aaron Parecki via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>
>>>>>> I do not support adoption of the draft as it currently stands, for
>>>>>> similar reasons to the previous replies on this topic.
>>>>>>
>>>>>>
>>>>>> The problematic language is the non-normative suggestion of using an
>>>>>> ID token as a bearer token to access resources at other domains. We should
>>>>>> not be encouraging this behavior even if it exists in the wild.
>>>>>>
>>>>>>
>>>>>> However, I do have a use for binding a DPoP key to an ID Token. One
>>>>>> application of the OAuth draft "Identity and Authorization Chaining Across
>>>>>> Domains"
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ involves
>>>>>> exchanging an initial token from the domain that issued it (using RFC8693
>>>>>> Token Exchange) for a token that moves across domains and is later
>>>>>> exchanged for an access token using RFC7523. This is further profiled by
>>>>>> the draft "Identity Assertion Authorization Grant"
>>>>>> https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/ (currently
>>>>>> in the middle of the working group adoption call), which specifies that the
>>>>>> initial token is an identity assertion such as an ID token.
>>>>>>
>>>>>>
>>>>>> In this flow, the OpenID Provider issues an ID token to a client. The
>>>>>> client uses Token Exchange to exchange the ID token back at the OpenID
>>>>>> Provider for a new JWT. It takes the new JWT to an authorization server in
>>>>>> a different trust domain exchanging it for an OAuth access token.
>>>>>>
>>>>>>
>>>>>> It would be valuable to be able to bind the ID token to the client
>>>>>> using DPoP, which is possible using the method described in this OpenID
>>>>>> draft. This use of the ID token doesn't have the problematic attribute of
>>>>>> being used directly in another domain.
>>>>>>
>>>>>>
>>>>>> I believe the sorts of cross-domain uses of ID tokens mentioned in
>>>>>> the draft would likely be better accomplished using "Identity and
>>>>>> Authorization Chaining Across Domains", which properly scopes the tokens to
>>>>>> each trust domain.
>>>>>>
>>>>>>
>>>>>> All this said, I do not believe the draft should be adopted as is,
>>>>>> because of the language suggesting it is okay to use ID tokens directly
>>>>>> across domains. I would not want an OIDF draft to endorse this behavior.
>>>>>>
>>>>>> Aaron Parecki
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 26, 2025 at 1:37 PM Ralph Bragg via Openid-specs-ab <
>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>
>>>>>>> *This message originated outside your organization.*
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> Likewise, I do not support utilisation the id token In this way for
>>>>>>> the reasons already raised. We’ve just had issues with multiple aud values
>>>>>>> being identified as a significant source of vulnerability with PKJ so
>>>>>>> extending / modifying an id tokens aud raises too many concerns for me as a
>>>>>>> potential mitigation. I don’t believe that this token should be relied on
>>>>>>> by any actor other than the intended audience.
>>>>>>>
>>>>>>> Ralph Bragg
>>>>>>>
>>>>>>> Chief Technology Officer
>>>>>>>
>>>>>>> M.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +447890130559
>>>>>>>
>>>>>>> T.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +44 20 4583 6770
>>>>>>>
>>>>>>> ralph.bragg at raidiam.com
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net>
>>>>>>> on behalf of Andrii Deinega via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net>
>>>>>>> *Sent:* Saturday, September 27, 2025 4:26:07 AM
>>>>>>> *To:* Artifact Binding/Connect Working Group <
>>>>>>> openid-specs-ab at lists.openid.net>
>>>>>>> *Cc:* Andrii Deinega <andrii.deinega at gmail.com>
>>>>>>> *Subject:* Re: [Openid-specs-ab] Call for Adoption for the OpenID
>>>>>>> Connect Key Binding Specification
>>>>>>>
>>>>>>> I believe that any recipient of a JWT (in this case, an ID Token)
>>>>>>> should immediately reject it if it isn't the intended audience (which is
>>>>>>> indicated by the aud claim), regardless of whether cryptographic binding is
>>>>>>> present or not. This alone makes the statement below too problematic for me.
>>>>>>>
>>>>>>> When an RP wants to prove to another system that it has
>>>>>>> authenticated a user, it may present the ID Token as a bearer token.
>>>>>>> However, bearer tokens are vulnerable to theft and replay attacks - if an
>>>>>>> attacker intercepts the ID Token, they can impersonate the authenticated
>>>>>>> user to downstream systems that accept a ID Token as a bearer token.
>>>>>>>
>>>>>>>
>>>>>>> It's difficult to imagine multiple systems (recipients) sharing the
>>>>>>> same value in the aud claim (this value must be a client_id of the RP per
>>>>>>> the Core spec). It's fair to add the aud claim may contain an array with
>>>>>>> more than one element, but it's also fair to say this practice is
>>>>>>> discouraged (1) and comes with additional complexity and concerns (2).
>>>>>>>
>>>>>>> At the end of the day... I see a lot of value, and I see the reason
>>>>>>> why people want to have the standard around "proving to another system that
>>>>>>> it has authenticated a user," but I don't think that repurposing existing
>>>>>>> ID Tokens for it is the right way to go.... I’d suggest, and actually love
>>>>>>> to see - the use of SD JWT VCs (or other VCs) for this purpose instead.
>>>>>>>
>>>>>>> I haven’t reached the point where I need to "touch" Justin’s
>>>>>>> concerns... I fully agree with him on them.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Andrii
>>>>>>>
>>>>>>> On Fri, Sep 26, 2025 at 9:05 AM Justin Richer via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>
>>>>>>> I do not support adoption of this work. The ID Token is not intended
>>>>>>> to be a conveyable artifact, and using it as such is a security layer
>>>>>>> boundary. It’s hard enough to get people to not use ID Tokens as Access
>>>>>>> Tokens today, since a lot of developers see all JWTs as equivalent, really.
>>>>>>> This work would make this problem significantly worse.
>>>>>>>
>>>>>>> — Justin
>>>>>>>
>>>>>>> On Sep 15, 2025, at 6:57 PM, Michael Jones via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>
>>>>>>> This starts a two-week call for feedback on whether to adopt the
>>>>>>> OpenID Connect OpenID Connect Key Binding specification contributed to the
>>>>>>> working group by Dick Hardt and Ethan Heilman as an OpenID Connect Working
>>>>>>> Group specification. Please reply-all by Monday, September 29, 2025 saying
>>>>>>> whether you are favor of adoption or not, also saying why.
>>>>>>>
>>>>>>> The specification was contributed at
>>>>>>> https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html
>>>>>>> <https://urldefense.com/v3/__https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ8YWyonU$>.
>>>>>>> It has been extensively discussed by the working group both on calls and on
>>>>>>> the mailing list. From my observations of the discussion as a working
>>>>>>> group chair, I believe that there is consensus that it would be useful to
>>>>>>> have a standard solving the problem addressed by this specification.
>>>>>>>
>>>>>>> Writing as a working
>>>>>>> group chair,
>>>>>>> --
>>>>>>> Mike
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 26, 2025 at 11:33 PM Aaron Parecki via Openid-specs-ab <
>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>
>>>>>> I do not support adoption of the draft as it currently stands, for
>>>>>> similar reasons to the previous replies on this topic.
>>>>>>
>>>>>>
>>>>>> The problematic language is the non-normative suggestion of using an
>>>>>> ID token as a bearer token to access resources at other domains. We should
>>>>>> not be encouraging this behavior even if it exists in the wild.
>>>>>>
>>>>>>
>>>>>> However, I do have a use for binding a DPoP key to an ID Token. One
>>>>>> application of the OAuth draft "Identity and Authorization Chaining Across
>>>>>> Domains"
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/
>>>>>> involves exchanging an initial token from the domain that issued it (using
>>>>>> RFC8693 Token Exchange) for a token that moves across domains and is later
>>>>>> exchanged for an access token using RFC7523. This is further profiled by
>>>>>> the draft "Identity Assertion Authorization Grant"
>>>>>> https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/
>>>>>> (currently in the middle of the working group adoption call), which
>>>>>> specifies that the initial token is an identity assertion such as an ID
>>>>>> token.
>>>>>>
>>>>>>
>>>>>> In this flow, the OpenID Provider issues an ID token to a client. The
>>>>>> client uses Token Exchange to exchange the ID token back at the OpenID
>>>>>> Provider for a new JWT. It takes the new JWT to an authorization server in
>>>>>> a different trust domain exchanging it for an OAuth access token.
>>>>>>
>>>>>>
>>>>>> It would be valuable to be able to bind the ID token to the client
>>>>>> using DPoP, which is possible using the method described in this OpenID
>>>>>> draft. This use of the ID token doesn't have the problematic attribute of
>>>>>> being used directly in another domain.
>>>>>>
>>>>>>
>>>>>> I believe the sorts of cross-domain uses of ID tokens mentioned in
>>>>>> the draft would likely be better accomplished using "Identity and
>>>>>> Authorization Chaining Across Domains", which properly scopes the tokens to
>>>>>> each trust domain.
>>>>>>
>>>>>>
>>>>>> All this said, I do not believe the draft should be adopted as is,
>>>>>> because of the language suggesting it is okay to use ID tokens directly
>>>>>> across domains. I would not want an OIDF draft to endorse this
>>>>>> behavior.
>>>>>>
>>>>>> Aaron Parecki
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 26, 2025 at 1:37 PM Ralph Bragg via Openid-specs-ab <
>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>
>>>>>>> *This message originated outside your organization.*
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> Likewise, I do not support utilisation the id token In this way for
>>>>>>> the reasons already raised. We’ve just had issues with multiple aud values
>>>>>>> being identified as a significant source of vulnerability with PKJ so
>>>>>>> extending / modifying an id tokens aud raises too many concerns for me as a
>>>>>>> potential mitigation. I don’t believe that this token should be relied on
>>>>>>> by any actor other than the intended audience.
>>>>>>>
>>>>>>> Ralph Bragg
>>>>>>>
>>>>>>> Chief Technology Officer
>>>>>>>
>>>>>>> M.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +447890130559
>>>>>>>
>>>>>>> T.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +44 20 4583 6770
>>>>>>>
>>>>>>> ralph.bragg at raidiam.com
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net>
>>>>>>> on behalf of Andrii Deinega via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net>
>>>>>>> *Sent:* Saturday, September 27, 2025 4:26:07 AM
>>>>>>> *To:* Artifact Binding/Connect Working Group <
>>>>>>> openid-specs-ab at lists.openid.net>
>>>>>>> *Cc:* Andrii Deinega <andrii.deinega at gmail.com>
>>>>>>> *Subject:* Re: [Openid-specs-ab] Call for Adoption for the OpenID
>>>>>>> Connect Key Binding Specification
>>>>>>>
>>>>>>> I believe that any recipient of a JWT (in this case, an ID Token)
>>>>>>> should immediately reject it if it isn't the intended audience (which is
>>>>>>> indicated by the aud claim), regardless of whether cryptographic binding is
>>>>>>> present or not. This alone makes the statement below too problematic for me.
>>>>>>>
>>>>>>> When an RP wants to prove to another system that it has
>>>>>>> authenticated a user, it may present the ID Token as a bearer token.
>>>>>>> However, bearer tokens are vulnerable to theft and replay attacks - if an
>>>>>>> attacker intercepts the ID Token, they can impersonate the authenticated
>>>>>>> user to downstream systems that accept a ID Token as a bearer token.
>>>>>>>
>>>>>>>
>>>>>>> It's difficult to imagine multiple systems (recipients) sharing the
>>>>>>> same value in the aud claim (this value must be a client_id of the RP per
>>>>>>> the Core spec). It's fair to add the aud claim may contain an array with
>>>>>>> more than one element, but it's also fair to say this practice is
>>>>>>> discouraged (1) and comes with additional complexity and concerns (2).
>>>>>>>
>>>>>>> At the end of the day... I see a lot of value, and I see the reason
>>>>>>> why people want to have the standard around "proving to another system that
>>>>>>> it has authenticated a user," but I don't think that repurposing existing
>>>>>>> ID Tokens for it is the right way to go.... I’d suggest, and actually love
>>>>>>> to see - the use of SD JWT VCs (or other VCs) for this purpose instead.
>>>>>>>
>>>>>>> I haven’t reached the point where I need to "touch" Justin’s
>>>>>>> concerns... I fully agree with him on them.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Andrii
>>>>>>>
>>>>>>> On Fri, Sep 26, 2025 at 9:05 AM Justin Richer via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>
>>>>>>> I do not support adoption of this work. The ID Token is not intended
>>>>>>> to be a conveyable artifact, and using it as such is a security layer
>>>>>>> boundary. It’s hard enough to get people to not use ID Tokens as Access
>>>>>>> Tokens today, since a lot of developers see all JWTs as equivalent, really.
>>>>>>> This work would make this problem significantly worse.
>>>>>>>
>>>>>>> — Justin
>>>>>>>
>>>>>>> On Sep 15, 2025, at 6:57 PM, Michael Jones via Openid-specs-ab <
>>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>>
>>>>>>> This starts a two-week call for feedback on whether to adopt the
>>>>>>> OpenID Connect OpenID Connect Key Binding specification contributed to the
>>>>>>> working group by Dick Hardt and Ethan Heilman as an OpenID Connect Working
>>>>>>> Group specification. Please reply-all by Monday, September 29, 2025 saying
>>>>>>> whether you are favor of adoption or not, also saying why.
>>>>>>>
>>>>>>> The specification was contributed at
>>>>>>> https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html
>>>>>>> <https://urldefense.com/v3/__https://lists.openid.net/pipermail/openid-specs-ab/2025-August/010890.html__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ8YWyonU$>.
>>>>>>> It has been extensively discussed by the working group both on calls and on
>>>>>>> the mailing list. From my observations of the discussion as a working
>>>>>>> group chair, I believe that there is consensus that it would be useful to
>>>>>>> have a standard solving the problem addressed by this specification.
>>>>>>>
>>>>>>> Writing as a working
>>>>>>> group chair,
>>>>>>> --
>>>>>>> Mike
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> <https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!6QnHIKzhjBzjwwVrJqFfHF90LftISX-Hsr1obR0wAaEN3vBfUK_FDeluuf1qi3PARLAeMVkMdeDKDke1X_e_ZGJaQ2Sra7o3$>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250929/9183d629/attachment-0001.htm>
More information about the Openid-specs-ab
mailing list