ANNEX XIISupplementary provisions
ANNEX XII ‘ ANNEX II Technical specifications referred to in Article 5 The technical specification in Annex C to ISO/IEC 18013-7:2025 shall apply. The technical specifications in clauses 4.1, 4.2, 5, and 6 of ETSI TS 119 472-2 V1.2.1 (2026-03), shall apply with the following adaptations, including the insertion of a new clause 4.3: (1) 1 Scope — The present document specifies two profiles of protocols for allowing Relying Parties (RP hereinafter) to request EAAPs or Personal Identification Data (PID hereinafter) to the EUDI Wallet, and the EUDI Wallet to send the requested EAAPs/PIDs to the RP. Each of the profiles supports two transmission mechanisms, namely: API-mediated and non-API mediated, as shown below: (a) A profile is built on: — ISO/IEC 18013-5 [10] for non-API mediated transmission mechanism only, and — Annex C of ISO/IEC 18013-7 [16] for API-mediated transmission mechanism. This profile is named ISO/IEC-mdoc profile and it is defined in clause 5 of the present document. (b) A profile is built on: OpenID4VC-HAIP [11] for both API-mediated and non-API mediated transmission mechanisms, as follows: — Sections 5, 5.1, 5.3, 7, and 8 of [11] for transmission via Redirects or non-API mediated transmission mechanism, and — Sections 5, 5.2, 5.3, 7, and 8 of [11] for API-mediated transmission mechanism. This profile is named OpenID4VC-HAIP profile and it is defined in clause 6 of the present document. (2) 2.1 Normative references — [15] ISO 639: 'Language code'. — [16] ISO/IEC 18013-7:2025 'Personal identification – ISO – compliant driving licence – Part 7: Mobile driving licence (mDL) add-on functions'. (3) 4.1 EAAP implementation based on SD-JWT VC — EAAP-SD-JWT VC-04: void. (4) 4.2 EAAP implementation based on ISO/IEC-mdoc — EAAP-ISO/IEC-mdoc-01: void. — Note2 : void. — EAAP-ISO/IEC-mdoc-02: void. (5) 4.3 EAAP implementation with mediating API — EAAP-API-GEN-01: The EUDI Wallet shall support a mediating API that supports both protocols defined in clause 5.2 of [11] and in Annex C of [16]. — NOTE : Where the device on which the EUDI Wallet is installed does not support both protocols, this requirement cannot be met and triggers a non-conformity due to underlying operating systems and browsers not implementing the necessary interoperability features. — EAAP-API-GEN-02: The EUDI Wallet shall support a mediating API at least for PIDs and EAA types registered in the catalogue of schemes as defined in Implementing Regulation (EU) 2025/1569, and at least for all the formats defined in Annex II to Implementing Regulation (EU) 2024/2979. — NOTE 1 : Where the underlying operating system, browser, mediating APIs, or any other technical layer outside the control of the EUDI Wallet restricts, filters, preselects, or otherwise constrains the credential formats, and the PID and EAA types registered in the catalogue of schemes, this requirement cannot be met. Where such a restriction prevents the EUDI Wallet from supporting a registered credential type or format, the resulting non-conformity is attributable to the failure of those underlying operating systems, browsers, mediating API, or other relevant technical layer to provide the necessary interoperability features. (6) 4.4 Wallet-relying party validation and overasking checks — WRP-VALIDATION-01: The EUDI Wallet shall validate the wallet-relying party registration certificate received in the request before presenting any requested PID or electronic attestation of attributes to the wallet user for approval. — WRP-VALIDATION-02: Where the validation of the wallet-relying party registration certificate fails, including where the certificate is expired, revoked, not issued by a valid trusted provider of wallet-relying party registration certificates, malformed, or cannot be cryptographically verified, the EUDI Wallet shall warn the wallet user that the wallet-relying party could not be validated and shall not present the request as successfully validated. The wallet user shall explicitly approve the request of the relying party. Silence or pre-ticked boxes shall not suffice for explicit approval. — WRP-VALIDATION-03: The wallet provider shall determine, based on its risk analysis and security policy, whether and under which conditions specific failed validation checks may be bypassed by the wallet user. — WRP-OVERASKING-01: The EUDI Wallet shall compare the attestations and attributes requested by the wallet-relying party with the registered attestations and attributes in the wallet-relying party registration certificate. — WRP-OVERASKING-02: Where the wallet-relying party requests PID or electronic attestations of attributes or claims that are not covered by the wallet-relying party registration certificate, the EUDI Wallet shall clearly warn the wallet user before any disclosure. The warning shall identify that the wallet-relying party is requesting more information than it has registered. The wallet user shall explicitly approve the request of the relying party. Silence or pre-ticked boxes shall not suffice for explicit approval. — WRP-OVERASKING-03: The wallet provider shall determine, based on its risk analysis, security policy and applicable law, whether the wallet user may continue despite such warning, whether only the subset of requested data covered by the registration certificate may be disclosed, or whether the request shall be rejected. (7) 5.1 Introduction — Clause 5 and its subclauses define a profile for a protocol allowing a RP to request EAAPs or PIDs to the EUDI Wallet, and the EUDI Wallet to send the requested EAAPs/PIDs to the RP using either a non-API mediated transmission mechanism, built on ISO/IEC 18013-5 [10] or an API-mediated transmission mechanism built on Annex C of ISO/IEC 18013-7 [16] for transferring the data structures defined in ISO/IEC 18013-5 [10] suitably encapsulated. — The rest of clause 5 is organised as follows: — Clause 5.2 defines requirements on support of the profile and transmission mechanisms by RPs and EUDI Wallet; — Clause 5.3 specifies requirements that are specific for the non-API mediated transmission mechanism; — Clause 5.4 and its subclauses specify requirements that are specific for the API-mediated transmission mechanism. (8) 5.2 Requirements on EUDI Wallet and RP support — ISO/IEC 18013-SUPPORT-01: Wallet Units, PID Providers, Attestation Providers, Wallet Providers, and Relying Parties shall not support server retrieval as specified in ISO/IEC 18013-5 [10] for requesting and presenting PID or attestation attributes. — ISO/IEC 18013-SUPPORT-02: The EUDI Wallet shall meet the requirements defined in clauses 5.3 and 5.4 of the present document. — ISO/IEC 18013-SUPPORT-04: A Relying Party should implement the profile defined in clause 5.4 of the present document. (9) 5.3.2 ISO/IEC-mdoc EAAP Request contents — ISO/IEC 18013-5-REQ-04: Device requests sent to EUDI Wallets shall contain the 'requestInfo' key-value pair specified in clause 8.3.2.1.2.1 of [10]. The value of this pair shall be of type RequestInfo. — ISO/IEC 18013-5-REQ-05: The RequestInfo type shall be as the CDDL definition shows below. RequestInfo = { 'euWrprc': bstr ; contains a registration certificate (see requirements below) } — ISO/IEC 18013-5-REQ-06: The mentioned requestInfo member shall contain a member with label 'euWrprc' — ISO/IEC 18013-5-REQ-07: The value of the 'euWrprc' shall be a CBOR-encoded registration certificate. — ISO/IEC 18013-5-REQ-08: void. — NOTE 3 : void. — ISO/IEC 18013-5-REQ-09: void. — ISO/IEC 18013-5-REQ-10: void. — ISO/IEC 18013-5-REQ-11: void. (10) 5.3.3 ISO/IEC-mdoc EAAP Response profile — The present clause defines requirements for the DeviceResponse message type, common to the two types of transmission mechanisms (API-mediated and non-API mediated). — NOTE 1 : Where a non-API mediated mechanism built on ISO/IEC 18013-5 [10] is used, an EAAP Response is exactly an instance of DeviceResponse as profiled in the present clause, Where an API-mediated mechanism built on Annex C of ISO/IEC 18013-7 [16] is used, the instance of DeviceRequest is encapsulated as specified in Annex C of [16]. — ISO/IEC 18013-5-RESP-02: The provider of person identification data and electronic attestations of attributes shall not include any data elements in the KeyAuthorizations map in the Mobile Security Object of the person identification data and electronic attestations of attributes they issue, except for data elements that are provided by the wallet-relying party in the transactional data in the mdoc request to be signed or sealed by the wallet unit using the private key of the person identification data or electronic attestations of attributes. — NOTE 2 : As a result, wallet units cannot present any device-signed data elements to wallet-relying parties, except to signing data that the wallet-relying party provided, for example in use cases for secure user authentication. — NOTE 3 : ISO/IEC 18013-5:2021 does not specify how wallet-relying parties can include transactional data in an mdoc request. The inclusion of transactional data in an mdoc request shall take place with the addition of technical specifications. — ISO/IEC 18013-5-RESP-03: Providers of person identification data shall not allow the private key of the person identification data to sign data elements that are provided by the wallet-relying party in the transactional data in the mdoc request. (11) 5.4 Requirements for API mediated mechanism 5.4.1 ISO/IEC 18013-7-related requirements The present clause defines requirements for API-mediated transmission mechanism related to the requirements defined in Annex C of [16]. — ISO/IEC 18013-7-API-01: The profile supporting API-mediated presentations shall comply with the requirements in Annex C of ISO/IEC 18013-7 [16] as further profiled in clauses 5.3 and 5.4 of the present document. — ISO/IEC 18013-7-API-02: All the mandatory requirements defined in Annex C of [16] shall apply as further profiled in clauses 5.3 and 5.4 of the present document. — ISO/IEC 18013-7-API-03: All the optional requirements defined in Annex C of [16] shall remain optional unless stated otherwise in the present document. (12) 5.4.2 Additional requirements — The present clause specifies additional requirements for API-mediated transmission mechanism. — ISO/IEC 18013-ADD-API-01: The EUDI Wallet shall by default disclose the presence of all stored electronic attestations of attributes’ type to the mediating API that works in accordance with Annex C of [16], but it shall not disclose the attributes and their values in these electronic attestations of attributes. — NOTE 1 : The attribute value restriction applies even if such disclosure would enhance the services provided by the Operating System to the EUDI Wallet, for example, attestation selection in the context of the mediating API. — There are the considerations related to operating systems and browsers which fall out of the control of implementers, which can be taken into account as indicated in the following notes 2 to 4: — NOTE 2 : A presentation request from a Relying Party supporting Annex C of [16] can be processed by the browser and/or the Operating System for searching available EAAs, for preventing fraud targeting the User, or for troubleshooting purposes. — NOTE 3 : A presentation request from a Relying Party supporting Annex C of [16] is expected to be processed by the browser and/or the Operating System for User security purposes. — NOTE 4 : A presentation request from a Relying Party supporting Annex C of [16] is expected not to be processed by the browser and/or the Operating System for market analysis purposes (including as a secondary purpose) or for the browser's and/or the Operating System's internal purposes. — ISO/IEC 18013-ADD-API-02: Where an EUDI Wallet deletes on the User's request a PID or EAA previously disclosed to the mediating API that works in accordance with Annex C of [16], the EUDI Wallet shall disclose the fact that it no longer stores this PID or EAA to the mediating API. — ISO/IEC 18013-ADD-API-03: If the User uninstalls their EUDI Wallet, the EUDI Wallet shall disclose the fact that it no longer stores any previously disclosed PID(s) or EAA(s) to the mediating API that works in accordance with Annex C of [16]. — ISO/IEC 18013-ADD-API-04: The EUDI Wallet shall provide a global user setting to disable the disclosure of stored EAAs via a mediating API that works as is specified in ISO/IEC 18013-ADD-API-01. When this setting is disabled, the EUDI Wallet shall not advertise or respond to the API-mediated presentation or issuance requests. — ISO/IEC 18013-ADD-API-05: EUDI Wallets shall verify in cross-device flows, using the mediating API, that the interacting device is in close physical proximity to the EUDI Wallet using a secure, direct, and user-mediated local communication channel, such as a short-range wireless communication technology to perform the physical proximity check. — NOTE : CTAP 2.3 enables to use BLE to perform the close physical proximity check and when implemented by both devices, also enables to transport the data between the devices via short-range transmission technologies. Performing both the physical proximity check and data transfer between the two devices using a local communication channel as enabled by CTAP 2.3, should be preferred by underlying operating systems, browsers, mediating APIs, or any other technical layer outside the control of the EUDI Wallet over the use of CTAP Hybrid tunnel services. (13) 6.2 Requirements on EUDI Wallet and RP support — OIDFVP-HAIP-SUPPORT-02: The EUDI Wallet shall meet the requirements specified in clause 6.5 of the present Annex. — OIDFVP-HAIP-SUPPORT-03: The EUDI Wallet should not support the redirects-based mechanism specified in clause 6.4 for cross-device presentation flows. — NOTE 3 : Using this mechanism is vulnerable to attacks, such as session fixation. Mitigating such attacks is up to relying parties. Implementing this mechanism should not trigger non-compliance. — OIDFVP-HAIP-SUPPORT-05: A Relying Party shall meet the requirements specified in clauses 6.5 of the present Annex. — NOTE 5 : void. (14) 6.3.1. General requirements — OIDFVP-HAIP-GEN-01: All the mandatory requirements specified in clauses 5, 5.3, 7, and 8 of HAIP [11] shall apply. — NOTE 1 : 'HAIP [11] Section 5' refers only to the requirements directly under the Section 5 heading. This does not include sections 5.1, 5.2, and 5.3. — OIDFVP-HAIP-GEN-03: If the present Annex modifies a requirement in OpenID4VC-HAIP [11], the modified requirement specified by the present Annex shall prevail. — NOTE 2 : This would allow, for instance, to convert in mandatory an optional requirement from OpenID4VC-HAIP [11] or to extend mandatory requirements. — OIDFVP-HAIP-GEN-04: When the format of the requested attestation complies with [10] Relying Parties and EUDI Wallets shall comply with the 'ISO mdocs' profile in [11] Section 6. — NOTE 3 : For clarity: the 'ISO mdocs profile' in HAIP implies that Relying Parties and EUDI Wallets must comply with the applicable requirements in [7] Annex B.2. — OIDFVP-HAIP-GEN-05: When the format of the requested attestation complies with [2], Relying Parties and EUDI Wallets shall comply with the 'IETF SD-JWT VCs' profile in [11] Section 6. — NOTE 4 : For clarity: the 'IETF SD-JWT VCs profile' implies that Relying Parties and EUDI Wallets must comply with the requirements in [7] Annex B.3, as well as with the requirements in [11] Section 6.1. (15) 6.3.2.1 General requirements — OIDFVP-HAIP-COMMON-REQ-01: void. (16) 6.3.2.2 Requirements for the Request Object — OIDFVP-HAIP-COMMON-REQ-RO-02: void — OIDFVP-HAIP-COMMON-REQ-RO-03: void — OIDFVP-HAIP-COMMON-REQ-RO-04: void — OIDFVP-HAIP-COMMON-REQ-RO-05: void — OIDFVP-HAIP-COMMON-REQ-RO-06: void. — OIDFVP-HAIP-COMMON-REQ-RO-07: void — OIDFVP-HAIP-COMMON-REQ-RO-08: void — OIDFVP-HAIP-COMMON-REQ-RO-09: void — OIDFVP-HAIP-COMMON-REQ-RO-10: void — OIDFVP-HAIP-COMMON-REQ-RO-11: void — OIDFVP-HAIP-COMMON-REQ-RO-12: void — Note 2 : void — OIDFVP-HAIP-COMMON-REQ-RO-13: One of the elements of the verifier_info parameter shall include the registration certificate. — OIDFVP-HAIP-COMMON-REQ-RO-23: The leaf certificate mentioned in OpenID4VP section 5.9.3 for use with the x509_hash Client Identifier Prefix shall be a RP access certificate as specified in ETSI TS 119 475 [14]. (17) 6.3.3 Authorization Response (EAAP response) profile — OIDFVP-HAIP-COMMON-RESP-01: void. (18) 6.4.1 General requirements — OIDFVP-HAIP-REDIRECTS-04: void. — NOTE : void. (19) 6.5.2 Additional requirements — OIDFVP-HAIP-ADD-API-01: The EUDI Wallet shall by default disclose the presence of all stored EAA types to the mediating API that works in accordance with clause 5.2 of [11], but it shall not disclose the attributes and their values in these EAAs. — OIDFVP-HAIP-ADD-API-04: If the EUDI Wallet supports a mediating API that works as is specified in OIDFVP-HAIP-ADD-API-01, it shall provide a global user setting to disable the disclosure of stored EAAs via the mediating API. When this setting is set to disabled disclosure, the EUDI Wallet should subsequently enable the User to select individual attestations to be disclosed to the mediating API. — OIDFVP-HAIP-ADD-API-05: EUDI Wallets shall verify, in cross-device flows, using the mediating API, that the interacting device is in close physical proximity to the EUDI Wallet using a secure, direct, and user-mediated local communication channel, such as a short-range wireless communication technology to perform the physical proximity check. — NOTE 5 : CTAP 2.3, enables to use BLE to perform the close physical proximity check and when implemented by both devices, also enables to transport the data between the devices via short-range transmission technologies. Performing both the physical proximity check and data transfer between the two devices using a local communication channel as enabled by CTAP 2.3, should be preferred by underlying operating systems, browsers, mediating APIs, or any other technical layer outside the control of the EUDI Wallet over the use of CTAP Hybrid tunnel services. (20) 6.5.3 Specific requirements when requesting ISO/IEC 18013-5 EAAP — OIDFVP-HAIP-ISO/IEC_18013_5_REQ-02: All requirements specified in this document applicable to Device Request and Device Response structures specified in ISO/IEC 18013-5 also apply when the EUDI Wallet receives a request for ISO/IEC mdoc presentation through an API-transmitted mechanism specified in clause C.1 of [16]. ’