<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Attendees:</div><div class=""><br class=""></div><div class="">Joseph Heenan</div><div class="">David Chadwick</div><div class="">Brian Campbell</div><div class="">Torsten Lodderstedt</div><div class="">Kristina Yasuda</div><div class="">Mike Jones</div><div class="">Nat Sakimura</div><div class="">David Waite</div><div class="">John Bradley</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><a href="https://bitbucket.org/openid/connect/pull-requests/176" class="">https://bitbucket.org/openid/connect/pull-requests/176</a></div><div class=""><br class=""></div><div class="">Agreed that SIOP is an informative reference</div><div class=""><br class=""></div><div class="">Discussion about <span style="caret-color: rgb(23, 43, 77); color: rgb(23, 43, 77); font-family: SFMono-Medium, "SF Mono", "Segoe UI Mono", "Roboto Mono", "Ubuntu Mono", Menlo, Consolas, Courier, monospace; font-size: 12.25px; letter-spacing: -0.07000000029802322px; white-space: pre-wrap; background-color: rgba(9, 30, 66, 0.08);" class="">presentation_submission</span> as a mandatory extra parameter; David Chadwick said it’s unnecessary as it’s already in the VP and you have to process the VP. Torsten said there are formats where it can’t be in the VP, for example ISO mobile driving license. David doesn’t think this matches the W3C definition of a VP. VP is not defined to require JSON (this was agreed).</div><div class=""><br class=""></div><div class="">There was discussion about whether an MDL needs an outer wrapper to allow it’s type to be defined. Torsten said this was essentially was presentation_submission achieves.</div><div class=""><br class=""></div><div class="">David said that VCs shouldn’t contain presentation_submission then, as it could cause issues where there are then two presentation_submissions which aren’t the same.</div><div class=""><br class=""></div><div class="">Kristina will open a separate issue for this to be considered, and hence it was agreed this PR can be merged as-is to unblock other work.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><a href="https://bitbucket.org/openid/connect/pull-requests/145" class="">https://bitbucket.org/openid/connect/pull-requests/145</a> - Revises the approach to credential metadata publishing</div><div class=""><br class=""></div><div class="">Discussion about whether there should be a top level object per language/locale or use the OIDC type approach of having one object but having the claim name have things like "#fr-CA” appended.</div><div class=""><br class=""></div><div class="">It was agreed we need a solution for this. Torsten suggested that perhaps display information within the claims information should be moved to the display object.</div><div class=""><br class=""></div><div class="">David mentioned a different problem that the claims need be displayed in particular orders in some cases, which isn’t currently possible.</div><div class=""><br class=""></div><div class="">Kristina will try to produce a new proposal based on today’s discussion; David Waite offered to help.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><a href="https://bitbucket.org/openid/connect/pull-requests/157" class="">https://bitbucket.org/openid/connect/pull-requests/157</a> - Building Trust between Wallet and Issuer</div><div class=""><br class=""></div><div class="">Probably good now. Kristina to do final review.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><a href="https://bitbucket.org/openid/connect/pull-requests/152" class="">https://bitbucket.org/openid/connect/pull-requests/152</a> - OP Identification/Attestation</div><div class=""><br class=""></div><div class="">Torsten suggested using JARM ( <a href="https://openid.net/specs/openid-financial-api-jarm-ID1.html" class="">https://openid.net/specs/openid-financial-api-jarm-ID1.html</a> - currently being finalised by FAPI WG) to solve this by signing the response with a key under the control of the provider (rather than the user). John asked how the verifier could find the key. Torsten said this might come from an ecosystem trust registry or from out of band knowledge of a jwks_uri. John wanted to give it more thought. Torsten suggested he creates a new PR and that 152 is a dead end and should be closed, which was agreed.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><a href="https://bitbucket.org/openid/connect/pull-requests/189" class="">https://bitbucket.org/openid/connect/pull-requests/189</a> - encoding of the issued vc</div></div><div class=""><br class=""></div><div class="">Good progress been made. Still some comments from Mike Jones to be addressed.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>