OpenID4VC High Assurance Interoperability Profile 1.0 - Editor's draft

Table of Contents

1. Introduction

This document defines a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. This document is an interoperability profile that can be used by implementations in various contexts, be it a certain industry or a certain regulatory environment.¶

This document is not a specification, but a profile. It refers to the specifications required for implementations to interoperate among each other and for the optionalities mentioned in the referenced specifications, defines the set of features to be mandatory to implement.¶

The profile uses OpenID for Verifiable Credential Issuance [OIDF.OID4VCI] and OpenID for Verifiable Presentations [OIDF.OID4VP] as the base protocols for issuance and presentation of Credentials, respectively. The credential formats used are IETF SD-JWT VC as specified in [I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [ISO.18013-5]. Additionally, considerations are given on how the issuance of Credentials in both IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [ISO.18013-5] formats can be performed in the same transaction.¶

A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference).¶

2. Terminology

This specification uses the terms "Holder", "Issuer", "Verifier", "Wallet", "Wallet Attestation", "Credential Type" and "Verifiable Credential" as defined in [OIDF.OID4VCI] and [OIDF.OID4VP].¶

3. Scope

This specification enables interoperable implementations of the following flows:¶

• Issuance of IETF SD-JWT VC using OpenID4VCI¶
• Presentation of IETF SD-JWT VC using OpenID4VP¶
• Presentation of IETF SD-JWT VC using OpenID4VP over W3C Digital Credentials API¶
• Presentation of ISO mdocs using OpenID4VP over W3C Digital Credentials API¶

Implementations of this specification do not have to implement all of the flows listed above, but they MUST be compliant to all of the requirements for a particular flow they chose to implement.¶

A parameter that is listed as optional to be implemented in a specification that is being profiled (i.e., OpenID4VCI, OpenID4VP, W3C Digital Credentials API, IETF SD-JWT VC, and ISO mdoc) remains optional unless it is stated otherwise in this specification.¶

Profile of OpenID4VCI defines Wallet Attestation and Key Attestation.¶

Profile of IETF SD-JWT VC defines the following aspects * Status management of the Credentials, including revocation * Cryptographic Key Binding * Issuer key resolution * Issuer identification (as prerequisite for trust management)¶

Mandatory to implement crypto suites are defined for all of the flows.¶

Note that when OpenID4VP is used, the Wallet and the Verifier can either be remote or in-person.¶

4. OpenID for Verifiable Credential Issuance

Both the Wallet and the Credential Issuer:¶

• MUST support the authorization code flow.¶
• MUST support protocol extensions for the SD-JWT VC Credential format profile as defined in Section 7.2.¶
• MUST support sender-constrained tokens using the mechanism defined in [RFC9449].¶
• MUST support [RFC7636] with S256 as the code challenge method.¶

Both Wallet initiated and Issuer initiated issuance is supported.¶

5. OpenID for Verifiable Presentations profile for IETF SD-JWT VC

Requirements for both the Wallet and the Verifier:¶

• As a way to invoke the Wallet, at least a custom URL scheme haip:// MUST be supported. Implementations MAY support other ways to invoke the Wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.¶
• Response type MUST be vp_token.¶
• Response mode MUST be direct_post.jwt. The Verifier MUST return redirect_uri in response to the HTTP POST request from the Wallet, where the Wallet redirects the User to, as defined in Section 8.2 of [OIDF.OID4VP]. Implementation considerations for the response mode direct_post.jwt are given in Section 14.3 of [OIDF.OID4VP].¶
• Authorization Request MUST be sent using the request_uri parameter as defined in JWT-Secured Authorization Request (JAR) [RFC9101].¶
• The Client Identifier Prefix as introduced in Section 5.10 of [OIDF.OID4VP] MUST be either x509_san_dns or verifier_attestation. The Wallet MUST support both. The Verifier MUST support at least one.¶
• To obtain the Issuer's public key for Verification, Verifiers MUST support Web-based key resolution, as defined in Section 5 of [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key.¶
• The DCQL query and response as defined in Section 6 of [OIDF.OID4VP] MUST be used.¶

6. OpenID for Verifiable Presentations over W3C Digital Credentials API

The following requirements apply for both, the Wallet and the Verifier, unless specified otherwise:¶

• MUST support Annex A in [OIDF.OID4VP] that defines how to use OpenID4VP over the W3C Digital Credentials API.¶

  • The Wallet MUST support both signed and unsigned requests as defined in Annex A.3.1 and A.3.2 of [OIDF.OID4VP]. The Verifier MAY support signed requests, unsigned requests, or both.¶
• Wallet Invocation is done via the W3C Digital Credentials API or an equivalent platform API. Any other mechanism, including Custom URL schemes, MUST NOT be used.¶
• Response Mode MUST be dc_api.jwt. The response MUST be encrypted.¶
• Response encryption MUST be performed as specified in Section 8.3 of [OIDF.OID4VP]. The JWE alg (algorithm) header parameter (see Section 4.1.1 of [RFC7516]) value ECDH-ES (as defined in Section 4.6 of [RFC7518]), with key agreement utilizing keys on the P-256 curve (see Section 6.2.1.1 of [RFC7518]) MUST be supported. The JWE enc (encryption algorithm) header parameter (see Section 4.1.2 of [RFC7516]) value A128GCM (as defined in Section 5.3 of [RFC7518]) MUST be supported.¶
• The DCQL query and response as defined in Section 6 of [OIDF.OID4VP] MUST be used. Presentation Exchange as defined in Sections 5.4 and 5.5 of [OIDF.OID4VP] MUST NOT be used.¶

7. SD-JWT VCs

This profile defines the following additional requirements for IETF SD-JWT VCs as defined in [I-D.ietf-oauth-sd-jwt-vc].¶

• Compact serialization MUST be supported as defined in [I-D.ietf-oauth-selective-disclosure-jwt]. JSON serialization MAY be supported.¶
• The following JWT Claims MUST be supported Content (differentiate issuance & presentation)¶

• The Issuer MUST NOT make any of the JWT Claims in the table above to be selectively disclosable, so that they are always present in the SD-JWT-VC presented by the Holder.¶
• It is at the discretion of the Issuer whether to use exp claim and/or a status claim to express the validity period of an SD-JWT-VC. The Wallet and the verifier MUST support both mechanisms.¶
• The iss claim MUST be an HTTPS URL. The iss value is used to obtain Issuer's signing key as defined in Section 7.1.¶
• The vct JWT claim as defined in [I-D.ietf-oauth-sd-jwt-vc].¶
• The cnf claim [RFC7800] MUST conform to the definition given in [I-D.ietf-oauth-sd-jwt-vc]. Implementations conforming to this profile MUST include the JSON Web Key [RFC7517] in the jwk sub claim.¶

Any of the flows defined in this specification MUST be used with cryptographic holder binding.¶

Note: Re-using the same Credential across Verifiers, or re-using the same JWK value across multiple Credentials gives colluding Verifiers a mechanism to correlate the User. There are currently two known ways to address this with SD-JWT VCs. First is to issue multiple instances of the same Credentials with different JWK values, so that if each instance of the Credential is used at only one Verifier, it can be reused multiple times. Another is to use each Credential only once (ephemeral Credentials). It is RECOMMENDED to adopt one of these mechanisms.¶

Note: If there is a requirement to communicate information about the verification status and identity assurance data of the claims about the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. It is up to each jurisdiction and ecosystem, whether to require it to the implementers of this profile.¶

Note: If there is a requirement to provide the Subject’s identifier assigned and maintained by the Issuer, the sub claim MAY be used. There is no requirement for a binding to exist between the sub and cnf claims. See the Implementation Considerations section in [I-D.ietf-oauth-sd-jwt-vc].¶

Note: In some Credential Types, it is not desirable to include an expiration date (eg: diploma attestation). Therefore, this profile leaves its inclusion to the Issuer, or the body defining the respective Credential Type.¶

8. Crypto Suites

Cryptography is required by the following operations:¶

• to sign and validate the signature on the Wallet Attestation and its proof of possession¶
• to sign and validate the Issuer's signature on the Verifiable Credential¶
• to sign and validate the Holder's signature on the Verifiable Presentation¶
• to sign and validate the Verifier's signature on the Presentation Request¶

Issuers, Holders, and Verifiers MUST support P-256 (secp256r1) as a key type with the ES256 JWT algorithm [RFC7518] for the creation and the verification of the above signatures.¶

When using this profile alongside other cryptosuites, each entity SHOULD make it explicit in its metadata which other algorithms and key types are supported for the cryptographic operations.¶

9. Hash Algoritms

The hash algorithm SHA-256 MUST be supported by all the entities to generate and validate the digests in the IETF SD-JWT VC and ISO mdoc.¶

When using this profile alongside other hash algorithms, each entity SHOULD make it explicit in its metadata which other algorithms are supported.¶

10. Implementations Considerations

11. Security Considerations

The security considerations in [OIDF.OID4VCI] and [OIDF.OID4VP] apply.¶

Appendix A. Acknowledgements

We would like to thank Paul Bastian, Christian Bormann, Mike Jones, Oliver Terbu, Daniel Fett, and Giuseppe De Marco for their valuable feedback and contributions to this specification.¶

Appendix B. Notices

Copyright (c) 2025 The OpenID Foundation.¶

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶

Appendix C. Document History

[[ To be removed from the final specification ]]¶

-04¶

• add key attestation to OpenID4VCI¶
• clarify text regarding mdoc specific parameters¶
• Add small note that establishing trust in and retrieving root certs is out scope¶
• Update wording from Client Identifier Scheme to Client Identifier Prefix #182¶
• fix reference to ARF #177¶
• Old link in section 8 & clarify a note on claim based binding in OpenID4VP in HAIP #183¶
• Clarify clause 4.1 statement #169¶
• add a list of all specifications being profiled #145¶

-03¶

• Add initial security considerations section¶
• Update notices section to match latest OIDF process document¶

-02¶

• Mandate DCQL instead of presentation exchange¶
• Refactor HAIP and add details for mdoc profile over DC API¶
• Add specific requirements for response encryption¶
• Add SessionTranscript requirements¶
• Update OID4VP reference to draft 24¶

-01¶

• Remove the Wallet Attestation Schema and point to OpenID4VCI instead¶
• Rename specification to enable non-SD-JWT credential formats to be included¶
• Require encrypted responses¶
• Remove reference to client_id_scheme parameter that no longer exists in OpenID4VP¶
• Refresh tokens are now optional¶

-00¶

• initial revision¶

Authors' Addresses