Profiling JOSE-HPKE for HAIP 1.1

[jogu]

https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ is a generic spec with many options, for interoperability reasons (and as we did for ECDH-ES) we need to pick which options are used.

As was done in openid/OpenID4VP#676 picking the same parameters as used in ISO 18013-7 Annex C (mdl presentation over DC API without using OID4VP) likely makes sense, and the same questions that arose there about what to use in the 'info' parameter need to be considered.

Who HPKE is mandatory for is being discussed in #356.

[jogu]

First stab at a profile:

1. alg MUST be HPKE-0 (meaning: Integrated encryption, DHKEM(P-256, HKDF-SHA256), HKDF-SHA256,AES-128-GCM)
2. psk_id MUST NOT be present
3. HPKE info parameter is set to either a CBOR value or string concatenation as suggested by Gareth here: 'pure' HPKE container approach using new response_mode OpenID4VP#676 (comment)

[selfissued]

These choices make sense to me.

[jogu]

Discussed on today's WG call:

alg MUST be HPKE-0 (meaning: Integrated encryption, DHKEM(P-256, HKDF-SHA256), HKDF-SHA256,AES-128-GCM)

Concern about whether AES-256-GCM should be allowed, as happened for ECDH-ES - see #329 for previous discussion.

Please comment if you have a preference for 256.

[bc-pi]

HPKE info parameter is set to either a CBOR value or string concatenation as suggested by Gareth here: openid/OpenID4VP#676 (comment)

String concatenation or byte array concatenation is totally sufficient and simple and doesn't bring a CBOR dependency for a single item.

[jogu]

Info parameter also discussed on today's WG call - consensus to go with string proposal due to it being simple to implement and that no one is required to parse:

// For redirects:
hash ( concat ( clientId, nonce, base64UrlEndcode(jwkThumprint), responseUri))

// For DC API
hash (concat (origin, nonce, base64UrlEndcode(jwkThumprint)))

Question: Do we need a parameter to indicate what is being used in the info parameter? Or does the definition of the info parameter need to go into VP 1.1?

Consensus on call: Define contents of info in VP 1.1 so we don't need a new parameter. Technically a breaking change from 1.0 perhaps but felt okay to people on the call.

Question: We should check if we do need the thumbprint or if HPKE essentially already checks that?

Okay to proceed with PR in VP. HAIP PR needs further discussion on the other issue.