openid4vc-high-assurance-interoperabilit October 2025
Yasuda, et al. Standards Track [Page]
Workgroup:
Digital Credentials Protocols
Published:
Authors:
K. Yasuda
SPRIND
T. Lodderstedt
SPRIND
C. Bormann
SPRIND
J. Heenan
Authlete

OpenID4VC High Assurance Interoperability Profile 1.0 - Editor's draft

Abstract

This document defines a profile of OpenID for Verifiable Credentials in combination with the credential formats IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc] and ISO mdoc [ISO.18013-5]. The aim is to select features and to define 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. The profiled specifications include OpenID for Verifiable Credential Issuance [OIDF.OID4VCI], OpenID for Verifiable Presentations [OIDF.OID4VP], IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc], and ISO mdoc [ISO.18013-5].

▲

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. Note that while this profile is aimed at high assurance use-cases, it can also be used for lower assurance use-cases.

This profile aims to achieve a level of security and privacy that includes the following properties:

Note: This profile defines the technical means by which holder authentication can be proven and claim authenticity can be protected using certain protocol and credential format features. Out of scope are concrete holder authentication mechanisms (which ensure only the holder can sign the presentation) and policies and procedures (as this is a technical interop profile and not a policy definition).

Note: This specification fulfils some, but not all, of the requirements to meet the "High" Level of Assurance (LoA) as defined in the eIDAS Regulation [eIDAS2.0]. While this profile defines features intended for scenarios targeting a high level of security, these features must be combined with additional measures outside of the scope of HAIP to achieve LoA High compliance.

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 Section 3.3.

1.1. Target Audience/Usage

The target audience of this document is implementers who require a high level of security and privacy for their solutions. A non-exhaustive list of the interested parties includes anyone implementing eIDAS 2.0, California Department of Motor Vehicles, Open Wallet Foundation (OWF), IDunion, GAIN, and the Trusted Web project of the Japanese government, but is expected to grow to include other jurisdictions and private sector companies.

1.2. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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:

Implementations of this specification do not have to implement all the flows listed above, but they MUST be compliant to all the requirements for a flow they choose to implement, as well as the requirements in the non-flow specific sections.

For each flow, at least one of the Credential profiles defined in Section 6 MUST be supported:

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

The Profile of OpenID4VCI defines Wallet Attestation and Key Attestation.

The Profile of IETF SD-JWT VC defines the following aspects:

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

3.1. Assumptions

Assumptions made are the following:

  • The Issuers and Verifiers cannot pre-discover Wallet's capability
  • The Issuer is talking to the Wallet supporting the features defined in this profile (via Wallet invocation mechanism)
  • There are mechanisms in place for Verifiers to discover Wallets' and Issuers' capabilities
  • There are mechanisms in place for Wallets to discover Verifiers' capabilities
  • There are mechanisms in place for Issuers to discover Wallets' capabilities

3.2. Scenarios/Business Requirements

  • Combined Issuance of IETF SD-JWT VC and ISO mdoc
  • Both issuer-initiated and wallet-initiated issuance
  • Presentation and Issuance of PID and (Q)EAA as defined in Architecture and Reference Framework [EU.ARF] implementing [eIDAS2.0].
  • Issuance and presentation of Credentials with and without cryptographic holder binding

3.3. Standards Requirements

The standards that are being profiled in this specification are:

Note that these standards in turn build upon other underlying standards, and requirements in those underlying standards also need to be followed.

3.4. Out of Scope

The following items are out of scope for the current version of this document, but might be added in future versions:

  • Trust Management refers to authorization of an Issuer to issue certain types of credentials, authorization of the Wallet to be issued certain types of credentials, authorization of the Verifier to receive certain types of credentials. Although X.509 PKI is extensively utilized in this profile, the methods for establishing trust or obtaining root certificates are out of the scope of this specification.
  • Protocol for presentation of Verifiable Credentials for offline use-cases, e.g. over BLE.

4. OpenID for Verifiable Credential Issuance

When implementing OpenID for Verifiable Credential Issuance, both the Wallet and the Credential Issuer:

The following aspects of [FAPI2_Security_Profile] are further profiled:

The following aspects of [FAPI2_Security_Profile] do not apply to this specification:

Note that some optional parts of [FAPI2_Security_Profile] are not applicable when using only OpenID for Verifiable Credential Issuance, e.g., MTLS or OpenID Connect.

Both Wallet initiated and Issuer initiated issuance are supported.

If batch issuance is supported, the Wallet SHOULD use it rather than making consecutive requests for a single Credential of the same Credential Dataset. The Issuer MUST indicate whether batch issuance is supported by including or omitting the batch_credential_issuance metadata parameter. The Issuer’s decision may be influenced by various factors, including, but not limited to, trust framework requirements, regulatory constraints, applicable laws or internal policies.

Additional requirements for OpenID4VCI are defined in Section 7 and Section 8.

4.1. Issuer Metadata

The Authorization Server MUST support metadata according to [RFC8414].

The Credential Issuer MUST support metadata retrieval according to Section 12.2.2 of [OIDF.OID4VCI]. The Credential Issuer metadata MUST include a scope for every Credential Configuration it supports.

When ecosystem policies require Issuer Authentication to a higher level than possible with TLS alone, signed Credential Issuer Metadata as specified in Section 11.2.3 in [OIDF.OID4VCI] MUST be supported by both the Wallet and the Issuer. Key resolution to validate the signed Issuer Metadata MUST be supported using the x5c JOSE header parameter as defined in [RFC7515]. In this case, 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.

Wallets that render images provided by the Credential Issuer in its metadata defined in Section 12.2.4 of [OIDF.OID4VCI] (e.g., the logo of a specific credential) have certain requirements. Such wallets MUST support both the SVG and PNG formats. They also MUST support images conveyed through both data URIs and HTTPS URLs.

If the Issuer supports Credential Configurations that require key binding, as indicated by the presence of cryptographic_binding_methods_supported, the nonce_endpoint MUST be present in the Credential Issuer Metadata.

4.2. Credential Offer

  • The Grant Type authorization_code MUST be supported as defined in Section 4.1.1 in [OIDF.OID4VCI]
  • For Grant Type authorization_code, the Issuer MUST include a scope value in order to allow the Wallet to identify the desired Credential Type. The Wallet MUST use that value in the scope Authorization parameter.
  • As a way to invoke the Wallet the custom URL scheme haip-vci:// MAY be supported. Implementations MAY support other ways to invoke Wallets as agreed upon by trust frameworks/ecosystems/jurisdictions, including but not limited to using other custom URL schemes or claimed "https" scheme URIs.

Note: The Authorization Code flow does not require a Credential Offer from the Issuer to the Wallet. However, it is included in the feature set to allow for Issuer initiated Credential issuance.

Both Issuer and Wallet MUST support Credential Offer in both same-device and cross-device flows.

4.3. Authorization Endpoint

  • Wallets MUST authenticate themselves at the PAR endpoint using the same rules as defined in Section 4.4 for client authentication at the token endpoint.
  • MUST use the scope parameter to communicate Credential Type(s) to be issued. The scope value MUST map to a specific Credential Type. The scope value may be pre-agreed, obtained from the Credential Offer, or the Credential Issuer Metadata.

4.4. Token Endpoint

  • Refresh tokens are RECOMMENDED to be supported for Credential refresh. For details, see Section 13.5 in [OIDF.OID4VCI].

Note: Issuers SHOULD consider how long a refresh token is allowed to be used to refresh a credential, as opposed to starting the issuance flow from the beginning. For example, if the User is trying to refresh a Credential more than a year after its original issuance, the usage of the refresh tokens is NOT RECOMMENDED.

4.4.1. Wallet Attestation

Wallets MUST use, and Issuers MUST require, an OAuth2 Client authentication mechanism at OAuth2 Endpoints that support client authentication (such as the PAR and Token Endpoints).

Ecosystems that desire wallet-issuer interoperability on the level of Wallet Attestations SHOULD require Wallets to support the authentication mechanism and Wallet Attestation format specified in Annex E of [OIDF.OID4VCI]. When doing so, they might need to define additional ecosystem-specific claims contained in the attestation. Alternatively, ecosystems MAY choose to rely on other Wallet Attestation formats.

Additional rules apply when using the format defined in Annex E of [OIDF.OID4VCI]:

  • the public key certificate, and optionally a trust certificate chain excluding the trust anchor, used to validate the signature on the Wallet Attestation MUST be included in the x5c JOSE header of the Client Attestation JWT
  • Wallet Attestations MUST NOT be reused across different Issuers. They MUST NOT introduce a unique identifier specific to a single Wallet instance. The subject claim for the Wallet Attestation MUST be a value that is shared by all Wallet instances using the present type of wallet implementation. See section 15.4.4 of [OIDF.OID4VCI] for details on the Wallet Attestation subject.
  • if applicable, the client_id value in the PAR request MUST be the string in the sub value in the client attestation JWT.
  • Wallets MUST perform client authentication with the Wallet Attestation at OAuth2 Endpoints that support client authentication.

4.5. Credential Endpoint

4.5.1. Key Attestation

Wallets MUST support key attestations. Ecosystems that desire wallet-issuer interoperability on the level of key attestations SHOULD require Wallets to support the format specified in Annex D of [OIDF.OID4VCI], in combination with the following proof types:

  • jwt proof type using key_attestation
  • attestation proof type

Alternatively, ecosystems MAY choose to rely on other key attestation formats, meaning they would need to use a proof type other than attestation, define a new proof type, or expand the jwt proof type to support other key attestation formats.

If batch issuance is used and the Credential Issuer has indicated (via cryptographic_binding_methods_supported metadata parameter) that cryptographic holder binding is required, all public keys used in Credential Request SHOULD be attested within a single key attestation.

5. OpenID for Verifiable Presentations

The following requirements apply to OpenID for Verifiable Presentations, irrespective of the flow and Credential Format:

Additional requirements for OpenID4VP are defined in Section 5.1, Section 5.2, Section 5.3, Section 7 and Section 8.

Note that while this document 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).

5.1. OpenID for Verifiable Presentations via Redirects

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

  • As a way to invoke the Wallet, the custom URL scheme haip-vp:// MAY be supported by the Wallet and the Verifier. Implementations MAY support other ways to invoke the Wallets as agreed upon by trust frameworks/ecosystems/jurisdictions, including but not limited to using other custom URL schemes or claimed "https" scheme URIs.
  • Signed Authorization Requests MUST be used by utilizing JWT-Secured Authorization Request (JAR) [RFC9101] with the request_uri parameter.
  • Response encryption MUST be used by utilizing response mode direct_post.jwt, as defined in Section 8.3 of [OIDF.OID4VP]. Security Considerations in Section 14.3 of [OIDF.OID4VP] MUST be applied.

5.2. OpenID for Verifiable Presentations via W3C Digital Credentials API

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

  • 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.
  • The Response Mode MUST be dc_api.jwt.
  • The Verifier and Wallet MUST use 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.

Note that unsigned requests depend on the origin information provided by the platform and the web PKI for request integrity protection and to authenticate the Verifier. Signed requests introduce a separate layer for request integrity protection and Verifier authentication that can be validated by the Wallet.

5.3. Requirements specific to Credential Formats

5.3.1. ISO Mobile Documents or mdocs (ISO/IEC 18013 and ISO/IEC 23220 series)

The following requirements apply to all OpenID4VP flows when the mdoc Credential Format is used:

  • The Credential Format identifier MUST be mso_mdoc.
  • When multiple ISO mdocs are being returned, each ISO mdoc MUST be returned in a separate DeviceResponse (as defined in 8.3.2.1.2.2 of [ISO.18013-5]), each matching to a respective DCQL query. Therefore, the resulting vp_token contains multiple DeviceResponse instances.
  • The Credential Issuer MAY include the MSO revocation mechanism in the issued mdoc. When doing so, it MUST use one of the mechanisms defined in ISO/IEC 18013-5 ([ISO.18013-5.second.edition]).

5.3.2. IETF SD-JWT VC

The following requirements apply to all OpenID4VP flows when the SD-JWT VC Credential Format is used:

  • The Credential Format identifier MUST be dc+sd-jwt.

6. OpenID4VC Credential Format Profiles

Credential Format Profiles are defined as follows:

6.1. IETF SD-JWT VC Profile

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.
  • It is RECOMMENDED that Issuers limit the validity period when issuing SD-JWT VC. When doing so, the Issuer MUST use an exp claim, a status claim, or both.
  • 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 member if the corresponding Credential Configuration requires cryptographic holder binding.
  • The status claim, if present, MUST contain status_list as defined in [I-D.ietf-oauth-status-list]
  • The public key used to validate the signature on the Status List Token defined in [I-D.ietf-oauth-status-list] MUST be included in the x5c JOSE header of the Token. The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the Status List Token. The X.509 certificate signing the request MUST NOT be self-signed.

Each Credential MUST have its own unique, unpredictable status list index, even when multiple Credentials reference the same status list URI (see section 13.2 of [I-D.ietf-oauth-status-list]). Refer to section 12.5 of [I-D.ietf-oauth-status-list] for additional privacy considerations on unlinkability.

Note: For guidance on preventing linkability by colluding parties, such as Issuer/Verifier pairs, multiple Verifiers, or repeated interactions with the same Verifier, see Section 15.4.1 of [OIDF.OID4VCI] and Section 15.5 of [OIDF.OID4VP].

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 (e.g., diploma attestation). Therefore, this profile leaves its inclusion to the Issuer, or the body defining the respective Credential Type.

6.1.1. Issuer identification and key resolution to validate an issued Credential

This profile mandates the support for X.509 certificate-based key resolution to validate the issuer signature of an SD-JWT VC. This MUST be supported by all entities (Issuer, Wallet, Verifier). The SD-JWT VC MUST contain the credential issuer's signing certificate along with a trust chain in the x5c JOSE header parameter as described in section 3.5 of [I-D.ietf-oauth-sd-jwt-vc]. The X.509 certificate of the trust anchor MUST NOT be included in the x5c JOSE header of the SD-JWT VC. The X.509 certificate signing the request MUST NOT be self-signed.

6.1.1.1. Cryptographic Holder Binding between VC and VP
  • If the credential has cryptographic holder binding, a KB-JWT, as defined in [I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC.

7. Crypto Suites

Issuers, Verifiers, and Wallets MUST, at a minimum, support ECDSA with P-256 and SHA-256 (JOSE algorithm identifier ES256; COSE algorithm identifier -7, as applicable) for the purpose of validating the following:

Ecosystem-specific profiles MAY mandate additional cryptographic suites.

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

8. Hash Algorithms

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.

Ecosystem-specific profiles MAY mandate additional hashing algorithms.

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

9. Implementation Considerations

9.1. Requirements for browser/OS support of specific features

This specification relies on certain prerequisites, such as browser or operating system support for specific features. When these prerequisites are mandatory for a flow (e.g., the W3C Digital Credentials API or an equivalent platform API), an implementer might be unable to support that flow due to factors beyond their control. In other cases (e.g., custom URL schemes), the prerequisites are optional, allowing implementers to achieve the same flow through alternative mechanisms.

9.2. Interoperable Key Attestations

Wallet implementations using the key attestation format specified in Annex D of [OIDF.OID4VCI] might need to utilize a transformation (backend) service to create such attestations based on data as provided in other formats by the respective platform or secure key management module. The dependency on such a service might impact the availability of the wallet app as well as the performance of the issuance process. This could be mitigated by creating keys and obtaining the respective key attestations in advance.

10. Security Considerations

Note that security considerations for OpenID for Verifiable Credential Issuance are defined in Section 13 of [OIDF.OID4VCI] and for OpenID for Verifiable Presentations in Section 14 (for redirect based flows) or Section A.5 (for DC API) of [OIDF.OID4VP].

10.1. Incomplete or Incorrect Implementations of the Specifications and Conformance Testing

To achieve the full security benefits, it is important that the implementation of this specification, and the underlying specifications, are both complete and correct.

The OpenID Foundation provides tools that can be used to confirm that an implementation is correct and conformant:

https://openid.net/certification/conformance-testing-for-openid-for-verifiable-credential-issuance/

https://openid.net/certification/conformance-testing-for-openid-for-verifiable-presentations/

10.2. Key sizes

Implementers need to ensure appropriate key sizes are used. Guidance can be found in, for example, [NIST.SP.800-131A], [NIST.SP.800-57] or [BSI.TR-02102-1].

11. Privacy Considerations

11.1. Interoperable Key Attestations

Wallet implementations using the key attestation format specified in Annex D of [OIDF.OID4VCI] might need to utilize a transformation (backend) service to create such attestations based on data as provided in other formats by the respective platform or secure key management module. Such a backend service MUST be designed considering the privacy of its users. For example, the service could be stateless and just perform the transformation of the attestation data without binding the process in any way to a unique user identifier.

12. Normative References

[FAPI2_Security_Profile]
Fett, D., Tonge, D., and J. Heenan, "FAPI 2.0 Security Profile", , <https://openid.net/specs/fapi-security-profile-2_0.html>.
[I-D.ietf-oauth-sd-jwt-vc]
Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-11>.
[I-D.ietf-oauth-selective-disclosure-jwt]
Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-22>.
[I-D.ietf-oauth-status-list]
Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-12>.
[ISO.18013-5]
ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification, "ISO/IEC 18013-5:2021 Personal identification — ISO-compliant driving license — Part 5: Mobile driving license (mDL) application", , <https://www.iso.org/standard/69084.html>.
[ISO.18013-5.second.edition]
ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification, "ISO/IEC 18013-5:xxxx Personal identification — ISO-compliant driving license — Part 5: Mobile driving license (mDL) application edition 2", <https://www.iso.org/standard/91081.html>.
[OIDF.OID4VCI]
Lodderstedt, T., Yasuda, K., Looker, T., and P. Bastian, "OpenID for Verifiable Credential Issuance 1.0", , <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html>.
[OIDF.OID4VP]
Terbu, O., Lodderstedt, T., Yasuda, K., Fett, D., and J. Heenan, "OpenID for Verifiable Presentations 1.0", , <https://openid.net/specs/openid-4-verifiable-presentations-1_0.html>.
[OIDF.ekyc-ida]
yes, Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance 1.0", , <https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID4.html>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516]
Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, , <https://www.rfc-editor.org/info/rfc7516>.
[RFC7517]
Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/info/rfc7517>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <https://www.rfc-editor.org/info/rfc7518>.
[RFC7636]
Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, , <https://www.rfc-editor.org/info/rfc7636>.
[RFC7800]
Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/info/rfc7800>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , <https://www.rfc-editor.org/info/rfc8414>.
[RFC9101]
Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, , <https://www.rfc-editor.org/info/rfc9101>.
[RFC9126]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, , <https://www.rfc-editor.org/info/rfc9126>.
[RFC9207]
Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, , <https://www.rfc-editor.org/info/rfc9207>.
[RFC9449]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/info/rfc9449>.

13. Informative References

[BSI.TR-02102-1]
Federal Office for Information Security (BSI), "Cryptographic Mechanisms: Recommendations and Key Lengths", , <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile>.
[ETSI.TL]
European Telecommunications Standards Institute (ETSI), "ETSI TS 119 612 V2.4.1 Electronic Signatures and Trust Infrastructures (ESI); Trusted Lists", , <https://www.etsi.org/deliver/etsi_ts/119600_119699/119612/02.04.01_60/ts_119612v020401p.pdf>.
[EU.ARF]
European Commission, "European Digital Identity Wallet Architecture and Reference Framework", , <https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/>.
[IANA.URI.Schemes]
IANA, "Uniform Resource Identifier (URI) Schemes", <https://www.iana.org/assignments/uri-schemes>.
[NIST.SP.800-131A]
Barker, E. and A. Roginsky, "NIST SP 800-131A: Transitioning the Use of Cryptographic Algorithms and Key Lengths", , <https://csrc.nist.gov/pubs/sp/800/131/a/r2/final>.
[NIST.SP.800-57]
Barker, E., "NIST SP 800-57 Part 1: Recommendation for Key Management: Part 1 – General", , <https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final>.
[eIDAS2.0]
European Union, "REGULATION (EU) 2024/1183 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework", , <https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401183>.
[w3c.digital_credentials_api]
Caceres, M., Cappalli, T., and M. A. Yosef, "Digital Credentials API", , <https://www.w3.org/TR/digital-credentials/>.

Appendix A. IANA Considerations

A.1. Uniform Resource Identifier (URI) Schemes Registry

This specification registers the following URI schemes in the IANA "Uniform Resource Identifier (URI) Schemes" registry [IANA.URI.Schemes].

A.1.1. haip-vci

  • Scheme name: haip-vci
  • Status: Permanent
  • Applications/protocols that use this scheme name: Wallets that implement the OIDF HAIP profile to offer a Credential using OpenID for Verifiable Credential Issuance
  • Contact: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 4.2 of this specification

A.1.2. haip-vp

  • Scheme name: haip-vp
  • Status: Permanent
  • Applications/protocols that use this scheme name: Verifiers invoking Wallets that implement the OIDF HAIP profile to request the presentation of Credentials using OpenID for Verifiable Presentations
  • Contact: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
  • Reference: Section 5.1 of this specification

Appendix B. Acknowledgements

We would like to thank Patrick Amrein, Paul Bastian, Brian Campbell, Lee Campbell, Tim Cappalli, Stefan Charsley, Gabe Cohen, Andrii Deinega, Daniel Fett, Pedro Felix, Ryan Galluzzo, Timo Glastra, Martijn Haring, Bjorn Hjelm, Alen Horvat, Łukasz Jaromin, Mike Jones, Markus Kreusch, Philipp Lehwalder, Tobias Looker, Hicham Lozi, Mirko Mollik, Gareth Oliver, Oliver Terbu, Giuseppe De Marco, Mikel Pintor, Joel Posti, Dima Postnikov, Andreea Prian, Bob Reynders, Samuel Rinnetmäki, Peter Sorotokin, Jan Vereecken and David Zeuthen for their valuable feedback and contributions to this specification.

Appendix C. 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 D. Document History

[[ To be removed from the final specification ]]

-05

-04

-03

-02

-01

-00

Authors' Addresses

Kristina Yasuda
SPRIND
Torsten Lodderstedt
SPRIND
Christian Bormann
SPRIND
Joseph Heenan
Authlete