
<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;"><div>Hi,</div><div><br></div><div>Below are the meeting minutes from the working group call May 15th.</div><div><br></div><div>Best Regards,</div><div>Christian</div><div><br></div><div><br></div><div><br></div><div>--- Attendees:</div><div><br></div><div>Bjorn Hjelm</div><div>Brian Campbell</div><div>Christian Bormann</div><div>Cosmin Mogos</div><div>Daniel Fett</div><div>David Zeuthen</div><div>Gareth Oliver</div><div>George Fletcher</div><div>Jan Vereecken</div><div>Jin Wen</div><div>Joseph Heenan</div><div>Juba Saadi</div><div>Ketan Mehta</div><div>Kristina Yasuda</div><div>Lee Campbell</div><div>Lukasz Jaromin</div><div>Martijn Haring</div><div>Max Crone</div><div>Michael Jones</div><div>Mirko Mollik</div><div>Oliver Terbu</div><div>Peter Sorotokin</div><div>Samuel Rinnetmäki</div><div>Tim cappalli</div><div>Timo Glastra</div><div>Torsten Lodderstedt</div><div><br></div><div>— Events/<span style="color: rgb(0, 0, 0); orphans: 2; text-wrap-mode: wrap; widows: 2;">Announcements:</span></div><div><br></div><div>- EC / ETSI / OpenID sync meeting: There seems to be some alignment to setup a closer collaboration and discuss specific details in the specifications. ESI + DCP chairs meeting is coming up and in general, the OpenID / ETSI liaison is set up, so all requirements for good collaboration seem to be there.</div><div><br></div><div>--- Issues/PRs:</div><div><br></div><div>OpenID4VP Issues/PRs:</div><div><br></div><div>Implement signature verification requirements - <a href="https://github.com/openid/OpenID4VP/pull/598">https://github.com/openid/OpenID4VP/pull/598</a> & Add encryption details parameter - <a href="https://github.com/openid/OpenID4VP/pull/597">https://github.com/openid/OpenID4VP/pull/597</a> :</div><div>Kristina states that both need reviews and asks to also look at the Privacy Considerations Discussion/PR (<a href="https://github.com/openid/OpenID4VP/pull/509">https://github.com/openid/OpenID4VP/pull/509</a>) please.</div><div><br></div><div>Brian asks about the ongoing discussion about ECDH-MAC (<a href="https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/574">https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/574</a>) and changes that might be required to OpenID4VP. Christian mentions that this sounds like a topic to add in 1.1 in a non-breaking manner. Brian creates an issue on the topic.</div><div><br></div><div>OpenID4VCI Issues/PRs:</div><div><br></div><div>decouple credential metadata - <a href="https://github.com/openid/OpenID4VCI/pull/500">https://github.com/openid/OpenID4VCI/pull/500</a>:</div><div><br></div><div>Moved the display specific parts into their own parameter and add clarification that these can be overwritten by credential-format specific mechanisms. No objection to the proposal and Christian will adjust all examples so people can see what that looks like.</div><div><br></div><div>Add DPoP Nonce to Nonce Endpoint - <a href="https://github.com/openid/OpenID4VCI/pull/478">https://github.com/openid/OpenID4VCI/pull/478</a>:</div><div>4 Approvals, Good to go</div><div><br></div><div>Remove the Dynamic Credential Request section and associated content - <a href="https://github.com/openid/OpenID4VCI/pull/487">https://github.com/openid/OpenID4VCI/pull/487</a>:</div><div><br></div><div>Removal of current dynamic credential request before doing the PR on the new mechanism. Kristina asks if removing the parameters `wallet_issuer` and `user_hint` is fine for everyone and no-one objects.</div><div><br></div><div>Partial response encryption - <a href="https://github.com/openid/OpenID4VCI/issues/502">https://github.com/openid/OpenID4VCI/issues/502</a>:</div><div><br></div><div>Martijn explains that there are special encryption requirements for some forms of VCI interactions, where some components involved in VCI interactions would need parts of the payload and that can only be done if we don't fully encrypt the response. Christian asks if there are sets of use-cases how to define which parts are encrypted by which entity or not encrypted. Otherwise we would need a fully dynamic discovery mechanism introducing a lot of complexity. Lee agrees that seems like a very complex thing if you need to dynamically discover which parts are encrypted or to encrypt.</div><div>Lee asks if it wouldn't be easier to encrypt the whole thing to an entity (i.e., the wallet) and that entity figures those things out and shares the information as necessary. Brian states that from an interoperability point of view, trying to propose a solution for all different kinds of architectures introduces a lot of complexity and we need to be careful.</div><div><br></div><div>Martijn mentions that partial encryption, or generally support for such mixed architectures are important and should be supported. Hicham states that the topic falls more into the category of not prohibiting specific implementations instead of architecture discussions. Hicham continues that by encrypting everything, you would need to decrypt at a layer that might not be the most secure one. Christian proposes a solution with several encryption keys and a list of parameters for each. Kristina asks about which parts should be unencrypted in the Credential Response. Lee agrees that there might be 2 keys, one of them used for the credentials and one for metadata. Kristina asks if we are only talking about Credential Response and if we are only talking about the separation of the credential and additional metadata. Hicham will clarify but thinks it is mainly about response and metadata/credential split.</div><div><br></div><div>Rationale for limiting claims description path for mdoc to only namespace and element? - <a href="https://github.com/openid/OpenID4VCI/issues/468">https://github.com/openid/OpenID4VCI/issues/468</a>:</div><div><br></div><div>David states the he doesn't like the idea, but understands the motivation. Timo explains that the question is how to find a specific element in CBOR needs to be fully specified. David responds that the idea of finding the claims and describing them as part of provisioning feels wrong to him. Christian responds that the metadata decoupling would allow for the format-specific display information. David asks when you would use the VCI metadata functionality if you have the machine-readable credential format specific one. Timo clarifies that this seems the best approach right now while we have nothing better. David responds that most wallets would take those strings not from the issuer, but from their own information source since it might create bad UX.</div><div><br></div><div>Kristina asks what the action items are or if we agree to keep this as is. Peter asks about the mechanism and that it seems like an additional attack surface to him and how we wallet is supposed to trust that information. Christian answers that this is issuer-provided information and there are some trust assumptions towards the issuer in the current model. David agrees that he doesn't think it is that much of a security issue, but fears that it might be a slippery slope and should be part of a mechanism of the wallet itself and not dynamically fetched. David states that he hopes we will not have too many different document types. Lee states that he thinks we will have a lot of credential types that are unknown during to wallets and that the spec should cover those kinds of cases.</div><div><br></div><div>There seems to be some consensus that this feature is useful and Kristina asks for a volunteer to create a PR. Oliver volunteers for the PR and Peter will take a critical look at it.</div><div><br></div><div><br></div><div>Kristina implores people who are assigned issues in VCI to make sure PRs are filed to not further delay the planned timelines.</div></body></html>