[Openid-specs-ab] Call for Adoption for the OpenID Connect Key Binding Specification

Dick Hardt dick.hardt at gmail.com
Mon Sep 29 14:57:51 UTC 2025 

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/a50108bc/attachment-0001.htm>

More information about the Openid-specs-ab mailing list