
<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;"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div><br></div><div>(Thanks to Oliver for taking notes!)</div><div><br></div><div>Attendees:</div><div><br></div><div>Kristina</div><div>Brian Campbell</div><div>Joseph Heenan</div><div>Oliver Terbu</div><div>Giuseppe De Marco</div><div>Julian (<a href="http://Identity.com">Identity.com</a>)</div><div>Takahiko Kawasaki</div><div>Felix Linker</div><div>Martin Riedel</div><div>Judith Kahler</div><div>Pedro Felix</div><div>Ramesh Narayanan</div><div><br></div><div>Agenda<br>- Intros<br>- External work<br>- Draft charter for new WG dedicated to OpenID4VC work<br>- PRs and issues<br><br></div><div># Intros<br><br>Felix Linker intro. PhD student in Zurich. In contact with Torsten and Daniel. Worked and was one of the lead authors of the OpenID4VC over BLE spec. Wants to contribute more in the future.<br><br>Julian: Software Engineer that works at <a href="http://identity.com/">identity.com</a> along with Martin Riedel.<br>External work<br>OWF due diligence TF kicking off this week.<br><a href="https://openwallet-foundation.github.io/tac/task-forces/OID4VC-due-diligence/">https://openwallet-foundation.github.io/tac/task-forces/OID4VC-due-diligence/</a><br>Torsten is co-leading it.<br>Good group of implementers of OpenID4VC.<br>Plan is to do some AMA by editors.<br>TF meets at Wednesday 5pm CEST, and might move to weekly cadence.<br>Draft charter:<br>The proposed charter was presented.<br><br>The link is here: <a href="https://docs.google.com/document/d/10pzVIpYF8gWVp2F6l0kinsBC9XVS5xZt4n55TzIcNLg/edit?usp=sharing">https://docs.google.com/document/d/10pzVIpYF8gWVp2F6l0kinsBC9XVS5xZt4n55TzIcNLg/edit?usp=sharing</a><br><br>The name of the WG is intentionally inclusive of multiple credential formats.<br><br>The name of the WG was discussed, and the scope. Specifically, discussions around the usage of the term three-party-model. The group found the issuer-holder-verifier model suited. <br><br>Charter also includes protocols such as SIOPv2 too that are required for issuer-holder-verifier use cases that don’t require credentials directly but contribute necessary supporting functions such as authentication in the case of SIOPv2.<br><br>Next steps:<br><br>The WG charter document is kept up for tomorrow and over the weekend. The WG would give the group a chance to have their own repository which is potentially hosted on Github. Everbody is invited to make comments in the proposed WG charter document. Comments and discussions will be resolved in the next SIOP call.<br><br>The main focus to get consensus on is the name of the WG.<br><br></div><div># Discussion on Figure 1 in OpenID4VCI<br><br>Taka noted that the box about the user in figure 1 should be made smaller. Also 2nd last line has a broken life lane.<br><br></div><div># PRs<br><br></div><div>## PR 539<br><br>It was noted that the spec should be only linked to PE 2.0, and not to 1.1. PE 2.0 is also a published specification. If anything else than PE 2.0 is linked then this should be fixed.<br><br>Only concern would then be a future PE 3.0 version.<br><br></div><div>### PE subtopic<br><br></div><div>Torsten mentioned that there will be a discussion of the evolutation of PE. Mainly around the richness of the syntax, and how selective disclosure and filtering is done with the same element. Goal is to make PE simpler and easier to get it secure. Today, filter expressions can include almost everything, also a full JSON schema, which is hard to parse and might create security issues.<br><br>Torsten invited the group to participate in that discussion with DIF.<br><br>Next steps:<br>OpenID4VC editors will have call with PE editors.<br>If the group has concerns about PE, then they should file issues in bitbucket or in the DIF PE repository until 3rd of july.<br><br>## PR 542<br>It was discussed whether same key proof can be used more than once. The answer is yes but it depends on the issuer. The specification does not make any requirements around that.<br><br></div><div>## PR 520<br>No time to discuss PR 520, but the group was invited to review PR 520.<br></div></div>

</body></html>