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

[Dick Hardt]

I agree that the recipient of a JWT should reject it if it is not the
intended audience.

We think of the "other system" to be another component of the RP -- and
because of that, that an id_token is the right token to bind and that both
would verify the id_token has the correct "aud" value.

VCs were designed for the issuer - holder - verifier model to protect the
privacy of the user by preventing the issuer from learning about
presentation by the holder to a verifier.



On Fri, Sep 26, 2025 at 7:28 PM Andrii Deinega via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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.
>> 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
>>
>>
>> _______________________________________________
>> 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/400d38bb/attachment-0001.htm>