[Openid-specs-digital-credentials-protocols] [notes] 1st August 2024 DCP WG call

[Joseph Heenan]

Participants:

Joseph Heenan
Kristina Yasuda
Daniel Fett
Andreea Prian
David Chadwick
Hicham Lozi
Jan Vereecken
Javier Ruiz
Juba Saadi
Lilli Walter
Lukasz Jaromin
Martijn Haring
Micha Kraus
Michael Jones
Paul Bastian
Pedro Felix
Sander Dijkhuis
Sebastian Bickerle
Sebastien Bahloul
Steve Venema


PRs needed reviews please

New query language https://github.com/openid/OpenID4VP/pull/220 : 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.

Removal of CWT proof type ( https://github.com/openid/OpenID4VCI/pull/369 ) will be merged soon unless there are any objections


Hierarchical deterministic keys

Sander Dijkhuis presented his slides, https://docs.google.com/presentation/d/1PZ93mXs5I7xhYR1RQyALJbe99ElfNuisRPmMAN1gbCg

Relevant issue in VCI: https://github.com/openid/OpenID4VCI/issues/359

This work has come from discussions across multiple European Union Large Scale Pilot

There’s a detailed PDF downloadable from their GitHub repo.

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).

Managing/storing the number of keys needed for the first approach is not easy.

There’s multiple solutions out there for key derivation (BIP32 / ARKG / KBSS), blinded proof of possession is also needed.

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).
 

Questions/answers:

Michael Jones: Have you been talking with John Bradley and co who have been prototyping something in this area in Sweden?

A: John/Micha are part of the working group & they’re working with author of ARKG.

Michael Jones: You asked about where to standardise it, I suggest the CRFG

Joseph: How well known is this crypto?

A: Similar techniques to BIP32 which is widely used in bitcoin. There are a couple of academic publications about ARKG.

Joseph: Can this be done on iOS SecureEnclave / Android Strongbox?

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.


Using HDK with OpenID4VC

Paul Bastian presented on what changes could be done to the OID4VC protocols to enable this.

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)..


Questions:

David Chadwick: Does this prevent Issuer and verifier collation? Is anyone looking at that?

Sander: No, not yet. Both other people are looking at this (e.g. BBS+).

Kristina: Google’s has a ZKP that could solve this

Joseph: Google are planning to present this at the next meeting of https://github.com/WICG/digital-credentials 

[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]


See https://github.com/openid/OpenID4VCI/issues/359#issuecomment-2263501850 for some extra details on the above Q&As.

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240801/37870491/attachment.html>