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

Dick Hardt dick.hardt at gmail.com
Mon Sep 29 14:27:16 UTC 2025 

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

More information about the Openid-specs-ab mailing list