[Openid-specs-ab] OpenID Connect Key Binding vs OpenID Connect UserInfo Verifiable Credentials

Sun Sep 7 17:18:53 UTC 2025

+ Aaron as you mentioned him

>  The reason it was abandoned was that Aaron Parecki and some others noted
that using the ID token here for anything other than DPoP-authenticated
HTTP requests results in the reuse of the DPoP key in different contexts,
creating a risk of cross-protocol attacks.  So for example it would be
problematic to do BastionZero-like or SigStore-like things with this ID
token.

Aaron was on the call we just had, and did not voice his concerns.

In the security considerations, the key used for key binding MUST be
different than the key used in other contexts. This applies equally to a VC
based approach.
We should also restrict DPoP for access token binding to be independent for
id_tokens.

Cross protocol JWT confusion is a problem for any JWT, including the VC
approach -- and requires a verifier to correctly verify the JWTs they
receive.

> zero OP interest

We have deployed this draft at Hellō for people to experiment with. My
interest in a VC based token that is not an id_token is low. There is
little understanding and machinery for VCs today. Building on the id_token
is much more palatable than creating brand new tokens.

I'm responding to George's email right after this which may provide more
context on the id_token focus.

/Dick

On Fri, Sep 5, 2025 at 9:46 PM Richard Barnes <rlb at ipv.sx> wrote:

> Hi Mike,
>
> To be blunt: The relationship between the two drafts is that the approach
> in the Key Binding draft was considered and rejected by our author team
> before we put forward the VC-based draft.
>
> I totally understand how the authors arrived at this scheme; it's one I
> have proposed myself before.  The reason it was abandoned was that Aaron
> Parecki and some others noted that using the ID token here for anything
> other than DPoP-authenticated HTTP requests results in the reuse of the
> DPoP key in different contexts, creating a risk of cross-protocol attacks.
> So for example it would be problematic to do BastionZero-like or
> SigStore-like things with this ID token.  The reason we went the VC route
> is that VC are intended to be used in different protocols, and you can mint
> multiple VCs to support different applications.
>
> You are correct that at this point the UserInfo VC draft is basically
> abandoned.  But only because there was basically zero OP interest in
> implementing as far as I could tell.  I still think the approach is
> correct, and the use cases are valuable (including Ethan and Dick's use
> cases).  If OPs were interested, I would be excited to consume it in Webex.
>
> If there's new energy here, I would propose we revive the VC draft and
> rebase it on the latest VCI stuff, probably the simpler SD-JWT-VC stuff out
> of OAuth rather than anything from W3C.
>
> Cheers,
> --Richard
>
>
> On Thu, Sep 4, 2025 at 2:46 PM Michael Jones <michael_b_jones at hotmail.com>
> wrote:
>
>> Dear Morteza, Richard, Pieter, and Kristina,
>>
>>
>>
>> I am writing as an OpenID Connect working group chair to ask you what
>> your plans are for the UserInfo VC draft (
>> https://openid.net/specs/openid-connect-userinfo-vc-1_0.html).  The
>> current draft is over 2 years old and is the -00 draft.  Furthermore, I
>> observed that it uses VCDM 1.1, rather than VCDM 2.0 which replaced it.
>>
>>
>>
>> Is one of you planning to continue working on the draft or should the
>> working group consider it to be inactive?
>>
>>
>>
>> Part of the context of the question is that Dick Hardt and Ethan Heilman
>> have created the OpenID Connect Key Binding draft (
>> https://github.com/dickhardt/openid-key-binding), which like your draft,
>> uses key binding to an OpenID Connect issued token – but their draft binds
>> the ID Token, rather than the UserInfo response.  The working group is
>> discussing whether to adopt their draft.
>>
>>
>>
>> We wanted to understand the relationship between your work and their work
>> before potentially issuing a call for adoption.
>>
>>
>>
>> Thanks for any information you can provide.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
>> Behalf Of *Brian Campbell via Openid-specs-ab
>> *Sent:* Thursday, September 4, 2025 6:15 AM
>> *To:* Dick.Hardt at gmail.com; Artifact Binding/Connect Working Group <
>> openid-specs-ab at lists.openid.net>
>> *Cc:* Brian Campbell <bcampbell at pingidentity.com>;
>> ethan.r.heilman at gmail.com
>> *Subject:* Re: [Openid-specs-ab] OpenID Connect Key Binding vs OpenID
>> Connect UserInfo Verifiable Credentials
>>
>>
>>
>> I suspect the intent of the homework runs a little deeper. Like perhaps
>> coordinating with the UserInfo Verifiable Credentials authors to see if
>> they are interested in reengaging with the work. Or understanding the
>> rationale for some of the design decisions made - id token vs. userinfo
>> endpoint vs. credential issuance endpoint being one that seems particularly
>> relevant but just one.
>>
>>
>>
>> On Thu, Aug 21, 2025 at 11:39 AM Dick Hardt via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>> Here is my homework as assigned by the working group chair. :)
>>
>>
>>
>> KB = OpenID Connect Key Binding
>>
>> UVC = OpenID Connect UserInfo Verifiable Credentials
>>
>> Links to specs at bottom
>>
>>
>>
>>
>> *Tl;dr: *KB adds the key to an ID Token
>> UVC creates a verifiable credential with same info, but VC syntax
>>
>> KB does it in one call to OP
>>
>> UVC requires two calls to OP
>>
>>
>>
>> *Key Bound Token*
>>
>> KB outputs an id_token that includes a `cnf` claim of the public key
>>
>> UVC outputs a verifiable credential with a `did:jwk:ey...` claim
>> Both include all the same user claims
>>
>>
>>
>>
>>
>> *Authentication Request*
>>
>> - KB uses `dpop` scope as well as `dpop_jkt` parameter
>>
>> - UVC uses `userinfo_credential`
>>
>>
>>
>> KB has extra layer of security as `dpop_jkt` provides additional
>> assurance between authentication request and token request
>>
>>
>> *Token Request*
>>
>> - KB - RP passes DPoP JWT as header
>>
>> - UVC has no changes
>>
>>
>>
>> *Token Response*
>>
>> - KB - OP passes back id_token that includes `cnf` claim
>>
>> - UVC - OP passes back an access_token as well as c_nonce and
>> c_nonce_expires_in
>>
>>
>>
>> At this point, KB has completed the key binding ...
>>
>>
>>
>> *Credential Request and Response *
>>
>> UVC continues on
>>
>> - RP generates a verifiable credential request and passes it with the
>> access_token as a bearer token to the OP's credential endpoint
>>
>> - OP returns a verifiable credential
>>
>>
>>
>>
>>
>> https://dickhardt.github.io/openid-key-binding/main.html
>>
>> https://github.com/dickhardt/openid-key-binding
>>
>>
>>
>> https://openid.net/specs/openid-connect-userinfo-vc-1_0.html
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250907/423a5c4a/attachment.htm>