[Openid-specs-ab] OpenID Connect Key Binding :: Proposed WG Item

[Nick Dawson]

4


On Tue, Aug 12, 2025 at 11:39 AM Dick Hardt via Openid-specs-ab <o
mpenid-specs-ab at lists.openid.net> wrote:

> Hey Kosuke
>
> I don't follow the flow you are suggesting. Perhaps you can provide a
> sequence diagram?
>
> I think we want to dig in more on what happens with the platform call, as
> you want to bind the results of the attestation with the OIDC flow.
>
> Protecting the privacy of the user is one of the objectives of
> https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
> because it is targeting the issuer - holder - verifier flow -- which has
> different requirements than OIDC.
>
>
>
>
>
> On Tue, Aug 12, 2025 at 6:50 AM Kosuke Koiwai <kkoiwai at gmail.com> wrote:
>
>> Hi Dick and AB-ers,
>>
>> Thanks for the proposed draft.
>> I was thinking about almost the same thing and going to present at the
>> next IIW.
>> I also want the cnf claim in an ID token, but with OAuth2.0
>> Attestation-Based Client Authentication.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
>>
>> My intended use case is a mobile app. A flow would follow like this:
>> 1. The app and OP establish trust (with attestation mechanisms from
>> platforms), and the app gets a Client Attestation JWT.
>> 2. The app sends PAR to OP with Client Attestation JWT and PoP JWT.
>> 3. The app opens a browser and completes login, redirecting back to the
>> app.
>> 4. The app obtains an ID token (with cnf claim), Access Token from the
>> OP's Token endpoint using usual code, etc., and Client Attestation JWT
>> and PoP JWT.
>> 5. The app sends the ID token, Access Token, and DPoP(using the same
>> key to the Client Attestation JWT) to a Resource Server
>> 6. The RS can verify the DPoP with the cnf claim in the ID token, thus
>> holder binding is achieved.
>>
>> I want this because the app and OP already establish trust using a
>> Client Attestation JWT and sending DPoP to the Token endpoint is kind
>> of redundant.
>> Adding a cnf claim to the ID token can be achieved without a huge
>> implementation, and the authentication module on the app doesn't have
>> to be modified to do this addition because it can just ignore the cnf
>> claim if the module doesn't recognize it.
>> For RS, as well, it can read the cnf claim and make the token
>> holder-bound only if RS wants.
>> As such, just adding the cnf claim in an ID token is very easy for
>> existing implementations to accommodate.
>>
>> Do you think the above use case can be added to your proposed draft?
>>
>> Thanks,
>> Kosuke
>>
>>
>>
>> 2025年8月12日(火) 6:11 Brian Campbell via Openid-specs-ab
>> <openid-specs-ab at lists.openid.net>:
>> >
>> > I, for one, am not available for this coming Thursday's WG meeting.
>> >
>> > On Mon, Aug 11, 2025 at 10:27 AM Dick Hardt <dick.hardt at gmail.com>
>> wrote:
>> >>
>> >> Hey
>> >>
>> >> Ethan and I are offering the attached document as a contribution to
>> the Connect WG.
>> >>
>> >> Mike / Nat: is there room on the agenda this coming Thursday to
>> discuss?
>> >>
>> >> For those of you that don't know him, Ethan worked on OpenPubkey and
>> now works at Cloudflare.
>> >>
>> >> There is very little new normative language in this spec. We are
>> building on the great work done by:
>> >>
>> >> Daniel Fett
>> >> Brian Campbell
>> >> John Bradley
>> >> Torsten Lodderstedt
>> >> Michael Jones
>> >> David Waite
>> >>
>> >>
>> >> in
>> >>
>> >>  RFC9449 - OAuth 2.0 Demonstrating Proof of Possession
>> >>
>> >> and profiling it for OpenID Connect.
>> >>
>> >> Here is the repo where you can file issues / comments / PRs
>> >>
>> >> https://github.com/dickhardt/openid-key-binding
>> >>
>> >> /Dick and Ethan
>> >>
>> >>
>> >
>> > 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
>>
> _______________________________________________
> 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/20250814/2c329e31/attachment.htm>