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

[Dick Hardt]

> For my intended use case though, I would have OP interpret/digest the
attestation from the OSes and add a claim to represent some kind of
"assurance levels."

You can do that, but an assurance level would be difficult to standardize,
but including an application identifier from the OS could be standardized.

On Thu, Aug 14, 2025 at 4:03 PM Kosuke Koiwai <kkoiwai at gmail.com> wrote:

> I think that's a great idea!
> For my intended use case though, I would have OP interpret/digest the
> attestation from the OSes and add a claim to represent some kind of
> "assurance levels."
> Because the OP and RP are the same entity in my case, RP doesn't have
> to verify the attestation again.
>
> 2025年8月14日(木) 19:02 Dick Hardt <dick.hardt at gmail.com>:
> >
> > 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/20250815/e02c831e/attachment.htm>