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

[Dick Hardt]

Thanks Kosuke

Would it be useful to include claims from the software assertion in the
id_token?

On Thu, Aug 14, 2025 at 5:25 AM Kosuke Koiwai <kkoiwai at gmail.com> wrote:

> Thanks Dick, good points.
>
> I think PAR is not necessary in general as long as PKCE is used and
> PoP JWT is sent to the Token endpoint. However, I also think PAR is
> useful because OP can make sure that the authorization request comes
> from the genuine app.
> I meant that the assertion requests to the OS are requests to sign
> with a key that the OS has.
>
> Kosuke
>
> 2025年8月14日(木) 0:29 Dick Hardt <dick.hardt at gmail.com>:
> >
> > Is an assertion request a signing by the OS?
> >
> > Why PAR instead of a regular authorization request?
> >
> > Looks like you are missing the mobile app requesting the nonce. :)
> >
> > Why does the RP get both the id token and the access token? Not sure it
> matters for our discussion.
> >
> > It would be useful to add in what is included in each of the calls. Is
> the attestation only passed in the PAR request?
> >
> > To not force others to use PAR, I would pass the attestation in the
> token request. This would require some mechanism to bind the attestation to
> the token request
> >
> > On Wed, Aug 13, 2025 at 9:27 AM Kosuke Koiwai <kkoiwai at gmail.com> wrote:
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20250814/8cd0cf9b/attachment-0001.htm>