
<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 style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>Participants:</div><div><br></div><div>Joseph Heenan</div><div>Kristina Yasuda</div><div>Daniel Fett</div><div>Andreea Prian</div><div>David Chadwick</div><div>Hicham Lozi</div><div>Jan Vereecken</div><div>Javier Ruiz</div><div>Juba Saadi</div><div>Lilli Walter</div><div>Lukasz Jaromin</div><div>Martijn Haring</div><div>Micha Kraus</div><div>Michael Jones</div><div>Paul Bastian</div><div>Pedro Felix</div><div>Sander Dijkhuis</div><div>Sebastian Bickerle</div><div>Sebastien Bahloul</div><div>Steve Venema</div><div><br></div><div><br></div><div><b><u>PRs needed reviews please</u></b></div><div><br></div><div>New query language <a href="https://github.com/openid/OpenID4VP/pull/220">https://github.com/openid/OpenID4VP/pull/220</a> : please review; we want to aim to merge the initial version within a few weeks so that we can start building upon it, any substantial unresolved discussions likely to be moved to dedicated issues to allow it to be merged.</div><div><br></div><div>Removal of CWT proof type ( <a href="https://github.com/openid/OpenID4VCI/pull/369">https://github.com/openid/OpenID4VCI/pull/369</a> ) will be merged soon unless there are any objections</div><div><br></div><div><br></div><div><u><b>Hierarchical deterministic keys</b></u></div><div><br></div><div>Sander Dijkhuis presented his slides, https://docs.google.com/presentation/d/1PZ93mXs5I7xhYR1RQyALJbe99ElfNuisRPmMAN1gbCg</div><div><br></div><div>Relevant issue in VCI: <a href="https://github.com/openid/OpenID4VCI/issues/359">https://github.com/openid/OpenID4VCI/issues/359</a></div><div></div><div><br></div><div>This work has come from discussions across multiple European Union Large Scale Pilot</div><div><br></div><div>There’s a detailed PDF downloadable from their GitHub repo.</div><div><br></div><div>The wallet needs to be able to prove that the credential was issued to it; called ‘device binding’ in the EU ARF. But these ‘proof of possession' keys introduce a linkability issue, currently avoided by using multiple keys and batch issuance, or a multi-message signature scheme (e.g. BBS).</div><div><br></div><div>Managing/storing the number of keys needed for the first approach is not easy.</div><div><br></div><div>There’s multiple solutions out there for key derivation (BIP32 / ARKG / KBSS), blinded proof of possession is also needed.</div><div><br></div><div>Some changes to OID4VCI would be needed to enable remote HDK derivation so that a public seed can be provided to issuer & key handles returned (see above GitHub issue).</div><div> </div><div><br></div><div>Questions/answers:</div><div><br></div><div>Michael Jones: Have you been talking with John Bradley and co who have been prototyping something in this area in Sweden?</div><div><br></div><div>A: John/Micha are part of the working group & they’re working with author of ARKG.</div><div><br></div><div>Michael Jones: You asked about where to standardise it, I suggest the CRFG</div><div><br></div><div>Joseph: How well known is this crypto?</div><div><br></div><div>A: Similar techniques to BIP32 which is widely used in bitcoin. There are a couple of academic publications about ARKG.</div><div><br></div><div>Joseph: Can this be done on iOS SecureEnclave / Android Strongbox?</div><div><br></div><div>A: The blinding has been designed to be usable on these, but there are some security questions they’re reaching out to more groups to talk about this. There are new mechanisms. More evaluation is needed.</div><div><br></div><div><br></div><div><b><u>Using HDK with OpenID4VC</u></b></div><div><br></div><div>Paul Bastian presented on what changes could be done to the OID4VC protocols to enable this.</div><div><br></div><div>Key derivation can be local or remote. Both options can make batch issuance and reissuance simpler and avoid the need for user approval at the wallet HSM during re-issuance (i.e. the issuer can generate or verify the keys based on the trust in the root key from the first issuance)..</div><div><br></div><div><br></div><div>Questions:</div><div><br></div><div>David Chadwick: Does this prevent Issuer and verifier collation? Is anyone looking at that?</div><div><br></div><div>Sander: No, not yet. Both other people are looking at this (e.g. BBS+).</div><div><br></div><div>Kristina: Google’s has a ZKP that could solve this</div><div><br></div><div>Joseph: Google are planning to present this at the next meeting of <a href="https://github.com/WICG/digital-credentials">https://github.com/WICG/digital-credentials</a> </div><div><br></div><div>[Info confirmed after the call: people who are not members of WICG are welcome to attend to observe the google ZKP presentation, it will be the 2024-08-07 ‘B’ call which is at 11PM London / 6pm Eastern - meeting invite is downloadable from above GitHub link]</div><div><br></div><div><br></div><div>See <a href="https://github.com/openid/OpenID4VCI/issues/359#issuecomment-2263501850">https://github.com/openid/OpenID4VCI/issues/359#issuecomment-2263501850</a> for some extra details on the above Q&As.</div><div><br></div><div>A recording of the above two presentations is available to working group members - please contact one of the chairs/editors if you would like to watch it.</div><div><br></div><div><br></div><div><br></div></div></body></html>