[Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification
Dick Hardt
dick.hardt at gmail.com
Mon Sep 29 15:26:04 UTC 2025
I agree that language could be better -- but I don't think it is misleading
-- and your characterization of the language is misleading.
On Mon, Sep 29, 2025 at 4:14 PM Aaron Parecki <aaron at parecki.com> wrote:
> 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/a261a752/attachment-0001.htm>
More information about the Openid-specs-ab
mailing list