<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Attendees:<div><br></div><div>Joseph Heenan</div><div>Takahiko Kawasaki</div><div>Kristina Yasuda</div><div>David Chadwick</div><div>Brian Campbell</div><div>Torsten Lodderstedt</div><div>Niels Klomp</div><div>Vittorio Bertocci</div><div>Oliver Terbu</div><div>Bjorn Hjelm</div><div>Jeremie Miller</div><div><br></div><div><br></div><div><br></div><div>Kristina/Torsten mentioned the new drafts and covered the rework that has been done in these new drafts, much of which was driven by feedback from the European Union & ISO - as per Torsten’s announcement:</div><div><br></div><div><div>https://openid.net/specs/openid-4-verifiable-presentations-1_0.html</div><div><br></div><div><ul class="MailOutline"><li>added support for signed and encrypted authorization responses based on JARM</li><li>clarified response encoding for authorization responses</li><li>moved invocation/just-in-time client metadata exchange/AS Discovery sections from siopv2 to openid4vp</li></ul></div><div><br></div><div>https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html</div><div><br></div><div><ul class="MailOutline"><li>introduced differentiation between credential issuer and authorization server</li><li>relaxed client identification requirements for pre-authorized code grant type</li><li>renamed issuance initiation endpoint to Credential Offer Endpoint</li><li>added grants structure to credential offer</li></ul></div></div><div><div><br></div><div><br></div></div><div>Feedback on structure / readability is very welcome.</div><div><br></div><div><br></div><div><br></div><div>Brian: Structure & content is hard</div><div><br></div><div>Vittorio: Same device seems to be treated as main/default flow, with cross device being a variant. Would expect them to be at the same level. No preamble explaining which device is taking which role in cross device flow. The VCI spec is hard to read without having read VP first. When SIOP spec links to VP, it should include a bit of explanation as well. Should not assume people have already read the other specs, each doc should stand on its own legs.</div><div><br></div><div>Kristina: Please do raise PRs for any editorial issues like capitalisation etc. Anything non-editorial</div><div><br></div><div>Torsten: We should be able to simplify the SIOP spec by referencing the other specs.</div><div><br></div><div>Vittorio: If the specs are separate, they should standalone. The concepts/purpose should be explained when SIOP links to other specs.</div><div><br></div><div>Torsten: Worries that this might result if things being explained in two places they might get out of sync</div><div><br></div><div>Vittorio: Agrees normative text should not be repeated, and OAuth2 doesn’t need to be explained from first principles. But e.g. Section 7.2 of SIOP says "as defined in section x of blah” - it should have a sentence “There is a mechanism that does <x> that is defined in <spec y>”.</div><div><br></div><div>Torsten/Kristina agreed, will look into it, please do raise issues.</div><div><br></div><div>Brian provides a specific example of an example in SIOP that says it’s a signed request, but isn’t signed, and that uses DID but doesn’t really explain how DID is being used.</div><div><br></div><div>Kristina: DID use is explained in https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#DID</div><div><br></div><div><br></div><div><br></div><div>Please review pull requests:</div><div><br></div><div>391 Editorial</div><div><br></div><div>387 Editorial 4VP cleanup</div><div><br></div><div>359 clarify client behaviour with regard to nonces</div><div>May need Richard on a call to discuss.</div><div> </div><div>360 access token hash - no consensus in WG yet</div><div><br></div><div>384 Add CWT proof type</div><div>Torsten would really appreciate if someone familiar with CWT could review this.</div><div>Brian noted it mentions JWT in a number of places that are C&P errors.</div><div><br></div><div>389 passing credential offer by reference</div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/pull-requests/374">https://bitbucket.org/openid/connect/pull-requests/374</a></div><div><br></div><div>Kristina will help resolve conflicts.</div><div><br></div><div><br></div><div><a href="https://bitbucket.org/openid/connect/issues/1412/add-wallet-attestation-to-the-siop">https://bitbucket.org/openid/connect/issues/1412/add-wallet-attestation-to-the-siop</a></div><div><br></div><div>David asked if the wallet or the wallet provider would sign the response. Torsten said it could be either, but that there’s no real world implementation experience of this yet.</div><div><br></div><div>Kristina suggested closing if it’s already clear that JARM can be used to sign responses.</div><div><br></div><div><br></div></body></html>