<div dir="ltr"><div dir="ltr"><div dir="ltr">> For my intended use case though, I would have OP interpret/digest the</div>attestation from the OSes and add a claim to represent some kind of<br>"assurance levels."</div><div dir="ltr"><br></div><div>You can do that, but an assurance level would be difficult to standardize, but including an application identifier from the OS could be standardized. </div><div dir="ltr"><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Aug 14, 2025 at 4:03 PM Kosuke Koiwai <<a href="mailto:kkoiwai@gmail.com">kkoiwai@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think that's a great idea!<br>
For my intended use case though, I would have OP interpret/digest the<br>
attestation from the OSes and add a claim to represent some kind of<br>
"assurance levels."<br>
Because the OP and RP are the same entity in my case, RP doesn't have<br>
to verify the attestation again.<br>
<br>
2025年8月14日(木) 19:02 Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>>:<br>
><br>
> Thanks Kosuke<br>
><br>
> Would it be useful to include claims from the software assertion in the id_token?<br>
><br>
> On Thu, Aug 14, 2025 at 5:25 AM Kosuke Koiwai <<a href="mailto:kkoiwai@gmail.com" target="_blank">kkoiwai@gmail.com</a>> wrote:<br>
>><br>
>> Thanks Dick, good points.<br>
>><br>
>> I think PAR is not necessary in general as long as PKCE is used and<br>
>> PoP JWT is sent to the Token endpoint. However, I also think PAR is<br>
>> useful because OP can make sure that the authorization request comes<br>
>> from the genuine app.<br>
>> I meant that the assertion requests to the OS are requests to sign<br>
>> with a key that the OS has.<br>
>><br>
>> Kosuke<br>
>><br>
>> 2025年8月14日(木) 0:29 Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>>:<br>
>> ><br>
>> > Is an assertion request a signing by the OS?<br>
>> ><br>
>> > Why PAR instead of a regular authorization request?<br>
>> ><br>
>> > Looks like you are missing the mobile app requesting the nonce. :)<br>
>> ><br>
>> > Why does the RP get both the id token and the access token? Not sure it matters for our discussion.<br>
>> ><br>
>> > It would be useful to add in what is included in each of the calls. Is the attestation only passed in the PAR request?<br>
>> ><br>
>> > 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<br>
>> ><br>
>> > On Wed, Aug 13, 2025 at 9:27 AM Kosuke Koiwai <<a href="mailto:kkoiwai@gmail.com" target="_blank">kkoiwai@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Thanks for the feedback!<br>
>> >><br>
>> >> Can you see the diagram here?<br>
>> >> <a href="https://drive.google.com/file/d/1-Og5iNYIFMzYS3kvLndxe2jaDDdJUiYr/view" rel="noreferrer" target="_blank">https://drive.google.com/file/d/1-Og5iNYIFMzYS3kvLndxe2jaDDdJUiYr/view</a><br>
>> >><br>
>> >> Regarding your concern, my use case is that OP and RP are the same<br>
>> >> entity and the app only logs in to one OP.<br>
>> >><br>
>> >> 2025年8月12日(火) 18:39 Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>>:<br>
>> >> ><br>
>> >> > Hey Kosuke<br>
>> >> ><br>
>> >> > I don't follow the flow you are suggesting. Perhaps you can provide a sequence diagram?<br>
>> >> ><br>
>> >> > 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.<br>
>> >> ><br>
>> >> > Protecting the privacy of the user is one of the objectives of <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/</a> because it is targeting the issuer - holder - verifier flow -- which has different requirements than OIDC.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Tue, Aug 12, 2025 at 6:50 AM Kosuke Koiwai <<a href="mailto:kkoiwai@gmail.com" target="_blank">kkoiwai@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Hi Dick and AB-ers,<br>
>> >> >><br>
>> >> >> Thanks for the proposed draft.<br>
>> >> >> I was thinking about almost the same thing and going to present at the next IIW.<br>
>> >> >> I also want the cnf claim in an ID token, but with OAuth2.0<br>
>> >> >> Attestation-Based Client Authentication.<br>
>> >> >> <a href="https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/</a><br>
>> >> >><br>
>> >> >> My intended use case is a mobile app. A flow would follow like this:<br>
>> >> >> 1. The app and OP establish trust (with attestation mechanisms from<br>
>> >> >> platforms), and the app gets a Client Attestation JWT.<br>
>> >> >> 2. The app sends PAR to OP with Client Attestation JWT and PoP JWT.<br>
>> >> >> 3. The app opens a browser and completes login, redirecting back to the app.<br>
>> >> >> 4. The app obtains an ID token (with cnf claim), Access Token from the<br>
>> >> >> OP's Token endpoint using usual code, etc., and Client Attestation JWT<br>
>> >> >> and PoP JWT.<br>
>> >> >> 5. The app sends the ID token, Access Token, and DPoP(using the same<br>
>> >> >> key to the Client Attestation JWT) to a Resource Server<br>
>> >> >> 6. The RS can verify the DPoP with the cnf claim in the ID token, thus<br>
>> >> >> holder binding is achieved.<br>
>> >> >><br>
>> >> >> I want this because the app and OP already establish trust using a<br>
>> >> >> Client Attestation JWT and sending DPoP to the Token endpoint is kind<br>
>> >> >> of redundant.<br>
>> >> >> Adding a cnf claim to the ID token can be achieved without a huge<br>
>> >> >> implementation, and the authentication module on the app doesn't have<br>
>> >> >> to be modified to do this addition because it can just ignore the cnf<br>
>> >> >> claim if the module doesn't recognize it.<br>
>> >> >> For RS, as well, it can read the cnf claim and make the token<br>
>> >> >> holder-bound only if RS wants.<br>
>> >> >> As such, just adding the cnf claim in an ID token is very easy for<br>
>> >> >> existing implementations to accommodate.<br>
>> >> >><br>
>> >> >> Do you think the above use case can be added to your proposed draft?<br>
>> >> >><br>
>> >> >> Thanks,<br>
>> >> >> Kosuke<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> 2025年8月12日(火) 6:11 Brian Campbell via Openid-specs-ab<br>
>> >> >> <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>:<br>
>> >> >> ><br>
>> >> >> > I, for one, am not available for this coming Thursday's WG meeting.<br>
>> >> >> ><br>
>> >> >> > On Mon, Aug 11, 2025 at 10:27 AM Dick Hardt <<a href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</a>> wrote:<br>
>> >> >> >><br>
>> >> >> >> Hey<br>
>> >> >> >><br>
>> >> >> >> Ethan and I are offering the attached document as a contribution to the Connect WG.<br>
>> >> >> >><br>
>> >> >> >> Mike / Nat: is there room on the agenda this coming Thursday to discuss?<br>
>> >> >> >><br>
>> >> >> >> For those of you that don't know him, Ethan worked on OpenPubkey and now works at Cloudflare.<br>
>> >> >> >><br>
>> >> >> >> There is very little new normative language in this spec. We are building on the great work done by:<br>
>> >> >> >><br>
>> >> >> >> Daniel Fett<br>
>> >> >> >> Brian Campbell<br>
>> >> >> >> John Bradley<br>
>> >> >> >> Torsten Lodderstedt<br>
>> >> >> >> Michael Jones<br>
>> >> >> >> David Waite<br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> >> in<br>
>> >> >> >><br>
>> >> >> >>  RFC9449 - OAuth 2.0 Demonstrating Proof of Possession<br>
>> >> >> >><br>
>> >> >> >> and profiling it for OpenID Connect.<br>
>> >> >> >><br>
>> >> >> >> Here is the repo where you can file issues / comments / PRs<br>
>> >> >> >><br>
>> >> >> >> <a href="https://github.com/dickhardt/openid-key-binding" rel="noreferrer" target="_blank">https://github.com/dickhardt/openid-key-binding</a><br>
>> >> >> >><br>
>> >> >> >> /Dick and Ethan<br>
>> >> >> >><br>
>> >> >> >><br>
>> >> >> ><br>
>> >> >> > 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._______________________________________________<br>
>> >> >> > Openid-specs-ab mailing list<br>
>> >> >> > <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
>> >> >> > <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div></div></div>