openid
'pure' HPKE container approach using new response_mode
per wg discussion this is a proposal for how to do HPKE directly.
The approach to allow hpke is to specify a new response_mode by appending .hpke instead of .jwt. This text picks an explicitly series of parameters instead of negotiating them, for simplicity and to align with the other HPKE usage in the ecosystem (Annex C). Encryption is only between the Wallet and the Verifier, and must be credential agnostic so making strong choices seems reasonable (unlike signatures where all parties are involved).
Proposed Text
8.3.1 JWE // Current Encrypted Responses Text
…
8.3.2 HPKE
This section defines how an Authorization Response containing a VP Token (such as when the Response Type value is vp_token or vp_token id_token) can be encrypted at the application level using [HPKE]. The HpkeEncryptedResponse is a JSON Object with the following parameters:
- “enc”: a Base64UrlEncoded string of the bytes of the ‘enc’ output from HPKE
- “cipherText”: A Base64UrlEncoded string of the encrypted, serialized Authorization Response.
The cipherText encryption MUST be performed using the HPKE one-shot API as defined in RFC 9180. The following parameters are used:
- Mode = BASE
- KEM = DHKEM_P256
- KDF = HKDF_SHA256
- AEAD = AES_128_GCM
The Wallet MUST use the following parameters for HPKE Single shot encryption:
- pKR: the Verifier’s public key as received in the jwks
- info: (Two options: cbor-encoded SessionTranscript as specified for mdocs OR hash of concat of strings of same fields)
- pt: JSON-serialized Authorization Response
- aad: empty
The resulting enc and ct are then Base64UrlEncoded and used as the “enc” and “cipherText” parameters in the HpkeEncryptedResponse object.
The Verifier MUST use the following parameters for HPKE Single shot decryption:
- enc: The decoded “enc” parameter in HpkeEncryptedResponse
- ct: The decoded “cipherText” parameter in HpkeEncryptedResponse
- sKR: The private key associated with the Verifier-provided jwks
- info: (SessionTranscript Or hash(concat))
- aad: empty
Text can continue with examples of how to then return this in the body of a direct_post or dc_api response
Notes:
If we wanted to extend to allow agility in choice of algorithms we could do the following:
- Add kid, kdf and aead to the HpkeEncryptedResponse
- Allow multiple jwks, and repeated pairs of supported_algs (kdf, aead).
If we wanted a bit of extra certainty of the .hpke description we could also add a versioning string to the HpkeEncryptedResponse.
The verifier can provide the option of either over DC api by making multiple requests with different response_modes (albeit inefficiently).
Open Questions:
- cbor SessionTranscript vs a Strin concat of equivalent values.
- Do we really need algorithm agility?
- Do we need an encryption identifier in the response?
- should be known from the request, though having it might help with debugging
- Do we need to perform checks on the alg and use of the key vs what is expected by the protocol on the Wallet side?
I'm in favor as it protects non-mdoc presentations against MitM because the encryption key is in the info, as mdoc today does with SessionTranscript, which we don't have today with JWE.
WG discussion:
- there was a rough consensus on the direction of what is documented in this issue during IIW session
- @bc-pi expressed concerns that a new response_mode.hpke might be problematic that verifier needs to specify how it wants encryption to work
- two (related) issues: a) how to communicate the usage of HPKE; b) how to actually do HPKE
- Options to move forward:
-
- wait for ietf jose-hpke (very low confidence it will materialize)
-
- effectively define jwe with hpke in dcp wg
-
- define vanilla hpke wrapper. what is in this draft - feedback still very welcome
- if we go this way, how much do we need to account for ietf jose-hpke?
-
Please continue the discussion in this issue.
cbor SessionTranscript vs a Strin concat of equivalent values.
just use string concatenation (if even needed) no need to bring cbor into a JSON and HTTP protocol suite
Do we really need algorithm agility?
During WG discussion on 10/24 @GarethCOliver said something to the effect of a (maybe) goal being to minimize the amount of technical debt introduced. Which seems to me like a laudable goal given all the factors here.
That would suggest that we do not really need algorithm agility.
But does mean that the chosen algorithm suite needs to accommodate the stakeholders who are unable to proceed without HPKE. And my reading of https://mailarchive.ietf.org/arch/msg/jose/EVOyeH9SC68is87cQZfIfb7W6BA/ is that DHKEM_P256/HKDF_SHA256/AES_128_GCM will not.
wait for ietf jose-hpke (very low confidence it will materialize)
I share that low confidence and am deeply disappointed that the totality of the situation has come to this.
define vanilla hpke wrapper. what is in this draft - feedback still very welcome if we go this way, how much do we need to account for ietf jose-hpke?
Given the presumptive requirements around HPKE's info, some accounting for it's similar use in ietf jose-hpke might be worthwhile.
@bc-pi expressed concerns that a new response_mode.hpke might be problematic that verifier needs to specify how it wants encryption to work
That concern is that a verifier can only chose one style of response encryption encoding per request. Which is very limiting in terms of algorithm agility and coexistence and interoperability at scale and over time. I think @GarethCOliver did kinda touch on this in the notes with:
The verifier can provide the option of either over DC api by making multiple requests with different response_modes (albeit inefficiently).
But I don't think that fully captures how limiting it is.
Do we really need algorithm agility?
During WG discussion on 10/24 @GarethCOliver said something to the effect of a (maybe) goal being to minimize the amount of technical debt introduced. Which seems to me like a laudable goal given all the factors here.
That would suggest that we do not really need algorithm agility.
But does mean that the chosen algorithm suite needs to accommodate the stakeholders who are unable to proceed without HPKE. And my reading of https://mailarchive.ietf.org/arch/msg/jose/EVOyeH9SC68is87cQZfIfb7W6BA/ is that DHKEM_P256/HKDF_SHA256/AES_128_GCM will not.
I guess it depends on your stakeholders. This matches the parameters fixed by Annex C, which is the other major approach for presentations of credentials. This will also minimize the burden of RPs who are supporting both approaches, or transitioning.
define vanilla hpke wrapper. what is in this draft - feedback still very welcome if we go this way, how much do we need to account for ietf jose-hpke?
Given the presumptive requirements around HPKE's info, some accounting for it's similar use in ietf jose-hpke might be worthwhile.
Could you provide more details of what you expect here? I'm definitely not as familiar about jose-hpke and would appreciate the thoughts.
@bc-pi expressed concerns that a new response_mode.hpke might be problematic that verifier needs to specify how it wants encryption to work
That concern is that a verifier can only chose one style of response encryption encoding per request. Which is very limiting in terms of algorithm agility and coexistence and interoperability at scale and over time. I think @GarethCOliver did kinda touch on this in the notes with:
The verifier can provide the option of either over DC api by making multiple requests with different response_modes (albeit inefficiently).
But I don't think that fully captures how limiting it is.
To fully capture it I'd say:
Wallets can provide inter-op across ecosystems by supporting both Verifiers who wish to support both will generally have a bad time as they must either
- in DC API duplicate both requests with different response_modes
- for redirects, know in advance what the Wallet supports (which is challenging)
This also minds that migrating an ecosystem from one choice to the other will be challenging, and will result in journeys that are broken that could have worked. To limit this we'd need to mandate support for wallets to support both and Verifiers to choose in HAIP.
For completeness a sketch of the 'middleground' solution is:
- response_mode remains *.jwt
- in client_metadata add enc_wrapper_formats_supported = OPTIONAL array of string values indicating the wrapper to use (with HPKE, and JWT as the options). The Wallet may choose any of the options provided. If absent then it MUST use JWT.
Then, in the response we will need to include the selected wrapper_format. To this in a backwards compatible way we might need to be creative (adding it parallel to the response parameter as a new parameter). The alternative would be to make response a container format.
This would allow for agility, with the cost of some increased complexity.
cbor SessionTranscript vs a Strin concat of equivalent values.
just use string concatenation (if even needed) no need to bring cbor into a JSON and HTTP protocol suite
Agree with the pros on string concatenation
The cons are primarily that
- we'll have two definitions of very similar things (the cbor session transcript and the string session transcript)
- For mdocs, you'd have to construct both of these different things (increasing complexity)
So the trade-off is between being able to avoid cbor libraries for sd-jwt only wallets/verifiers in exchange for increased complexity for mdocs.
If we defined the concat I think it'd be:
// For redirects: hash ( concat ( clientId, nonce, base64UrlEndcode(jwkThumprint), responseUri))
// For DC API hash (concat (origin, nonce, base64UrlEndcode(jwkThumprint)))
We can of course argue on the contents but start from the place that it's the same as what is used for verification of the stricter format seems reasonable.
update during the WG call: https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/84 is the still-in-draft in-process PR for JOSE-HPKE that should put 4VP and 4VCI in a place to use JOSE-HPKE rather than trying to define its own bespoke container
But does mean that the chosen algorithm suite needs to accommodate the stakeholders who are unable to proceed without HPKE. And my reading of https://mailarchive.ietf.org/arch/msg/jose/EVOyeH9SC68is87cQZfIfb7W6BA/ is that DHKEM_P256/HKDF_SHA256/AES_128_GCM will not.
I guess it depends on your stakeholders. This matches the parameters fixed by Annex C, which is the other major approach for presentations of credentials. This will also minimize the burden of RPs who are supporting both approaches, or transitioning.
That's fair and I don't honestly know the all the stakeholders or their needs. But it seemed to me that an individual from what I perceive to be a significant stakeholder behind the general requirement for HPKE is saying A256GCM is needed or it would be "blocker". That's the possibly naive thinking behind the original comment.
Given the presumptive requirements around HPKE's info, some accounting for it's similar use in ietf jose-hpke might be worthwhile.
Could you provide more details of what you expect here? I'm definitely not as familiar about jose-hpke and would appreciate the thoughts.
My expectation is that jose-hpke will allow for the setting of the info parameter into the HPKE API. So however the SessionTranscript type thing might be defined for this container (String or byte concatenation, please) would likely also be applicable to jose-hpke use from this spec layer.
But I don't think that fully captures how limiting it is.
To fully capture it I'd say: ... This would allow for agility, with the cost of some increased complexity.
Thanks for elaborating. I think it's fair to say that the extent to which it's limiting is somewhat subjective. Similar for complexity. But there's at least some limitations and increased complexity.
So the trade-off is between being able to avoid cbor libraries for sd-jwt only wallets/verifiers in exchange for increased complexity for mdocs.
Yeah, but again from the perspective of a (mostly) credential format agnostic protocol that uses HTTP/JSON/JOSE it's just a rational choice for that layer.
update during the WG call: ietf-wg-jose/draft-ietf-jose-hpke-encrypt#84 is the still-in-draft in-process PR for JOSE-HPKE that should put 4VP and 4VCI in a place to use JOSE-HPKE rather than trying to define its own bespoke container
I said I'd comment here about that but I am notably slow sometimes so thank you for beating me to it.
I have completed the PR applying the design team decisions to the JOSE HPKE spec. Please review https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/84. For ease of reviewing, there’s also a rendered version of the PR at https://self-issued.info/tmp/draft-ietf-jose-hpke-encrypt.html.
https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-15.html has now been published, which incorporates these decisions.
As @panva pointed out on the JOSE mailing list, it would be good for people to validate the examples with their implementations.
WG discussion:
- Japanese government has a requirement for HPKE based encryption for openid4vp.
- jose-hpke IETF draft getting close to WGLC.
- doing jose-hpke is just another alg when doing JWE. in which case, there are no changes for openid4vp. and it's a discussion in HAIP whether HPKE algs are mandated or not.
- need a detailed proposal how this would work for jose-hpke. @GarethCOliver volunteered to write it up in a new issue. might require a new issue in HAIP and not openid4vp, based on the above