Support for Hierarchical Deterministic Keys (HDK)

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?

Review the linked HDK and ARKG specifications, then compare their requirements with OpenID4VCI’s proof and credential response definitions. Clarify whether an hdk proof type, seed object, key_handles parameter, and proof-of-possession signaling are needed; done means the protocol changes are agreed and specified.