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

[Jacob Ideskog]

Hi all,

I'd like to chip in on the semantics of the two approaches.

The way I've always interpreted the id_token vs the user info is the
following:

The *id_token* represents the authentication transaction that just took
place. For that reason it contains important non-profile information such
as auth_time, acr, amr etc which are useful for the RP when deciding if the
authentication that took place is strong enough, fresh enough etc. It *can*
also contain a number of useful claims about the account or the user but at
a minimum it needs the subject in some form.

The *user info *on the other hand is mainly governed by the profile scope
and sibling scopes. It does not contain authentication specific information
but rather only account specific details.

In our implementation we tend to recommend adding account/user claims in
the ID token if you think the RP needs them to save them the round trip for
user info, but it's optional and up to the particular use-case. For
instance if you intend to share the ID token as this spec proposes, then
adding account claims should be weighed against the privacy posture
required.

That said, to me, issuing a proof based on user info is less valuable to a
3rd party as it would not contain the authentication specific details that
may matter to that party as well. If nothing else, the auth_time is
generally valuable. It could also convey details about how long the OP
considers the session to be valid for if you chose to interpret the exp as
such.
Issuing a bound ID token seems more to the point if that's the main
use-case we're after. If all we want to do is share user info details to
another party then a credential would do.

It sounds like they solve different problems and should not be mixed.

Just my 2¢

/Jacob Ideskog







On Thu, 21 Aug 2025 at 19:39, 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
>


-- 
Jacob Ideskog
CTO
Curity
-------------------------------------------------------------------
Sankt Göransgatan 66, Stockholm, Sweden
M: +46 70-2233664
j <jacob at twobo.com>acob at curity.io
curity.io
-------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250905/cc30b4bc/attachment.htm>