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

[Tom Jones]

This email is designed to be controversial, not so much to create an
argument as to act as a gut check to the OIDF general direction.

Assertions:
1. The primary source of privacy issues arise from the misuse of the User
Issue Endpoint.
2. The best way to improve the privacy profile of access methods is to
remove the User Issue Endpoint.

I believe these assertions match the general trend of access management in
the past few years.
I would like to explore the elimination of the User Issue Endpoint in all
future access methods.

The current alternative of interest to me is creating policy statements
and/or credentials that can flow from the user to the agents.

Peace ..tom jones


On Thu, Sep 4, 2025 at 6:16 AM Brian Campbell via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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.*_______________________________________________
> 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/20250904/133abe4c/attachment-0001.htm>