<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Date: 25<sup>th</sup> January 2024<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Attendees (incomplete, this is only the people that were speaking in zoom/active in chat – sorry about that):<o:p></o:p></p><p class=MsoNormal>Kristina Yasuda<o:p></o:p></p><p class=MsoNormal>Torsten Lodderstedt<o:p></o:p></p><p class=MsoNormal>Daniel Fett<o:p></o:p></p><p class=MsoNormal>Gabe Cohen<o:p></o:p></p><p class=MsoNormal>Jacob Ward<o:p></o:p></p><p class=MsoNormal>Paul Bastian<o:p></o:p></p><p class=MsoNormal>Oliver Terbu<o:p></o:p></p><p class=MsoNormal>Michael Jones<o:p></o:p></p><p class=MsoNormal>George Fletcher<o:p></o:p></p><p class=MsoNormal>Lukasz Jaromin<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>--- General<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Kristina mentions IIW coming up in April(16th to 18th). At the last IIW, there was a DCP working group on monday before, but this time it conflicts with an open wallet foundation event in Seattle. The proposal would be to have a roughly 3 hour working group meeting on Friday (the day after IIW). Please reach out if there are conflicts with the friday idea for a working group meeting. Mike adds that we then also need a place for the meeting and Kristina answers she will start looking.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>--- Issues and PRs (VCI):<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>https://github.com/openid/OpenID4VCI/pull/220 - rename credential_configurations to credential_configuration_ids:<o:p></o:p></p><p class=MsoNormal>Kristina explains that feedback came in that credential_configurations points to credential_configuration metadata and credential_configuration_id points to the same metadata. credential_configuration_ids would be cleaner / close than credential_configurations. Kristina mentions that there are five approvals, so it seems like people agree that credential_configuration_ids is a cleaner approach.<o:p></o:p></p><p class=MsoNormal>Christian asks why some of the examples have no reference in the spec and after some discussions decisions is made to create a list for examples that are not referenced in the spec and decide from there.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>https://github.com/openid/OpenID4VCI/pull/219 - added format to authorization details and respective format specific additional claims:<o:p></o:p></p><p class=MsoNormal>Kristina explains that we only have 2 approvals, would be nice to have a few more. Kristina mentions the problem with conditional claims and the formulation according to IETF. George adds that someone reading this without the history of the spec makes it confusing. Torsten explains the problem that the claims are mutually exclusive which ist not covered by IETF wording. George says he would prefer the more complex REQUIRED formulation. Lukasz adds that he would be confused with the longer REQUIRED formulation. <o:p></o:p></p><p class=MsoNormal>Kristina creates 3 options and asks for feedback and Lukasz expresses that he prefers option 1. Overall agreement with the last presented option to directly express REQUIRED when <..>.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>https://github.com/openid/OpenID4VCI/pull/232 - Fix layout in "VC Secured using Data Integrity" issuer metadata:<o:p></o:p></p><p class=MsoNormal>Short discussion about what indentation is correct here and merged.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>https://github.com/openid/OpenID4VCI/pull/187 - Wrote initial Privacy Considerations:<o:p></o:p></p><p class=MsoNormal>Kristina asks for everyone to take a bit of time right now and read if possible as it was changed very recently. Paul expresses that the section on selective disclosure seems to be pretty specific and there are other credential types like zkp based ones that give that choice completely to the holder. Torsten adds that he would like to keep it simple in openid4vci and mike agrees. Kristina proposes to create a more generic statement and Mike agrees that he can do that. Jacob asks who this segment is intended for and Mike explains mainly issuer and wallet - the parties implementing the spec. Daniel and Gabe volunteered to review the PR. Kristina explains that in general she would like to have cleaner segments.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>https://github.com/openid/OpenID4VCI/issues/37 - Missing link between cryptographic_suites_supported and format of credential:<o:p></o:p></p><p class=MsoNormal>Kristina explains that there are 2 issues, 37 and 217 on the cryptographic_suites_supported parameter and it is currently unclear what it applies to. Kristina explains that Timo is suggesting to rework the definition of cryptographic_suites_supported to refer only to the cryptosuites. Torsten asks if this means we have no metadata what kind of signatures and algorithms are supported by the issuer? Kristina says that there seem to be 3 options: Option 1 cryptosuites_supported is for both, Option 2 where crypto suites only apply to the proof which, Option 3 where the structure of proof_types is changed from array to map and clarify that crypto_suites_supported.<o:p></o:p></p><p class=MsoNormal>Paul adds that issue #214 is a similar issue and he agrees to go with the map route (option 3). Jacob asks if crypto suites in that map would then only apply to proofs or the credential signature as well. Kristina answers that within the map it would only apply to the proof type and we would crypto_suites_supported and clarify that that one would apply to credential signatures.<o:p></o:p></p><p class=MsoNormal>Torsten asks if we need meta data to signal how the credential will be signed. Kristina adds that some wallets verify the credentials they receive from the issuer. Torsten explains that for the time being he prefers to keep the metadata about credential signature and if we figure out we don't need it later on it can still be removed.<o:p></o:p></p><p class=MsoNormal>Paul asks about holder binding and how that is also related. Kristina explains that she believes there is some kind of relationship between proof type and cryptographic_binding_supported as well. Paul adds that he thinks there needs to be a bit more thought about the issue and we have not yet enough information. Torsten agrees and Kristina will draft a PR with the changes for the map. Paul will create a separate issue for holder binding.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none'>Best Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none'>Christian Bormann<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>