openid / openid/OpenID4VC-HAIP

Who HPKE is mandatory / optional for in HAIP 1.1

Open
#356 4 comments 0 reactions 1 assignee View on GitHub

@Sakurann is already working on this.

Since Jan 15, 2026.

has-PR
Dominant language
Makefile
Stars
57
Forks
17
PR merge metrics
No merged PRs in 30d

Description

I think there are essentially two possible ways we could integrate HPKE into HAIP 1.1:

  1. As new sections that are "VP + redirects + HPKE" and "VP + DC API + HPKE".
  2. As options within the existing sections.

Option "1" seems hard to proceed for the redirect based flow; there would be no way for verifiers to know if HPKE was supported, and no way for them to make both HPKE & non-HPKE requests.

So option 2 seems like the way to proceed.

We cannot make breaking changes in HAIP 1.1, so we can't entirely remove ECDH-ES ( as issue #199 seemed to propose).

So I think the base position is:

  1. Wallets MAY support JOSE-HPKE [using a profile for JOSE-HPKE defined in HAIP, see issue #357 for discussion about how to profile it] for encrypting returned credentials. If a Wallet supports JOSE-HPKE and the Verifier request both ECDH-ES and HPKE, the Wallet SHOULD use HPKE. (I'm not strongly attached to 'SHOULD', 'MUST' might make sense too?)
  2. Verifiers MAY support JOSE-HPKE. (meaning that when they make a request, they need to supply include both ECDH-ES for backwards compatibility with 1.0 and also HPKE in the request)

This would mean everyone can add HPKE, and if both sites support HPKE then HPKE 'should' be used.

The additional problem is that some ecosystems want to support only HPKE. If we want to allow these ecosystems to be HAIP compatible, we would need carve outs to allow this - something like:

Ecosystems MAY mandate that only HPKE is supported. In such ecosystems, both Wallets and Verifiers MUST support HPKE and, if they need to interoperate with other ecosystems that may not require HPKE, MAY support ECDH-ES.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.