Support for Hierarchical Deterministic Keys (HDK)

[sander]

Hi OpenID4VCI authors! With a cross-pilot working group we’re specifying Hierarchical Deterministic Keys (HDKs) for the European Digital Identity Wallet. Let’s discuss how we could make HDK work with OpenID4VCI.

An HDK is a key deterministically derived from parent key material, and bound to a wallet secure cryptographic device (WSCD) using key blinding. A wallet instance could derive an HDK either locally, just using a static seed and path, or remotely, additionally using a key handle provided by another component. Remote key derivation is implemented using Asynchronous Remote Key Generation (ARKG). By construction, the wallet instance and optional remote party know that child keys are bound to the same WSCD (if any) as their parent key.

This design should offer several advantages to the ecosystem:

• Issuers can rely on WSCD binding without processing additional personal metadata, such as issuer trust evidence or proof of association.
• Wallet users only need to create a single proof of possession using the WSCD to enable issuers to regularly issue fresh batches of single-use credentials.
• Wallet solutions can efficiently deploy off-the-shelf WSCD solutions that support protecting a single ECDH or EC-SDSA key, and implement the rest in (mobile) wallet instance software.

Locally derived keys are opaque to issuers, so can be considered just an optimisation for wallet solution design. Remotely derived keys have some consequences for OpenID4VCI applications:

1. To request remote key derivation, the client provides an ARKG public seed (pk_kem, pk_bl), where pk_kem is a KEM public key and pk_bl is an asymmetric key blinding public key (the key to derive from).
2. To respond with remotely derived keys, the issuer associates with each credential an AKRG key handle, which is an opaque byte string. This key handle should not be part of the credential itself, to avoid sharing metadata with relying parties.
3. A single ARKG public seed may be used to issue many credentials, potentially in several batches. These credentials have the same configuration and dataset, but distinct cryptographic material derived using ARKG. The credentials do not need to be delivered in a particular order.
4. When ARKG is applied, the credential to be issued does not contain the same public key as the proof of possession, but a key derived from it.
5. When ARKG is applied, the proof of possession may be implicit. For example, the issuer may have authenticated the user with PID, and remotely derive public keys from the presented PID-bound public key.

As of d5ed198, it looks like OpenID4VCI does not yet fully support these features. As @paulbastian suggested in a recent HDK call, we could define a new proof type.

My first suggestion would be:

• Add an hdk proof type with an associated object containing elements:
  • seed: REQUIRED. An ARKG public seed represented as base64url-encoded COSE_Key structure.
• Add an optional Credential Response parameter array key_handles containing base64url-encoded ARKG key handles in the same order as the associated entries in the credential or credentials parameter.
• Specify how the issuer may indicate to the user that for a given hdk.seed, a proof of possession needs to be given of the key associated with the BL public key – and hence with the WSCD, if any. Does invalid_proof meet this use case?

What do you think?

[jogu]

Hi @sander

Thanks for working on this! I'm one of the co-chairs of the DCP WG group (the other chairs being Kristina & Torsten).

We don't seem to obviously have a contribution agreement from you or your company - unless you already completed one in the last few days, can you please complete one via the docusign process on https://openid.net/intellectual-property/openid-foundation-contribution-agreements/ ? This is a necessary step for anyone that wants to contribute to an OpenID Foundation specification, so it may be something you want to mention to other members of your working group that might get involved in adding this to the VCI spec.

In principle your proposal seems to make sense (although I am not qualified to comment on any of the cryptographic details).

I suspect a sensible next step might be to try and arrange for some members of your working group to join a DCP WG call and give the working group members a briefing on your specification. The WG call schedule is on https://openid.net/wg/digital-credentials-protocols/ - we have two different time slots (one is "EU friendly", one APAC-ish friendly), we may need to do this in both time slots (or perhaps do it in one and record it). Probably the earliest we could think about doing this is 11th July, and we should avoid week of 22nd July as IETF is that week.)

[sander]

Thanks @jogu! I’ve just signed the contribution agreement. The 11th July EU Call should work for me, I’ll also check with other working group members.

[jogu]

Great, thanks. Just for clarity we'll also need to confirm we have the right people on our side available that day too.

[paulbastian]

Hi @sander , I already opened an Issue for this discussion a week ago here: https://github.com/openid/OpenID4VCI/issues/355 which is kind of adjacent

[sander]

Thanks @paulbastian, this is indeed closely related and should be aligned. Note that with HDK:

• the Wallet Provider would not attest the optional device_keys, but just the cnf key to ensure the Wallet Provider does not learn the derived public keys as correlation handles;
• the Wallet Instance extends the cnf key into an ARKG public seed, without involvement of the Wallet Provider, so this will not be part of the WTE/ITE;
• (Q)EAA Providers typically do not need ITE if they have already verified some PID and trust that its PID Provider has authenticated the WSCD (which PID Providers may be legally required to do?), reducing:
  • reliance on Wallet Provider availability;
  • risk of tracking users between Wallet Providers and (Q)EAA Providers.