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

[Kosuke Koiwai]

Thanks for the feedback!

Can you see the diagram here?
https://drive.google.com/file/d/1-Og5iNYIFMzYS3kvLndxe2jaDDdJUiYr/view

Regarding your concern, my use case is that OP and RP are the same
entity and the app only logs in to one OP.

2025年8月12日(火) 18:39 Dick Hardt <dick.hardt at gmail.com>:
>
> 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