Who HPKE is mandatory / optional for in HAIP 1.1

[jogu]

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 Profiling JOSE-HPKE for HAIP 1.1 #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.

[jogu]

Discussed on today's WG call:

If people want to use HPKE, why don't they define a new profile that allows HPKE but is otherwise the same as HAIP? We do not want a proliferation of profiles, and we've discouraged people from defining their own profiles historically. We want people to be able to pick standard software that's compliant with the profile and be able to use that out of the box.

Why do people want HPKE? The benefits are from implementing only HPKE, it's biggest advantage is it's easier to implement and it may be more secure (because of the 'info' parameter and because the underlying HPKE spec has been more formally evaluated), but that diminishes if you have to implement both HPKE and ECDH-ES.

Shouldn't we be discussing post quantum? (But Joseph believes that both Apple & Google public statements have so far indicated that HPKE is how they will support post quantum.)

Leaving it to ecosystems may cause issues for certification / formal compliance, and ecosystems is not clearly defined.

Alternative suggestions that were made during the call:

1. Have new top level options: Add new sections that are "VP + redirects + HPKE" and "VP + DC API + HPKE", but also "VP + redirects + HPKE or ECDH-ES" and "VP + DC API + HPKE or ECDH-ES".
2. Suggestion also use the text I'd proposed above adding HPKE as an optional feature, but without the bit of text leaving it to ecosystems.
3. Do HAIP 2.0 instead as a breaking that requires HPKE? (And perhaps do a HAIP 1.1 that makes HPKE an option as well.)

No conclusion on which is the best way forward yet.

[jogu]

Discussed on today's APAC call:

Consensus to add new sections that are "VP + redirects + HPKE" and "VP + DC API + HPKE", and people (ecosystems) would be able to pick to implement either the existing ECDH-ES section, or the HPKE, or both.

Agreed to move towards a PR so we have concrete text to review.

[Sakurann]

WG discussion:

• some ecosystems indicated that they want only HPKE. so an option to mandate verifiers to support both enc mechanisms and wallet chooses one does not fulfill that.
• adding separate profiles of OpenID4VP in HAIP 1.1 to do HPKE only without ECDH-ES seems to be less disliked option (even though it is ugly..) and maybe we can clean this up in HAIP 2.0

[Sakurann]

this will also supercede and resolve #199