Response Encryption : Why HPKE without JSON envelope

[hlozi]

The encryption for The Digital Credential Response should be specified in detail to ensure interoperability. Since the API is one-shot and doesn’t allow for negotiation, there should be a single encryption method. Negotiation would lead to privacy leaks.

Why HPKE ?

• HPKE is format-agnostic, unlike JARM, which is JWT-specific. This means that when used in transmission modes where JWT isn’t appropriate, a different encryption mechanism is needed.
• JARM requires the transmission of all authenticated information, including APU, and AVP headers. However, there are security benefits in not sending all information and providing it on both sides.
• The JSON envelope adds complexity that provides little value when HPKE is used.
• HPKE as a mechanism has support on native platform libraries.
• In constrained environments like UICC, SE, etc., dealing with JSON structures can be very challenging.

[jogu]

I think there's 3 separate points that are probably being mixed together here:

1. For the interoperability profiles we need to select a single encryption method (which is a pretty uncontentious statement and something OID4VP does expect people to do, e.g. ISO 18013-7 picked ECDH-ES I think)
2. The suggestion that HPKE should be that single encryption method (which is possible already without any breaking changes to OID4VP / will be possible when https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ is further along in the IETF process. The suggestion to (optionally?) omit APU/AVP headers is I presume something that could be suggested to the authors of this draft if it currently requires them.)
3. The suggestion to not use JARM, which would require a breaking change to OID4VP itself, rather than simply profiling it.

[paulbastian]

As discussed on DCP Call, currently the JARM encrypts the vp_token, which is a JSON structure. A possible (breaking) optimization could be to only encrypt individual Credentials, that could enable passing the encrypted credential to a SecureElement without it doing any JSON parsing.

[c2bo]

As discussed on the WG call today, I'd propose to initially add a small note in the JARM section that clarifies the different options from JOSE and explicitly points to HPKE as one such option.

Switching from the current variant to encryption on the level of individual credentials is something that needs a bit more discussion and also has some dependencies on features currently getting discussed like wallet attestation as part of the authorization response (and where exactly it resides).

[paulbastian]

To illustrate, currently we do:

Auth Response -> JARM JWE -> vp_token -> credential
                                      -> credential

The suggestion is to:

Auth Response -> vp_token -> JARM JWE -> credential
                          -> JARM JWE -> credential

[Sakurann]

First draft from @GarethCOliver on how the HPKE + JWE encryption might look like:

---

AuthorizationResponses that contain an ISO mDoc MUST be encrypted using HPKE (RFC 9180) using:

• Mode: Base
• KEM: DHKEM_P256
• KDF: HKDF_SHA256
• AEAD: AES_128_GCM

To enable this, AuthorizationRequests that include a credential of format mso_mdoc MUST include client_metadata

• Authorization_encrypted_response_alg with the value HPKE-P256-SHA256-A128GCM
• Authorization_encrypted_response_enc with a base64url encoded encapsulated key as defined in (either RFC 9180 or IETF ietf-jose-hpke-encrypt)

---

@bc-pi said the last bullet point does not really make sense.

[Sakurann]

WG call: @ve7jtb said let's not do this because this will create incompatibility and complexity. there was an agreement from others.

[Sakurann]

as discussed here, agreed to do this post final 1.0, changing the milestone to 1.1