HDK spec v1

[sander]

Work is ongoing in keys.md. It needs significant editorial work:

• a proper introduction, based on context.md
• iterations based on peer reviews
• possible simplification: Limit scope to wallet key management #12

Questions for the 2024-06-03 meeting:

1. What do initial reviewers think?
2. Who is interested in contributing? Who wants to review as well?

[sander]

Discussed 2024-06-03.

@emlun, @ve7jtb (after this week), Juan, Sarah will review.

Specific issues to address in the review, next to general feedback:

• Is this indeed an application of ARKG, or do ARKG and HDK apply the same primitives that we should extract?
• OpenID4VCI extension: how to request batch issuance with different contents?
• Can we reduce the amount of OpenID4VCI endpoints?
• Do we need to support related keys with different security properties? E.g. require PoP with user verification upon presentation, but PoP without user verification upon repeated issuance using a refresh token in OpenID4VCI.
• What is the relation with Wallet Instance Attestations? Do HDK replace a need for these?
• What is the relation with Wallet Trust Evidence?
• How should wallet revocation work with HDK?
• Should Efficient mass issuance #1 be in scope of HDK?

[sander]

Discussed 2024-06-10. Reviews still pending.

[sander-cb]

2024-06-17 meeting:

Remco:

• security/privacy objectives?
• Add: issuer does not get additional power to leverage presentation to issue presentation on its own, given presentations of other issuers’ attestations (cross-issuer faking of presentations). John: ARKG references may contain a good term.
• “optionally evidence of security of the blinded private key” – possibly mandatory for EUDI Wallet. Also: how to make it work with existing hardware in practice. Consider if Wallet Provider should be able to issue the WTE, given the root public key – then should be a conscious and known choice.
• WSCD should meet EAL4+ for LoA High – make explicit how. Paul: how would backup & recovery look (issuers 24/7 online?) – at least for the blinding keys, for the device key could be contentious.
• Wallet generates seed – how well do these bytes need to be protected; security, privacy implications.
• “The Credential Issuer SHOULD verify a proof of possession of the provided ARKG key blinding public key.” – when would be a good excuse to not do it? John: possibly when WTE already provides sufficient assurance.

[Sakurann]

Could someone elaborate on the rationale and ask in the item Can we reduce the amount of OpenID4VCI endpoints?

[sander]

@Sakurann:

Could someone elaborate on the rationale and ask in the item Can we reduce the amount of OpenID4VCI endpoints?

This came up during a review of keys.md § Applying HDK in OpenID for Verifiable Credential Issuance. My proposal was to add a “Multiple Batch Endpoint” to support HDK. Participants told we already have many endpoints, and should look instead if we can reuse and extend any of the existing ones instead.

You’ve mentioned during last week’s ETSI ESI#83 that the OpenID4VCI working group will soon publish a new draft with “Optimizing Issuance of Credential Batches”, and is discussing “Optimizing number of endpoints”. Is there work in progress we can follow?

[sander]

2024-07-01: Micha: big merge done or in progress, simplifying batch endpoints. openid/OpenID4VCI#293

During the 2024-07-01 meeting, we’ve walked through the current simplified spec structure.

[sander]

2024-07-08

• Micha: make explicit how verifier uses the HDK-Authenticate output, e.g. in the ECDH case (currently implicit)
• Antoine: mention it can be used purely locally

[sander]

Closing with the 0.1.0 release. Specific comments now have dedicated issues.