Conversation
Sakurann
requested review from
GarethCOliver,
awoie,
bc-pi,
c2bo,
hlozi,
jogu,
selfissued,
tlodderstedt and
tplooker
and removed request for
jogu
March 9, 2026 16:07
Sakurann
commented
Mar 12, 2026
|
|
||
| ### Response Encryption using HPKE with JWE | ||
|
|
||
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3.1]. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `HPKE-0` (as defined in [@I-D.ietf-jose-hpke-encrypt]). The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) value `A128GCM` (as defined in [@!RFC7518, section 5.3]) MUST be supported by Verifiers and Wallets. |
Collaborator
Author
There was a problem hiding this comment.
need to omit enc.
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
GarethCOliver
approved these changes
Mar 26, 2026
GarethCOliver
left a comment
GarethCOliver
left a comment
Contributor
There was a problem hiding this comment.
lgtm with the suggested change.
javereec
reviewed
Apr 24, 2026
Sakurann
marked this pull request as ready for review
April 27, 2026 20:23
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> Co-authored-by: Jan Vereecken <ciao@janvereecken.com>
fkj
reviewed
Jul 24, 2026
|
|
||
| ### Response Encryption using ECDH-ES with JWE | ||
|
|
||
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3]. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `ECDH-ES` (as defined in [@!RFC7518, section 4.6]), with key agreement utilizing keys on the `P-256` curve (see [@!RFC7518, section 6.2.1.1]) MUST be supported. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) values `A128GCM` and `A256GCM` (as defined in [@!RFC7518, section 5.3]) MUST be supported by Verifiers. Wallets MUST support `A128GCM` or `A256GCM`, or both. If both are supported, the Wallet SHOULD use `A256GCM` for the JWE `enc`. Verifiers MUST list both `A128GCM` and `A256GCM` in `encrypted_response_enc_values_supported` in their client metadata. |
Member
There was a problem hiding this comment.
I think this makes the normative requirement clearer:
Suggested change
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3]. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `ECDH-ES` (as defined in [@!RFC7518, section 4.6]), with key agreement utilizing keys on the `P-256` curve (see [@!RFC7518, section 6.2.1.1]) MUST be supported. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) values `A128GCM` and `A256GCM` (as defined in [@!RFC7518, section 5.3]) MUST be supported by Verifiers. Wallets MUST support `A128GCM` or `A256GCM`, or both. If both are supported, the Wallet SHOULD use `A256GCM` for the JWE `enc`. Verifiers MUST list both `A128GCM` and `A256GCM` in `encrypted_response_enc_values_supported` in their client metadata. | |
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3]. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `ECDH-ES` (as defined in [@!RFC7518, section 4.6]), with key agreement utilizing keys on the `P-256` curve (see [@!RFC7518, section 6.2.1.1]) MUST be supported. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) values `A128GCM` and `A256GCM` (as defined in [@!RFC7518, section 5.3]) MUST be supported by Verifiers. Wallets MUST support `A128GCM` or `A256GCM` or both. If the Wallet supports both, it SHOULD use `A256GCM` for the JWE `enc`. Verifiers MUST list both `A128GCM` and `A256GCM` in `encrypted_response_enc_values_supported` in their client metadata. |
|
|
||
| ### Response Encryption using HPKE with JWE | ||
|
|
||
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3.1] using JOSE HPKE integrated encryption. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `HPKE-0` (as defined in [@I-D.ietf-jose-hpke-encrypt]) MUST be supported by Wallets and Verifiers. `psk_id` (pre-shared key id) header parameter MUST NOT be present. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) MUST NOT be present. |
Member
There was a problem hiding this comment.
Suggested change
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3.1] using JOSE HPKE integrated encryption. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `HPKE-0` (as defined in [@I-D.ietf-jose-hpke-encrypt]) MUST be supported by Wallets and Verifiers. `psk_id` (pre-shared key id) header parameter MUST NOT be present. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) MUST NOT be present. | |
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3.1] using JOSE HPKE integrated encryption. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `HPKE-0` (as defined in [@I-D.ietf-jose-hpke-encrypt]) MUST be supported by Wallets and Verifiers. The `psk_id` (pre-shared key id) header parameter MUST NOT be present. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) MUST NOT be present. |
|
|
||
| ### Response Encryption using HPKE with JWE | ||
|
|
||
| Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3.1] using JOSE HPKE integrated encryption. The JWE `alg` (algorithm) header parameter (see [@!RFC7516, section 4.1.1]) value `HPKE-0` (as defined in [@I-D.ietf-jose-hpke-encrypt]) MUST be supported by Wallets and Verifiers. `psk_id` (pre-shared key id) header parameter MUST NOT be present. The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) MUST NOT be present. |
Member
There was a problem hiding this comment.
psk_id(pre-shared key id) header parameter MUST NOT be present
The JWE
enc(encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) MUST NOT be present.
It would probably be helpful to clarify where/when they must not be present.
|
|
||
| ## Wallet Invocation | ||
|
|
||
| Either redirects or W3C Digital Credentials API (or an equivalent platform API) can be used by the Verifiers as defined in this section. |
Member
There was a problem hiding this comment.
I think this is really normative language. It should be rewritten to make this clear. Here's what I think is intended:
Suggested change
| Either redirects or W3C Digital Credentials API (or an equivalent platform API) can be used by the Verifiers as defined in this section. | |
| Verifiers that use OpenID for Verifiable Presentations via redirects or the W3C Digital Credentials API (or an equivalent platform API) MUST follow the requirements defined in this section. |
Member
|
I think this needs to be rebased before merging, and also we should probably check that section number references are still accurate. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
resolves #356
resolves #357
builds up on #361 (#361 needs to be merged first)