Skip to content

First pass at HAIP HPKE section #362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
Sakurann wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

First pass at HAIP HPKE section #362

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
b97081b
create 1.0 and 1.1 folders
Sakurann Mar 9, 2026
c1f3f19
update file name typo
Sakurann Mar 9, 2026
9dfbb9b
first pass at HPKE section
Sakurann Mar 9, 2026
66b9c34
clarify psk_id must not be present
Sakurann Mar 9, 2026
058c5fa
Merge branch 'main' into haip-hpke
Sakurann Mar 25, 2026
3f99f23
Apply suggestions from Gareth's code review
Sakurann Mar 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 27 additions & 5 deletions 1.1/openid4vc-high-assurance-interoperability-profile-1_1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -255,17 +255,39 @@ The following requirements apply to OpenID for Verifiable Presentations, irrespe
* The Response type MUST be `vp_token`.
* For signed requests, the Verifier MUST use, and the Wallet MUST accept the Client Identifier Prefix `x509_hash` as defined in Section 5.9.3 of [@!OIDF.OID4VP]. The X.509 certificate of the trust anchor MUST NOT be included in the `x5c` JOSE header of the signed request. The X.509 certificate signing the request MUST NOT be self-signed. X.509 certificate profiles to be used with `x509_hash` are out of scope of this specification.
* The DCQL query and response MUST be used as defined in Section 6 of [@!OIDF.OID4VP].
* 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.
* Verifiers MUST supply ephemeral encryption public keys specific to each Authorization Request passed via client metadata as specified in Section 8.3 of [@!OIDF.OID4VP].
* The Authority Key Identifier (`aki`)-based Trusted Authority Query (`trusted_authorities`) for DCQL, as defined in section 6.1.1.1 of [@!OIDF.OID4VP], MUST be supported. Note that the Authority Key Identifiers mechanism can be used to support multiple X.509-based trust mechanisms, such as ISO mDL VICAL (as introduced in [@ISO.18013-5]) or ETSI Trusted Lists [@ETSI.TL]. This is achieved by collecting the relevant X.509 certificates for the trusted Issuers and including the encoded Key Identifiers from the certificates in the `aki` array .

Additional requirements for OpenID4VP are defined in (#oid4vp-redirects), (#oid4vp-dc-api), (#oid4vp-credential-formats), (#crypto-suites) and (#hash-algorithms).

Note that while this specification does not define profiles for X.509 certificates used in Verifier authentication (e.g., with the `x509_hash` Client Identifier Prefix), Ecosystems are encouraged to select suitable certificate issuing policies and certificate profiles (for example, an mDL Ecosystem can use the Reader Authentication Certificate profile defined in Annex B of ISO/IEC 18013-5 with `x509_hash`), or define new ones if there is a good reason to do so. Such policies and profiles MAY specify how information in the certificate corresponds to information in the presentation flows. For example, an Ecosystem might require that the Wallet verifies that the `redirect_uri`, `response_uri`, `origin`, or `expected_origin` request parameters match with information contained in the Verifier's end-entity certificate (e.g., its DNS name).

## OpenID for Verifiable Presentations via Redirects {#oid4vp-redirects}
The following combinations of the flows are supported by this specification:

* OpenID for Verifiable Presentations via Redirects & Response Encryption using ECDH-ES with JWE
* OpenID for Verifiable Presentations via Redirects & Response Encryption using HPKE with JWE
* OpenID for Verifiable Presentations via W3C Digital Credentials API & Response Encryption using ECDH-ES with JWE
* OpenID for Verifiable Presentations via W3C Digital Credentials API & Response Encryption using HPKE with JWE

## Response Encryption

Response encryption can be done using JWE with either ECDH-ES or HPKE.

The Wallet MUST determine `alg` header parameter in the `jwks` client metadata parameter and return an `invelid_request` error if it does not support algorithm indicated by the verifier.
Copy link
Copy Markdown
Contributor

@GarethCOliver GarethCOliver Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

The Wallet MUST determine the `alg` header parameter for each JWK in the `jwks` client metadata parameter and return an `invalid_request` error if it does not support any of the algorithms supplied by the verifier.

Verifier can pass more than one jwk in the jwks so can indicate support for more than one alg. Wallet should only return an error if it does not support any of them.

Section 8.3 of OpenID4VP does already describe how to obtain the alg parameter and that it must be used. Would be more consistent to just make this error text inside that paragraph as well (as it applies generically to the protocol) and maybe just reference that section from here?

Copy link
Copy Markdown
Collaborator Author

@Sakurann Sakurann Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Wallet MUST determine `alg` header parameter in the `jwks` client metadata parameter and return an `invelid_request` error if it does not support algorithm indicated by the verifier.
The Wallet MUST determine the `alg` header parameter for each JWK in the `jwks` client metadata parameter and return an `invalid_request` error if it does not support any of the algorithms supplied by the verifier.


### 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.

### Response Encryption using HPKE with JWE

Response encryption MUST be performed as specified in [@!OIDF.OID4VP, section 8.3.1] using 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.

## Wallet Invocation

Either redirects or W3C Digital Credentials API can be used by the Verifiers.

### OpenID for Verifiable Presentations via Redirects {#oid4vp-redirects}

The following requirements apply to OpenID for Verifiable Presentations via redirects:

Expand All @@ -278,7 +300,7 @@ The following requirements apply to OpenID for Verifiable Presentations via redi
* Verifiers MUST reject presentations if Wallets do not follow the redirect back or the redirect back arrives in a different user session to the one the request was initiated in.
* Implementation considerations can be found in Section 13.3 of [@!OIDF.OID4VP] and security considerations in Section 14.2 of [@!OIDF.OID4VP].

## OpenID for Verifiable Presentations via W3C Digital Credentials API {#oid4vp-dc-api}
### OpenID for Verifiable Presentations via W3C Digital Credentials API {#oid4vp-dc-api}

The following requirements apply to OpenID for Verifiable Presentations via the W3C Digital Credentials API:

Expand Down
Loading