-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Hierarchical Deterministic Keys (HDK) #359
Comments
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.) |
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. |
Great, thanks. Just for clarity we'll also need to confirm we have the right people on our side available that day too. |
Thanks @paulbastian, this is indeed closely related and should be aligned. Note that with HDK:
|
@jogu should we still meet tomorrow? I could also do next week if it works better. |
Could we do this discussion after IETF, the week of July 29th? @paulbastian is on vacation next two weeks and I think it would be better to have him on the call. Also, is there any implementation experience on the approach being proposed in this issue? |
This sounds like John should be there as well imho - If I recall correctly we had some initial discussions in this/a similar direction at an IIW with him? |
I’ll join the Thu Aug 1 meeting at 17:00 CEST as discussed, hopefully together with some more HDK working group members such as @ve7jtb. For the briefing, I could present an extract of the HDK slide deck, highlighting the points in this issue’s opening post. The main objectives would be to:
|
To further detail some Q&A from today’s call:
|
Here are some sketches of how these mechanism could be applied to OpenID4VCI: Given that we only use local derivation, the flow would be:
Benefits:
This could work well with a new proof type and is easy to integrate today:
|
Given that we only use remote derivation, the flow would be:
Benefits:
This has some challenges for integration in OpenID4VCI, as we also have to change the Credential Response.
Credential Response proposal 1:
Credential Response proposal 2:
A third option to be analysed is also to derive new credentials from the public key of an existing, verified credential. |
Next steps:
Do you see this the same way or am I missing steps? |
how much is this addressed by #389 ? |
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:
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:
(pk_kem, pk_bl)
, wherepk_kem
is a KEM public key andpk_bl
is an asymmetric key blinding public key (the key to derive from).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:
hdk
proof type with an associated object containing elements:seed
: REQUIRED. An ARKG public seed represented as base64url-encoded COSE_Key structure.key_handles
containing base64url-encoded ARKG key handles in the same order as the associated entries in thecredential
orcredentials
parameter.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. Doesinvalid_proof
meet this use case?What do you think?
The text was updated successfully, but these errors were encountered: