<div dir="ltr"># OIDF DCP WG Meeting Notes for 2024-11-07<br><br>## Attendees<br><br>Bjorn Hjelm<br>Christian Bormann<br>David Chadwick<br>Gareth Oliver<br>Hicham Lozi<br>Joseph Heenan<br>Martjin Haring<br>Nemanja Patrnogic<br>Oliver Terbu<br>Paul Bastian<br>Pedro Felix<br>Rajvardhan Deshmukh<br>Steve Venema<br>Torsten Lodderstedt<br><br>## Agenda Items<br><br>### EU letter<br>- Letter present in the following mailing list message - <a href="https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20241028/000524.html">https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20241028/000524.html</a><br>- No full clarity regarding the OpenID4VP, OpenID4VCI, and HAIP deadlines.<br>    - OpenID4VP, OpenID4VCI - aiming for end of march.<br>    - HAIP - a bit later.<br>- Discussion about the importance of HAIP as a concrete profile to provide to implementors.<br>- Reference to interest from "CEN TC 224 WG 20".<br><br>### IIW recap<br>- See attached image.<br>- Discussion about adding mdoc to HAIP, including the full lifetime and not only presentation.<br>    - Different opinions. No final decision or conclusion.<br>    - Important to make sure there isn't overlap with ISO specifications, namely with ISO TS 18013-7.<br>- Discussion about HPKE.<br>    - Issue: <a href="https://github.com/openid/OpenID4VP/issues/310">https://github.com/openid/OpenID4VP/issues/310</a>.<br>    - Hicham considered important that the design doesn't require JSON processing on the secure element.<br>    - Christian commented that it is important to clarify exactly what is being encrypted.<br>    - Comments on the above issue are welcomed.<br><br>### Open public review period for OpenID4VP implementors draft<br>- Started last Friday (IINM).<br>- PRs with suggested changes to the implementors draft<br>    - <a href="https://github.com/openid/OpenID4VP/pull/314">https://github.com/openid/OpenID4VP/pull/314</a> - editorial, corrects non-normative example.<br>    - <a href="https://github.com/openid/OpenID4VP/pull/311">https://github.com/openid/OpenID4VP/pull/311</a> - editorial, corrects non-normative example.<br>    - <a href="https://github.com/openid/OpenID4VP/pull/303">https://github.com/openid/OpenID4VP/pull/303</a> - missing request parameters on the browser API.<br>- Reviews are welcomed on these PRs.<br><br>### VCI<br>- Key attestation - <a href="https://github.com/openid/OpenID4VCI/pull/389">https://github.com/openid/OpenID4VCI/pull/389</a><br>    - Paul stated that, based on feedback from external experts, it may be enough to have the "apr" property, and avoid the "key_storage_type" and "user_authentication". However it may not be easy for the wallet provider to assert concrete "apr" values.<br><br>- Wallet attestation - <a href="https://github.com/openid/OpenID4VCI/pull/408">https://github.com/openid/OpenID4VCI/pull/408</a><br>    - Discussion about wallet attestation requiring JSON-based structures on wallets that exclusively deal with non JSON-based credential formats.<br>    - Comment about the need to exactly define what is meant by attestation, namely what is exactly being attested. This may not be easy to do.<br><br>Regards,<br>Pedro <br></div>