<div dir="ltr"><div dir="ltr">Thanks for the updates Kristina. I left a few comments in the PR.<input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false,"sms":false},"attachments":{},"compose-id":"1","compose-window":{"secure":false}}"><div><br></div><div>One other high-level thoughts I had after the WG discussion is, that in the case of Device Auth, new parameters were defined. In this cross-user_agent/device use case, it's a bit more like the Device Auth flow. I don't know if that is helpful to the editors as you all consider existing or new parameters. The Device Auth flow does not define how the second user-agent/device authenticates/consents (left out of scope). In this VP case, we are looking to standardize that other flow. I don't know that I have a strong position one way or another, it's just an additional perspective to consider.</div><div><br></div><div>Thanks,</div><div>George</div></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Tue, Oct 25, 2022 at 3:40 AM Kristina Yasuda via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</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"><div class="msg5694884009827428672">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_5694884009827428672WordSection1">
<p class="MsoNormal">Response_mode=post PR has been updated with the new value direct_post and better description:
<a href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/327__;!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eB_S0wt8w$" target="_blank">https://bitbucket.org/openid/connect/pull-requests/327</a><u></u><u></u></p>
<p class="MsoNormal">We will discuss with the editors wrt defining a new parameter vs reusing response_mode.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Inspired by the discussion, also did an editorial PR clarifying concepts in OpenID4VP spec:
<a href="https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/327__;!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eB_S0wt8w$" target="_blank">https://bitbucket.org/openid/connect/pull-requests/327</a>
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
<p class="MsoNormal">Kristina<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span>From:</span></b><span> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Mike Jones via Openid-specs-ab<br>
<b>Sent:</b> Tuesday, October 25, 2022 12:28 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Cc:</b> Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><br>
<b>Subject:</b> [Openid-specs-ab] Spec Call Notes 24-Oct-22<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Spec Call Notes 24-Oct-22<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mike Jones<u></u><u></u></p>
<p class="MsoNormal">Vittorio Bertocci<u></u><u></u></p>
<p class="MsoNormal">George Fletcher<u></u><u></u></p>
<p class="MsoNormal">Kristina Yasuda<u></u><u></u></p>
<p class="MsoNormal">Dima Postnikov<u></u><u></u></p>
<p class="MsoNormal">Tom Jones<u></u><u></u></p>
<p class="MsoNormal">David Waite (DW)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Errata Updates<u></u><u></u></p>
<p class="MsoNormal"> Mike created 7 errata PRs<u></u><u></u></p>
<p class="MsoNormal"> They have [Errata] at the beginning of the subject line<u></u><u></u></p>
<p class="MsoNormal"> He plans to merge them in a week after they were created unless comments are received<u></u><u></u></p>
<p class="MsoNormal"> He noted that in the past, he simply pushed errata updates to master<u></u><u></u></p>
<p class="MsoNormal"> Because the working group had already decided how to address them<u></u><u></u></p>
<p class="MsoNormal"> Given the WG's increasing use of PRs, he created PRs this time to enable people to comment before merging<u></u><u></u></p>
<p class="MsoNormal"> Addressing the open errata issues is part of preparing for ISO PAS submission<u></u><u></u></p>
<p class="MsoNormal"> See the open errata issues at<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbitbucket.org*2Fopenid*2Fconnect*2Fissues*3Fstatus*3Dnew*26status*3Dopen*26milestone*3DErrata&data=05*7C01*7CKristina.Yasuda*40microsoft.com*7Cf3814bd398044e7861c308dab65a6b88*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638022796813293038*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=LqNCHh5CZtjvOnmbW3b4l4W2uaUlSGfEEa1cSbYFxAU*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eBpRvDhPA$" target="_blank">
https://bitbucket.org/openid/connect/issues?status=new&status=open&milestone=Errata</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Pull Requests<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbitbucket.org*2Fopenid*2Fconnect*2Fpull-requests*2F&data=05*7C01*7CKristina.Yasuda*40microsoft.com*7Cf3814bd398044e7861c308dab65a6b88*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638022796813293038*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=cwEROrtI*2Bdbl6tnhnYGXKvdURLm9Mxp9sef4bt*2BqHlE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eB61vT7Aw$" target="_blank">
https://bitbucket.org/openid/connect/pull-requests/</a><u></u><u></u></p>
<p class="MsoNormal"> PR #335: chore: [Federation] disambiguations on the federation entity role<u></u><u></u></p>
<p class="MsoNormal"> We need to address Roland's comments<u></u><u></u></p>
<p class="MsoNormal"> PR #327: clarified the definition of response mode post - Issue #1626<u></u><u></u></p>
<p class="MsoNormal"> Kristina requested that George review<u></u><u></u></p>
<p class="MsoNormal"> We discussed the naming suggestions from the 13-Oct-22 SIOP special topic call<u></u><u></u></p>
<p class="MsoNormal"> George is good with Joseph's name direct_post<u></u><u></u></p>
<p class="MsoNormal"> This is different from other response modes because it can cross devices, rather than use a redirect<u></u><u></u></p>
<p class="MsoNormal"> George said that direct_post is the only mode that makes sense cross-device<u></u><u></u></p>
<p class="MsoNormal"> George said that direct_post with a cloud wallet is an interesting context<u></u><u></u></p>
<p class="MsoNormal"> Vittorio asked whether there are any other response types or response modes that result in cross-device flows<u></u><u></u></p>
<p class="MsoNormal"> He's not sure why we're trying to reuse an existing parameter rather than defining a new one<u></u><u></u></p>
<p class="MsoNormal"> He said that using a client as an authorization server is confusing<u></u><u></u></p>
<p class="MsoNormal"> Kristina said that it's well-defined for a native application to be able to do both<u></u><u></u></p>
<p class="MsoNormal"> He doesn't see a security issue - he just finds it to be unnatural<u></u><u></u></p>
<p class="MsoNormal"> Kristina said that these differences are why the introduction to OpenID4VP is long<u></u><u></u></p>
<p class="MsoNormal"> The PR is an attempt to describe this better<u></u><u></u></p>
<p class="MsoNormal"> Kristina said that developers have successfully built and deployed the specification<u></u><u></u></p>
<p class="MsoNormal"> The form_post response mode is defined at
<a href="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fopenid.net*2Fspecs*2Foauth-v2-form-post-response-mode-1_0.html*23FormPostResponseMode&data=05*7C01*7CKristina.Yasuda*40microsoft.com*7Cf3814bd398044e7861c308dab65a6b88*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638022796813449288*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=672av00AAkBJhRKpXkFvbQzvZnCGfWYkqBozQOoCRJw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eBDiezAZY$" target="_blank">
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html#FormPostResponseMode</a><u></u><u></u></p>
<p class="MsoNormal"> The response_mode parameter is registered with IANA<u></u><u></u></p>
<p class="MsoNormal"> The response mode values are not<u></u><u></u></p>
<p class="MsoNormal"> George suggested adding more context about the roles that are being played by different parties<u></u><u></u></p>
<p class="MsoNormal"> George agreed to make a comment on the PR<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Issues<u></u><u></u></p>
<p class="MsoNormal"> <a href="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbitbucket.org*2Fopenid*2Fconnect*2Fissues*3Fstatus*3Dnew*26status*3Dopen&data=05*7C01*7CKristina.Yasuda*40microsoft.com*7Cf3814bd398044e7861c308dab65a6b88*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638022796813449288*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=sTBJmEnBoI0J8OzAK2xUAjiglsxqA74C8tXjEJXNf1I*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eB__PJZok$" target="_blank">
https://bitbucket.org/openid/connect/issues?status=new&status=open</a><u></u><u></u></p>
<p class="MsoNormal"> #1681: [Federation] FAPI prohibits RS256<u></u><u></u></p>
<p class="MsoNormal"> Mike reported that the Federation editors agreed to the following resolution:<u></u><u></u></p>
<p class="MsoNormal"> “Implementations SHOULD support signature verification with RS256 because OpenID Connect Core requires support for RS256;<u></u><u></u></p>
<p class="MsoNormal"> Federations MAY also specify different mandatory-to-implement algorithms.”<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Next Call<u></u><u></u></p>
<p class="MsoNormal"> The next call is the SIOP Special Topic on Thursday, October 27th at 7am Pacific Time<u></u><u></u></p>
</div>
</div>
_______________________________________________<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://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eBgZNkdSQ$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!J4KNBJMskgPJj0WiqrbB1r380ztP4mHgIRYtG2cDomi1-D_w92E9BOhznjq5h_VmMj0urFxCvejDe4sTM7dtsubM6-ZAD1eBgZNkdSQ$</a> <br>
</div></blockquote></div></div>
<HR><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30"><BR>
<tr><BR>
<font color="#404040">The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.</font></td><BR>
</tr><BR>
</table><BR>