Updated CIR info

[Saramandus]

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601735
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601730
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202601731

... and also - what does this mean, what changes?

[miluDIGG]

I refer to my comment here, instead of posting it again: #292 @Saramandus

[Sebastian-Elfors-IDnow]

Actually, these CIRs contain a lot of technical information that is of relevance to the WE BUILD WP4 architecture group. Below is a summary of the CIRs.

CIR (EU) 2026/1730

CIR (EU) 2026/1730 amends Implementing Regulation (EU) 2025/848 on the registration of wallet-relying parties in the EUDI Wallet ecosystem. It updates the information requirements, registrar processes, certificate issuance, certificate profiles and interoperability standards. It entered into force on 11 August 2026 and is directly applicable in all Member States.

Below is a summary of the changes.

1. New information linking intermediaries to relying parties
The registration data must now include, where applicable, an association between:

• The intermediary to which a wallet-relying-party access certificate has been issued; and
• The wallet-relying party acting through that intermediary and intending to rely on the wallet.
• This is intended to make intermediary relationships transparent and enable wallets to understand on whose behalf an intermediary is acting.

2. Changes to registrar verification
Registrars must verify the accuracy, validity, authenticity and integrity of the information specified in Annex I, points 1–6 and 11–16.

Information in Annex I, points 7–10 must instead be collected automatically and only for transparency purposes. Registrars must not subject this information to a pre-authorisation process. This separates core registration checks from information collected for transparency.

3. Faster, automated registration-certificate issuance
Member States must authorise at least one certificate authority to issue wallet-relying-party registration certificates.

Providers of those certificates must issue them:

• Automatically; and
• Without undue delay after registration.
• The purpose is to allow wallet units to validate that a relying party’s requested data falls within the relying party’s registered intended use.

4. Intended use must be embedded in certificates
Member States must ensure that wallet-relying-party registration certificates:

• State each relying party’s registered intended use.
• Include a harmonised general access policy.
• Inform wallet users that the relying party may request only the data specified in the certificate for the registered intended use.
• Enable wallet providers to warn users when a relying party requests data outside the scope of its registration certificate.
• Include a URL linking to the relying party’s privacy policy concerning the intended use.
• This makes the registered purpose and permitted data requests visible to both wallets and users.

5. Harmonised certificate profiles and policies
The regulation introduces updated and more harmonised technical requirements for wallet-relying-party certificates.

For relevant certificate profiles:

• The former reference to the normalised certificate policy under ETSI EN 319 411-1 is replaced by ETSI TS 119 411-8 V1.1.1 (2025-10).
• The certificate information must include a reference to the national wallet-relying-party register where the relying party is registered.
• Requirements for wallet-relying-party registration certificates are updated to ETSI TS 119 475 V1.2.1 (2026-03).
• Certificate policies and certificate practice statements must follow the updated Annex V requirements.

6. Stronger interoperability between national registers
The amendments are designed to support a common format and API for wallet-relying-party registration information. This should make it easier for national registers and wallet implementations in different Member States to exchange and interpret registration data consistently.

CIR (EU) 2026/1731

CIR (EU) 2026/1731 amends CIRs (EU) 2024/2977, (EU) 2024/2979, (EU) 2024/2980 and (EU) 2024/2982 as regards applicable standards and specifications. These changes are significant, and specify several technical details.

Below is a summary of the changes.

1. Stronger protection for portrait data

The regulation introduces specific safeguards for the wallet user’s portrait, which is treated as biometric data:

• Wallets must warn users that a request involves sharing biometric data.
• Disclosure of the portrait must require the user’s explicit and specific confirmation.
• Silence or pre-ticked boxes do not constitute confirmation.
• Relying parties may retain the portrait only where necessary for identification or authentication, or where required by EU or national law.
• Transfers of the portrait to third countries or international organisations are restricted to cases permitted under EU data-protection law.
• The portrait must be selectively disclosable like other identity attributes.
• The portrait becomes part of the mandatory person-identification dataset only from 11 August 2028. Member States may also allow users to opt out of including it.

2. Updated person-identification data and encoding rules

The regulation replaces the technical annex for person-identification data. It specifies:

• Mandatory natural-person data such as surname, given name, date and place of birth, nationality and (subject to the 2028 timing rules) the portrait.
• Optional attributes including address, administrative number, sex, email address and mobile number.
• Mandatory and optional legal-person attributes, including legal name and possible identifiers such as VAT, LEI, EORI and national company identifiers.
• Metadata such as issuing authority, issuing country, expiry date, document number and issuance jurisdiction.
• Detailed encoding requirements for both:
• ISO/IEC mdoc, using the namespace eu.europa.ec.eudi.pid.1; and
• SD-JWT VC, using the base type urn:eudi:pid:1.
• The amendments also reinforce selective disclosure and require the identity data to be bound to a public key associated with a private key stored in the wallet’s secure cryptographic device.

3. New cryptographic requirements
Wallet providers must use the cryptographic mechanisms referenced in ENISA’s “Agreed Cryptographic Mechanisms” publication.

4. New wallet unit attestation (WUA) requirements
The regulation Annex IB also introduces detailed requirements for wallet unit attestations (WUA):

• Wallet instance attestations and key attestations are based on JWT structures.
• They use compact JAdES baseline B signatures or seals.
• The specifications build on the OpenID for Verifiable Credential Issuance framework.
• Wallet providers must verify the integrity of wallet instances before issuing attestations.
• During issuance, wallet units must present the relevant wallet-instance attestation together with proof of possession.
• The attestation’s validity period must be closely linked to the integrity verification, with the relevant time difference being less than 24 hours.

This specification is to a large extent based on EC TS03. An ETSI standardized version of WUA is in the works at ETSI ESI.

5. Mandatory EU Digital Identity Wallet Trust Mark
A new Article 14a establishes the operational requirements for the EU Digital Identity Wallet Trust Mark:

• Wallet units must display the official Trust Mark.
• Users must be able to access information verifying the wallet solution’s certification status.
• Wallets must use Commission-provided verification URLs and Trust Mark data.
• The regulation specifies the official blue and yellow colours, as well as permitted black-and-white and negative versions.
• The minimum size is 64 \times 85 pixels at 150 dpi.
• The Trust Mark must clearly relate to the relevant wallet unit.
• It must no longer be displayed if the wallet unit’s attestation has been revoked.
• This gives users and relying parties a standard, recognisable way to distinguish certified wallets.

6. Revised issuance and presentation protocols
The regulation updates the protocols and interfaces for issuing and presenting identity data and attestations:

• Wallets must support revised technical specifications for issuance. More specifically, there are technical details that amend ETSI TS 119 472-3, which is the ETSI standardized profile of OID4VCI.
• Wallets must support revised technical specifications for presentation. More specifically, there are technical details that amend ETSI TS 119 472-2, which is the ETSI standardized profile of OID4VP.
• Wallet-relying parties must be authenticated and their requests validated.
• Wallets must validate wallet-relying-party access certificates and registration certificates.
• Information contained in access certificates must be shown to users.
• Requested attributes must not be presented until:
• embedded disclosure policies have been processed; and
• the user has approved the presentation, in whole or in part.
• Signature-creation applications may be integrated into the wallet or operate externally, but must support the specified API.
• Online cross-device flows should prefer local communication enabled by CTAP 2.3 over CTAP Hybrid tunnel services where applicable.
• The regulation also reflects the evolution of the European Digital Identity Wallet Architecture and Reference Framework and updates the associated standards and annexes.

CIR (EU) 2026/1735

CIR (EU) 2026/1735 amends Implementing Regulation (EU) 2025/1569 on qualified electronic attestations of attributes (QEAA) and electronic attestations of attributes issued by or on behalf of a public-sector body responsible for an authentic source. It updates the applicable standards, issuance and revocation requirements, and verification mechanisms. The regulation generally applies from 11 August 2026. The new rules on verification results signed or sealed by authentic sources apply from 1 January 2027.

Below is a summary of the changes.

1. Attestation schemes become part of conformity assessment
Providers issuing attestations under schemes listed in the catalogue of schemes for attestation of attributes must comply with the requirements of the relevant scheme.

Their policies and procedures for meeting those scheme requirements must form part of the provider’s conformity assessment. This makes the catalogue schemes more directly relevant to audit and certification activities.

2. Revised revocation requirements
The regulation removes the previous general requirement in Article 4(1) and replaces the revocation rules for attestations with a validity period of more than 24 hours.

Providers must revoke an attestation at least in the following cases:

• At the request of the person to whom it was issued or, where applicable, the subject of the attestation.
• When the provider becomes aware of a compromise affecting the security or trustworthiness of the attestation.
• In other circumstances required by EU or national law.
• Revocation techniques and management methods must be privacy-preserving and designed to limit linkability and traceability. The technical revocation methods now point to the requirements in Annex II of Regulation 2024/2979.

3. New authentication and validation requirements for wallet interactions
The updated standards require an electronic-attestation service provider to:

• Authenticate to the European Digital Identity Wallet instance using mutual authentication and a valid access certificate.
• Validate the wallet unit and determine whether the wallet instance has been revoked.
• The previous generic provisions on verification of attributes against authentic sources and certain EUDI Wallet-specific provisions in ETSI TS 119 471 are excluded or replaced by more specific requirements.

4. Verification results must be signed or sealed
When an attribute is verified against an authentic source, the verification result must:

• State whether the attribute was verified.
• Identify the public-sector body responsible for the authentic source, or a nationally designated intermediary.
• Be signed or sealed by that body or intermediary.

The signature or seal must be at least:

• An advanced electronic signature based on a qualified certificate; or
• An advanced electronic seal based on a qualified certificate.

This requirement applies from 1 January 2027, giving authentic-source operators and intermediaries time to implement the necessary signing or sealing processes.

5. New verification-mechanism specifications
The verification mechanism must comply with one or both of the following:

• ETSI TS 119 478 V1.1.1 (2026-01), clause 6.1.1; or
• ETSI TS 119 478 V1.1.1 (2026-01), clause 6.2.3.

The regulation adds specific adaptations for handling results such as:

• Match
• MatchWithVariation

Where applicable, the response may include:

• The attribute value received from the request; or
• The corresponding value held by the authentic source.
• Similar rules apply to fragments of attributes. This establishes a more precise interoperability model for cases where the requested and source-held values match exactly or differ in an accepted way.

6. Updated trust-service standards
The revised Annex I updates the reference standards for electronic-attestation trust services. Notable additions and references include:

• ETSI EN 319 401 V3.2.1 (2026-01) for general policy requirements for trust service providers.
• ENISA’s Agreed Cryptographic Mechanisms.
• FIPS PUB 140-3, including Level 3 requirements.
• The EU Common Criteria cybersecurity certification scheme, or EUCC.
• ISO/IEC 15408:2022, Parts 1–5.
• Commission Implementing Regulations 2024/482 and 2024/3144 concerning EUCC.

The regulation also adds a definition of a secure cryptographic device: a device that holds a private key, protects it against compromise and performs signing or decryption functions for the user.

7. Stronger cryptographic-device requirements
Providers must maintain appropriate security controls for cryptographic keys, algorithms and devices throughout their lifecycle, including consideration of cryptographic agility.

They must use cryptographic techniques compliant with ENISA’s agreed mechanisms.

For signing or sealing electronic attestations, the relevant secure cryptographic device must be a qualified signature or seal creation device. Other signing or sealing operations supporting the attestation service must use a trustworthy, certified system meeting one of the recognised certification routes:

• Common Criteria or ISO/IEC 15408 at EAL 4 or higher.
• The EUCC scheme at EAL 4 or higher.
• FIPS 140-2 Level 3 for existing certified systems until 31 August 2027.
• FIPS 140-3 Level 3 until 31 December 2030.
• Where an EUCC-certified device is used, it must be configured and operated in accordance with its certification.

8. New operational, change-notification and termination requirements
The updated rules require providers to document their revocation mechanism in the electronic-attestation practice statement.

Providers must also notify their supervisory body of:

• Changes to the provision of the electronic-attestation trust service at least one month before implementing the change.
• Planned cessation of the service at least three months before termination.
• Termination plans must comply with the relevant implementing acts adopted under eIDAS Article 24(5).

9. Monitoring and incident-management clarification
Monitoring activities must take account of the sensitivity of the information collected or analysed. This reinforces the need for proportionate monitoring and handling of potentially sensitive identity and attribute data.