Skip to content

Implementation Profiles for the Trust Framework

Version 0.1 (Draft)

Version Date Description
0.1 2026-04-19 First release

Authors:

  • Gianmario Cortese, Namirial S.p.A.
  • Henry Faure-Geors, Keynectis
  • Francesco Antonio Marino, Istituto Poligrafico e Zecca dello Stato S.p.A.
  • Andrea Moro, Fondazione Bruno Kessler
  • Marco Pernpruner, Fondazione Bruno Kessler
  • Nuno Ponte, Multicert
  • Andreea Prian, iDAKTO
  • Giada Sciarretta, Fondazione Bruno Kessler
  • Hoang Van Hoan, Keynectis
  • Maroš Zelenák, ARICOMA Digital S.R.O

Reviewers:

  • Dominik František Bučík, ARICOMA Digital S.R.O
  • Guillaume Hébert, Keynectis
  • Angel Palomares Perez, Atos IT Solutions
  • Leonardo Pio Palumbo, Istituto Poligrafico e Zecca dello Stato S.p.A.
  • Leone Riello, Infocert S.p.A.
  • Michal Šťava, ARICOMA Digital S.R.O
  • Nikolaos Triantafyllou, University of the Aegean

Feedback:

1. Introduction

This specification, Implementation Profiles for the Trust Framework, defines the conceptual and architectural requirements for ensuring trust in the APTITUDE piloted environments. At this stage, the specification focuses on articulating the necessary trust architecture, defining the essential trust artifacts, and outlining the high-level evaluation processes. By setting these principles, this document serves as a shared reference to guide subsequent development, ensuring that all implementation efforts remain aligned with the project's objectives for security, privacy, and interoperability.

2. Scope

This specification defines the trust framework profiles for the APTITUDE Large Scale Pilot. Its scope is limited to establishing the essential mechanisms for trust in interactions between Wallet Units and Wallet-Relying Parties. The scope of this document is organized as follows:

Out of Scope

The current version of these specifications does not provide details on:

  • Low-level Implementation: These will be covered in subsequent versions of the specifications.

  • Trust Management Process: While this document defines revocation mechanisms, the broader Trust Management Process (covering full lifecycle management) is currently missing and will be addressed in future versions.

  • Registration, Notification, and Publication Processes: The administrative and regulatory processes governing the registration, notification, and publication of Trust Entities between Member States and the European Commission are excluded from this scope.

3. Normative Language

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.

4. Trust Architecture

This section describes the trust-related processes (i.e., Wallet-Relying Party registration, Provider notification and publication in Trusted List, and trust evaluation) by detailing the entities involved, high level flows and their relationships.

The main entities involved in the EUDI Wallet ecosystem are:

graph TD

    WP["Wallet Provider (WP)"]
    User((User))
    WU["Wallet Unit <br/> [WIA]"]

   subgraph WRP["Wallet Relying Parties (WRPs) [WRPAC, WRPRC]"]
        direction LR
        PIDP["PID Providers"]
        subgraph AP["Attestation Providers"]
            QEAAP["QEAA <br/>Providers"]
            PubP["Pub-EAA <br/>Providers"]
            EAAP["non-qualified <br/>EAA Providers"]
        end
        RP["Relying Parties (RPs)"]
        RPI["RP <br/>Intermediaries"]
    end

    %% Skeleton
    PIDP ~~~ RPI
    RPI ~~~ AP
    RP ~~~ RPI

    %% Style
    classDef WRP_entities fill:#ffefd5, stroke:#ffdab9
    style WRP fill:#ffff,stroke:#ffdab9,stroke-width:2px,rx:20,ry:20
    style AP fill:#ffff,stroke:#ffdab9,stroke-width:2px,rx:20,ry:20

    class QEAAP,PIDP,PubP,EAAP,RP,RPI WRP_entities;


    %% Arrows
    WP ---|Provides Wallet Solution| User 
    User ---|Controls/activates| WU
    WU ---|"Interacts (issue/present <br/>PID/Attestation)"| WRP

To trust the interactions between these entities, the following trust evaluation processes are needed:

While these trust evaluation processes and its artifacts (i.e., Register and its common APIs, WRPAC, WRPRC, LoTE, EUMS TL and Embedded Disclosure Policies) will be further detailed in the Trust Evaluation Process and Trust Artifacts sections respectively, the processes to obtain and manage these artifacts are brieftly detailed below:

  • WRP Registration Process: to rely on Wallet Units for the purpose of providing a service, WRPs register at a Registrar in the Member State where they are established. Based on the type of service registered, registration includes: the attributes that the RP intends to request from Wallet Units or the Attestation type(s) the Attestation Provider wants to issue to Wallet Units. The following steps are in common to all WRPs: 1. Identity and Catalogue Verification: Registrar verifies the identity of WRP according to requirements in [ETSI TS 119 461]. The specific identity proofing level may vary based on entity type and applicable regulatory framework (e.g. QTSP requirements or MS national legislation) and it is out of scope of the piloting. In this process, Registrar may use the Catalogue of Attributes and Catalogue of Schemes for the Attestation of Attributes managed by the Commission for evaluating the registration request. 2. Registration Record Creation: Registrar creates registration record in national Register and made available online both in human-readable and machine-readable format. Record contains at least:

    graph TD

WRP["Wallet Relying Parties <br/> (WRPs)"]

subgraph MS["Member State (MS)"]
    MSReg[MS <br/>Registrar]
    ProvAC[Provider of <br/>WRPAC]
    ProvRC[Provider of <br/>WRPRC]
    Reg[/"Register(s)"/]
    MSReg---|"Publishes data"| Reg
end

subgraph EC["European Commission (EC)"]
    Cat[/Catalogues/]
end

%% Style
style WRP fill:#ffefd5, stroke:#ffdab9,stroke-width:2px,rx:20,ry:20
style MS fill:#ffff,stroke:#2f4f4f,stroke-width:2px,rx:20,ry:20
style EC fill:#ffff,stroke:#abb2bf,stroke-width:2px,rx:20,ry:20
classDef blue fill:#e8f0fe,stroke:#abb2bf
classDef green fill:#8fbc8f,stroke:#2f4f4f

class QEAAP,PIDP,PubP,EAAP,RP,RPI WRP_entities;
class ECLoTE,ECNS,Cat,LoTEs blue;
class MSReg,ProvAC,ProvRC,TLs,Reg green;

%% Arrows
WRP ---|"Request registration"| MSReg
ProvAC ---|"Issues WRPAC"| WRP
ProvRC-. "Issues WRPRC" .-> WRP
MSReg ---|"Checks Catalogues"| Cat

  • Notification Process: MS sends data related to the registered entity to the EC. As result:

    graph LR

subgraph MS["Member State (MS)"]
    MSTLP["MS  <br/>Trusted List Provider  <br/>(TLP)"]
    TLs[/TLs/]
    MSTLP ---|"publish"| TLs
end

subgraph EC["European Commission (EC)"]
    ECLoTE[EC LoTE <br/>Provider]
    LoTE1[/WP <br/>LoTE/]
    LoTE2[/PID Providers <br/>LoTE/]
    LoTE3[/Providers of <br/>WRPAC LoTE/]
    LoTE4[/Providers of <br/>WRPRC LoTE/]
    LoTE5[/MS Registrar <br/>LoTE/]
    LoTE6[/Pub-EAA Providers <br/>LoTE/]
    LOTL[/LOTL/]
    ECLoTE ---|"publish"| LoTE1
    ECLoTE ---|"publish"| LoTE2
    ECLoTE ---|"publish"| LoTE3
    ECLoTE ---|"publish"| LoTE4
    ECLoTE ---|"publish"| LoTE5
    ECLoTE ---|"publish"| LoTE6
    ECLoTE ---|"publish"| LOTL
end

LoTE1 ~~~ LoTE2
LoTE3 ~~~ LoTE4
LoTE5 ~~~ LoTE6

%% Style
style EC fill:#ffff,stroke:#abb2bf,stroke-width:2px,rx:20,ry:20
style MS fill:#ffff,stroke:#2f4f4f,stroke-width:2px,rx:20,ry:20
classDef blue fill:#e8f0fe,stroke:#abb2bf
classDef green fill:#8fbc8f,stroke:#2f4f4f

class ECLoTE,ECNS,LoTE1,LoTE2,LoTE3,LoTE4,LoTE5,LoTE6,LOTL blue;
class MSTLP,TLs green;

%% Arrows
EC ---|"Notification Process <br/>(Trust Anchor or <br/>URL of the EUMS TL)"| MS

The following figure add these two processes to the previous architecture.

graph TD

    WP["Wallet Provider (WP)"]
    User((User))
    WU["Wallet Unit <br/> [WIA]"]

   subgraph WRP["Wallet Relying Parties (WRPs) <br/>[WRPAC, WRPRC]"]
        direction LR
        PIDP["PID Providers"]
        subgraph AP["Attestation Providers"]
            QEAAP["QEAA <br/>Providers"]
            PubP["Pub-EAA <br/>Providers"]
            EAAP["non-qualified <br/>EAA Providers"]
        end
        RP["Relying Parties (RPs)"]
        RPI["RP <br/>Intermediaries"]
    end

    subgraph MS["Member State (MS)"]
        MSReg[MS <br/>Registrar]
        ProvAC[Provider of <br/>WRPAC]
        ProvRC[Provider of <br/>WRPRC]
        MSTLP["MS  <br/>Trusted List Provider  <br/>(TLP)"]
        TLs[/EUMS TLs/]
        Reg[/"Register(s)"/]
        MSTLP --- TLs
        MSReg--- Reg
    end

    subgraph EC["European Commission (EC)"]
        ECLoTE[EC LoTE <br/>Provider]
        Cat[/Catalogues/]
        LoTEs[/LOTLs or LoTEs/]
        ECLoTE --- LoTEs
    end



    %% Skeleton
    PIDP ~~~ RPI
    RPI ~~~ AP
    RP ~~~ RPI
    ProvAC ~~~ ProvRC


    %% Style
    classDef WRP_entities fill:#ffefd5, stroke:#ffdab9
    style WRP fill:#ffff,stroke:#ffdab9,stroke-width:2px,rx:20,ry:20
    style AP fill:#ffff,stroke:#ffdab9,stroke-width:2px,rx:20,ry:20
    style EC fill:#ffff,stroke:#abb2bf,stroke-width:2px,rx:20,ry:20
    style MS fill:#ffff,stroke:#2f4f4f,stroke-width:2px,rx:20,ry:20
    classDef blue fill:#e8f0fe,stroke:#abb2bf
    classDef green fill:#8fbc8f,stroke:#2f4f4f

    class QEAAP,PIDP,PubP,EAAP,RP,RPI WRP_entities;
    class ECLoTE,ECNS,Cat,LoTEs blue;
    class MSTLP,MSReg,ProvAC,ProvRC,TLs,Reg green;


    %% Arrows
    WP ---|Provides Wallet Solution| User 
    User ---|Controls/activates| WU
    WU ---|"Interacts (issue/present <br/>PID/Attestation)"| WRP 
    WRP ---|"WRP Registration Process"| MS  
    EC ---|"Notification Process <br/> through the EC Notification System"| MS

5. Trust Artifacts

Register

This section specifies requirements for the Registrar of Wallet-Relying Parties (WRPs) and the national Register of WRPs (the registry service) in the context of eIDAS2 and the EUDI Wallet ecosystem.

Formally, a Registrar is the designated body that:

  • manages the WRP registration lifecycle (onboarding, update, suspension, cancellation),
  • ensures the integrity and publication of registration information,
  • ensures interoperability by exposing WRP registration data via a national website and a single common REST API.

The national Register of WRPs is the publicly accessible system (dataset + API) that provides signed/sealed registration statements about WRPs and their authorisations/declared usage.

Note

The national Register of WRPs is a single logical register. For scalability and resilience, a Member State MAY deploy multiple technical instances provided they expose a single coherent common REST API and return signed statements as required.

Additionally, sectorial registers may exist internally, but the decision regarding issuance of WRPAC is solely based on whether the WRP has been registered with an active status in the national Register.

References

The list below enumerates all the applicable standards and specifications that have been used to populate the table below:

  • CIR 2025/848 on WRP registration and Registers.
  • CIR 2025/848-Amendment. This draft slightly modifies Annexes I-V of [CIR 2025/848] and introduces Annex VI for common API and data schema for Register of WRPs.
  • ETSI TS 119 475 on WRP attributes, entitlement URIs, RP authorisation decision support.
  • RFC 7515
  • RFC 7519
  • RFC 8392
  • TS05 on common formats and API for WRP registration information.
  • TS06 on common set of WRP information to be registered.

Requirements

Register Requirements
ID Requirement Reference
REGISTER-PUB-01 Each Member State SHALL establish and maintain at least one national Register of WRPs. [CIR 2025/848], Article 3(1)
REGISTER-PUB-02 The Register SHALL include at least the information set out in Annex I of [CIR 2025/848]. [CIR 2025/848], Article 3(2)
REGISTER-PUB-03 Member States SHALL designate at least one Registrar to manage and operate at least one national Register. [CIR 2025/848], Article 3(3)
REGISTER-PUB-04 Member States SHALL make Annex I information publicly available online in human-readable and machine-processable form. [CIR 2025/848], Article 3(4)
REGISTER-PUB-05 Annex I information included in the Register (as for REGISTER-PUB-02) SHALL be available through a national website and a single common API, and SHALL be electronically signed/sealed by/on behalf of the Registrar. [CIR 2025/848], Article 3(5)
REGISTER-API-01 The single common API SHALL be a REST API supporting JSON, and signed according to IETF RFC 7515. [CIR 2025/848], Annex II §2(1)(a)
REGISTER-API-02 The API SHALL allow any requestor, without prior authentication, to search and request complete lists, allowing partial matches on defined parameters. [CIR 2025/848], Annex II §2(1)(b)
REGISTER-API-03 Replies to request that match at least one WRP SHALL include statements covering Annex I information [CIR 2025/848], current/historic WRPACs and WRPRCs, excluding Annex I point 4 information. [CIR 2025/848], Annex II §2(1)(c)
REGISTER-API-04 The API SHALL be published as OpenAPI v3 with documentation enabling interoperability across the Union. [CIR 2025/848], Annex II §2(1)(d)
REGISTER-API-05 The API SHALL provide security-by-default and by-design to ensure availability and integrity. [CIR 2025/848], Annex II §2(1)(e)
REGISTER-API-06 Statements referred to in REGISTER-API-03 SHALL be electronically signed/sealed JSON files as for IETF RFC 7515. [CIR 2025/848], Annex II §2(2)

Note

The set of WRP information listed in Annex I of [CIR 2025/848] and mentioned in REGISTER-PUB-05 and REGISTER-API-03 will be described in the Register Data Schema section.

Registrar Requirements
ID Requirement Reference
REGISTRAR-REG-01 Registrars SHALL establish easy-to-use electronic, and where possible automated, registration processes. [CIR 2025/848], Article 6(1)
REGISTRAR-REG-02 WRPs SHALL provide at least Annex I information to national registers. [CIR 2025/848], Article 5(1)
REGISTRAR-REG-03 WRPs SHALL ensure information is accurate and SHALL update without undue delay. [CIR 2025/848], Article 5(2)–(3)
REGISTRAR-REG-04 Where possible, Registrars SHALL verify (automated) accuracy/validity, power of attorney (if applicable), entitlement type(s), and absence of existing registration in another national Register. [CIR 2025/848], Article 6(3)
REGISTRAR-REG-05 Registrars SHALL verify against supporting documentation or appropriate authentic sources/official records. [CIR 2025/848], Article 6(4)
REGISTRAR-REG-06 Verification of entitlements SHALL be carried out according to Annex III of [CIR 2025/848]. [CIR 2025/848], Article 6(5)
REGISTRAR-REG-07 If Registrar cannot verify according to Article 6(3)–(5) of [CIR 2025/848], Registrar SHALL reject the registration. [CIR 2025/848], Article 6(6)
REGISTRAR-GOV-01 Registrars SHALL suspend/cancel a registration of a WRP where requested by a supervisory body (per eIDAS reference). [CIR 2025/848], Article 9(1)
REGISTRAR-GOV-02 Registrars MAY suspend/cancel a registration of a WRP if info inaccurate/outdated/misleading, non-compliance, excessive attribute requests, breach of law. [CIR 2025/848], Article 9(2)
REGISTRAR-GOV-03 Registrars SHALL suspend/cancel a registration of a WRP if requested by the WRP itself. [CIR 2025/848], Article 9(3)
REGISTRAR-GOV-04 Registrar SHALL conduct proportionality assessment before suspension/cancellation under Article 9(2). [CIR 2025/848], Article 9(4)
REGISTRAR-GOV-05 Registrar SHALL notify WRP and relevant Providers of WRPAC and WRPRC without undue delay and not later than 24 hours. [CIR 2025/848], Article 9(5)
REGISTRAR-GOV-06 Providers of WRPAC and WRPRC SHALL revoke affected certificates without undue delay after notification (where applicable). [CIR 2025/848], Article 9(6)
REGISTRAR-GOV-07 Registrars SHALL keep records (Annex I + issuance data + changes) for 10 years. [CIR 2025/848], Article 10
Provider of WRPAC and WRPRC and Register Interactions Requirements
ID Requirement Reference
PROVIDER-WRPAC-01 Providers of WRPAC SHALL verify at issuance time that the WRP is included with valid registration status in the national Register and certificate info is consistent with Register info. [CIR 2025/848], Annex IV §3(c)
PROVIDER-WRPAC-02 Providers of WRPAC SHALL continuously monitor changes in the national Register and revoke when changes require (especially suspension/cancellation). [CIR 2025/848], Annex IV §3(e)
PROVIDER-WRPAC-03 Providers of WRPAC SHALL publish revocation status timely and in any event within 24 hours after receipt of revocation request. [CIR 2025/848], Annex IV §3(h)
PROVIDER-WRPRC-01 Where a Member State authorises WRPRCs, it SHALL ensure each intended use is expressed in the WRPRC and that WRPRCs include a privacy policy URL and a general access policy. [CIR 2025/848], Article 8(2)(b)–(c) and (g), Article 8(3)
PROVIDER-WRPRC-02 Providers of WRPRC SHALL verify at issuance time Register status, consistency with Register info, and validity of the WRPAC (when relevant). [CIR 2025/848], Annex V §3(c)
PROVIDER-WRPRC-03 Providers of WRPRC SHALL monitor Register changes, reissue/revoke when changes require. [CIR 2025/848], Annex V §3(d)
PROVIDER-WRPRC-04 Data exchange format for WRPRC SHALL be signed JWTs (RFC 7519) and CWTs (RFC 8392), using an Advanced Electronic Signature (AdES) with the B-B profile (JAdES per [ETSI TS 119 182-1] for JWT, COSE for CWT). [CIR 2025/848], Annex V §4; [ETSI TS 119 475] §4.4

Register Data Schema

This section defines the data schema for each WRP registered in the national Register of WRPs. The values are extracted from the Annex VI of the [CIR 2025/848-Amendment].

Address field publication rule

The draft Annex VI text says the published API payload excludes WalletRelyingParty.physicalAddress, while Table 1 uses the attribute name postalAddress. This document uses postalAddress as the schema field name and applies the publication rule to that field (i.e., do not publish it in API statements).

Parameter Type Presence Description
legalPerson LegalPerson REQUIRED if legal person Specific attributes of a legal person. It SHALL be present if the legal entity is a legal person.
naturalPerson NaturalPerson REQUIRED if natural person Specific attributes of a natural person. It SHALL be present if the legal entity is a natural person.
identifier Identifier[] REQUIRED One or more identifiers from official records.
postalAddress string[] OPTIONAL Postal address(es) of the legal entity (registration view only; excluded from published API statements). Note: [ETSI TS 119 475] B.2.2 defines this as [1..1] string; Draft Annex VI Table 1 uses an array. This document follows Draft Annex VI.
country string REQUIRED ISO 3166-1 alpha-2 country code, or "EU" for providers operating in the Union.
email string[] OPTIONAL Contact email address(es) (RFC 5322 format).
phone string[] OPTIONAL Contact phone number(s), international form with + prefix.
infoURI string[] OPTIONAL Web page URI(s) for information about the entity.
providerType string REQUIRED Provider subtype. For WRP records, typically WalletRelyingParty.
policy Policy[] REQUIRED Policy/terms/privacy/registration policy URL(s) with policy type URI.
x5c string[] OPTIONAL X.509 certificate chain(s) for provider services (JWS x5c-style chains; supports rollover).
tradeName string OPTIONAL User-facing trade/service name recognisable to users.
supportURI string[] REQUIRED Support/helpdesk URI(s) for the service.
srvDescription MultiLangString[][] REQUIRED Array of service descriptions, each being an array of localised strings (one inner array per service).
intendedUse IntendedUse[] REQUIRED if the entity is not an intermediary Intended-use definitions and requested attestation data. Not required if registering only as a designated intermediary.
isPSB boolean REQUIRED Whether the WRP is a public sector body (explicitly present; false if not PSB).
entitlement string[] REQUIRED Entitlement URI(s) (see note below).
providesAttestations Credential[] REQUIRED if PID/Attestation Provider Attestation types the WRP intends to issue to wallet units. It SHALL be present if any entitlement is QEAA_Provider, Non_Q_EAA_Provider, PUB_EAA_Provider, or PID_Provider.
supervisoryAuthority LegalEntity REQUIRED Competent supervisory authority (Art. 46a eIDAS) including contact information.
registryURI string REQUIRED URI of the API of the national register of WRPs.
usesIntermediary WalletRelyingParty[] OPTIONAL If present, indicates designated intermediary(ies). Only the subset {identifier, tradeName, registryURI} is needed for each intermediary reference.
isIntermediary boolean REQUIRED Whether the registered entity is a designated intermediary. SHALL be false if usesIntermediary is present.

Note

Mapping between CIR entitlement label and [ETSI TS 119 475] (Annex A.2) normative URI:

CIR entitlement label Normative URI
Service_Provider https://uri.etsi.org/19475/Entitlement/Service_Provider
QEAA_Provider https://uri.etsi.org/19475/Entitlement/QEAA_Provider
Non_Q_EAA_Provider https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider
PUB_EAA_Provider https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider
PID_Provider https://uri.etsi.org/19475/Entitlement/PID_Provider
QCert_for_ESeal_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESeal_Provider
QCert_for_ESig_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESig_Provider
rQSigCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSigCDs_Provider
rQSealCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSealCDs_Provider
ESig_ESeal_Creation_Provider https://uri.etsi.org/19475/Entitlement/ESig_ESeal_Creation_Provider

[ETSI TS 119 475] v1.2.1 Annex A.3 defines additional sub-entitlement URIs for specific service provider roles. For example, Payment Service Provider sub-entitlements include:

Sub-entitlement URI
Account Servicing PSP https://uri.etsi.org/19475/SubEntitlement/psp/psp-as
Payment Initiation Service Provider https://uri.etsi.org/19475/SubEntitlement/psp/psp-pi
Account Information Service Provider https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai
PSP issuing card-based payment instruments https://uri.etsi.org/19475/SubEntitlement/psp/psp-ic
Unspecified PSP https://uri.etsi.org/19475/SubEntitlement/psp/unspecified

Future editions may define additional sub-entitlements at national or EU level.

Identifier
Parameter Type Presence Description
identifier string REQUIRED Identifier value of the LegalEntity.
type string REQUIRED Identifier scheme/type URI (see normative URIs below).

Normative identifier type URIs defined in [ETSI TS 119 475]:

Label Normative URI Description
EORI-No http://data.europa.eu/eudi/id/EORI-No Economic Operator Registration and Identification Number according to (EU) No 1352/2013.
LEI http://data.europa.eu/eudi/id/LEI Legal Entity Identifier according to (EU) 2022/1860; [ISO 17442-1].
EUID http://data.europa.eu/eudi/id/EUID European Unique Identifier according to (EU) 2020/2244; (EU) 2021/1042.
VATIN http://data.europa.eu/eudi/id/VATIN Value Added Tax Identification Number according to Council Directive 2006/112/EC.
TIN http://data.europa.eu/eudi/id/TIN Taxpayer Identification Number.
Excise http://data.europa.eu/eudi/id/Excise Excise Number according to Art. 2 (12) of the Council Regulation (EC) No 389/2012.

Note

Additional type identifiers may be defined at national or EU level.

MultiLangString
Parameter Type Presence Description
lang string REQUIRED Language tag (e.g., en, fr).
content string REQUIRED Language-specific content.
IntendedUse
Parameter Type Presence Description
intendedUseIdentifier string REQUIRED Registry-level unique identifier for the intended use.
purpose MultiLangString[] REQUIRED Description of intended use of the data to request from wallet units.
privacyPolicy Policy[] REQUIRED Privacy policy URL(s) for the intended use.
credential Credential[] REQUIRED Machine-readable list of requested data (attestations/attributes).
createdAt string REQUIRED Validity start date of the intended use in accordance with ISO86011 YYYY-MM-DD format.
revokedAt string OPTIONAL End date for the validity of the intended use in accordance with ISO86011 YYYY-MM-DD format.
Policy
Parameter Type Presence Description
type string REQUIRED Policy type URI (RFC 3986). See defined policy type URIs below.
policyURI string REQUIRED URL where the policy is published.

Defined policy type URIs:

Policy type URI Reference
Privacy policy http://data.europa.eu/eudi/policy/privacy-policy [ETSI TS 119 475] B.2.8; [CIR 2025/848] Article 8(2)(g)
Terms and conditions http://data.europa.eu/eudi/policy/terms-and-conditions [CIR 2025/848-Amendment], Annex VI Table 7
Privacy statement (intended use) http://data.europa.eu/eudi/policy/privacy-statement [CIR 2025/848-Amendment], Annex VI Table 7

Note

Additional policy type URIs may be defined at national or EU level.

Credential
Parameter Type Presence Description
format string REQUIRED Credential format identifier (e.g., dc+sd-jwt, mso_mdoc).
meta object REQUIRED Additional grouping/type metadata defined per credential format (e.g., {"vct": "..."} for dc+sd-jwt, {"doctype_value": "..."} for mso_mdoc). See OpenID4VP §6.1.
claim Claim[] OPTIONAL Requested claim paths and allowed values (if constrained).
Claim
Parameter Type Presence Description
path array REQUIRED Non-empty path array of strings / null / non-negative integers (OpenID4VP-style path pointer segments).
values array OPTIONAL Optional allowed values; elements may be string, integer, or boolean.
LegalEntity (for supervisoryAuthority)
Parameter Type Presence Description
legalPerson LegalPerson OPTIONAL Present when the authority is a legal person.
naturalPerson NaturalPerson OPTIONAL Present when the authority is a natural person.
identifier Identifier[] OPTIONAL Identifier(s) of the authority.
postalAddress string[] OPTIONAL Postal address(es) of the authority.
country string REQUIRED Country code (or EU where applicable).
email string[] OPTIONAL Email address(es) of the authority.
phone string[] OPTIONAL Phone number(s) of the authority.
infoURI string[] OPTIONAL Information URI(s) of the authority.
LegalPerson
Parameter Type Presence Description
legalName string[] REQUIRED Legal name(s) as in official records.
establishedBylaw Law[] REQUIRED if PSBs responsible for authentic sources Legal basis for establishment. It SHALL be present for PSBs responsible for authentic sources; present for other PSBs where applicable.
NaturalPerson
Parameter Type Presence Description
givenName string REQUIRED Current first name(s), including middle names where applicable.
familyName string REQUIRED Current surname(s).
dateOfBirth string OPTIONAL Date of birth (where present in official records).
placeOfBirth string OPTIONAL Place of birth (where present in official records).
Law
Parameter Type Presence Description
lang string REQUIRED Two-letter language code (ISO 639-1 style).
legalBasis string REQUIRED Legal basis text establishing the legal person (or requiring/recommending access to a claim).
Non-normative example: WRP object for a Relying Party

A bank registered as a service provider (requesting PID for KYC).

{
  "legalPerson": {
    "legalName": ["ExampleBank S.A."]
  },
  "identifier": [
    {
      "type": "http://data.europa.eu/eudi/id/EUID",
      "identifier": "FR-EUID-123456789"
    },
    {
      "type": "http://data.europa.eu/eudi/id/VATIN",
      "identifier": "FR12345678901"
    }
  ],
  "postalAddress": [
    "10 Rue Exemple, 75000 Paris, FR"
  ],
  "country": "FR",
  "email": [
    "wallet-rp-registration@examplebank.eu"
  ],
  "phone": [
    "+33100000000"
  ],
  "infoURI": [
    "https://examplebank.eu"
  ],
  "providerType": "WalletRelyingParty",
  "policy": [
    {
      "type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
      "policyURI": "https://examplebank.eu/terms"
    },
    {
      "type": "http://data.europa.eu/eudi/policy/privacy-policy",
      "policyURI": "https://examplebank.eu/privacy"
    }
  ],
  "tradeName": "ExampleBank Mobile",
  "supportURI": [
    "https://examplebank.eu/support"
  ],
  "srvDescription": [
    [
      { "lang": "en", "content": "Retail banking services for individuals." },
      { "lang": "fr", "content": "Services bancaires pour particuliers." }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider"
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autorité de supervision Exemple"]
    },
    "country": "FR",
    "email": ["contact@supervisor.example.fr"],
    "infoURI": ["https://supervisor.example.fr"]
  },
  "registryURI": "https://registry.example.fr/api",
  "isIntermediary": false,
  "intendedUse": [
    {
      "intendedUseIdentifier": "iu-001",
      "purpose": [
        { "lang": "en", "content": "Open a bank account remotely." }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://examplebank.eu/privacy/wallet"
        }
      ],
      "credential": [
        {
          "format": "dc+sd-jwt",
          "meta": {
            "vct": "https://example.eu/schema/pid"
          },
          "claim": [
            { "path": ["family_name"] },
            { "path": ["given_name"] },
            { "path": ["birth_date"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    }
  ]
}
Non-normative example: WRP object for a Relying Party that is also an Attestation Provider

A bank registered as both a service provider (requesting PID for KYC) and a QEAA_Provider (issuing bank account attestations to wallet units). It has both intendedUse and providesAttestations.

{
  "legalPerson": {
    "legalName": ["ExampleBank S.A."]
  },
  [...as previous example...] 
  "srvDescription": [
    [
      { "lang": "en", "content": "Retail banking services for individuals." },
      { "lang": "fr", "content": "Services bancaires pour particuliers." }
    ],
    [
      { "lang": "en", "content": "Issuance of qualified bank account attestations." },
      { "lang": "fr", "content": "Délivrance d'attestations de compte bancaire qualifiées." }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider",
    "https://uri.etsi.org/19475/Entitlement/QEAA_Provider"
  ],
  "providesAttestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://examplebank.eu/schema/bank-account"]
      },
      "claim": [
        { "path": ["iban"] },
        { "path": ["account_holder_name"] },
        { "path": ["account_type"] },
        { "path": ["currency"] }
      ]
    }
  ],
  "intendedUse": [
    {
      "intendedUseIdentifier": "iu-account-opening",
      "purpose": [
        { "lang": "en", "content": "Open a bank account remotely." },
        { "lang": "fr", "content": "Ouvrir un compte bancaire à distance." }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://examplebank.eu/privacy/wallet/account-opening"
        }
      ],
      "credential": [
        {
          "format": "dc+sd-jwt",
          "meta": { "vct_values": ["https://example.eu/schema/pid"] },
          "claim": [
            { "path": ["family_name"] },
            { "path": ["given_name"] },
            { "path": ["birth_date"] },
            { "path": ["nationalities"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    },
    {
      "intendedUseIdentifier": "iu-bank-account-attestation-issuance",
      "purpose": [
        {
          "lang": "en",
          "content": "Verify wallet holder identity to issue a bank account attestation."
        }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://examplebank.eu/privacy/wallet/attestation-issuance"
        }
      ],
      "credential": [
        {
          "format": "dc+sd-jwt",
          "meta": { "vct_values": ["https://example.eu/schema/pid"] },
          "claim": [
            { "path": ["family_name"] },
            { "path": ["given_name"] },
            { "path": ["birth_date"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    }
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autorité de supervision Exemple"]
    },
    "country": "FR",
    "email": ["contact@supervisor.example.fr"],
    "infoURI": ["https://supervisor.example.fr"]
  },
  "registryURI": "https://registry.example.fr/api",
  "isIntermediary": false
}
Non-normative example: WRP object for a designated Intermediary

An entity registered as a designated Intermediary that acts on behalf of WRPs during Wallet interactions. It has isIntermediary: true and does not declare intendedUse (not required when registering solely as an intermediary).

{
  "legalPerson": {
    "legalName": ["TrustBridge Services B.V."]
  },
  "identifier": [
    {
      "type": "http://data.europa.eu/eudi/id/EUID",
      "identifier": "NL-EUID-112233445"
    },
    {
      "type": "http://data.europa.eu/eudi/id/VATIN",
      "identifier": "NL112233445B01"
    }
  ],
  "postalAddress": [
    "Keizersgracht 100, 1015 CN Amsterdam, NL"
  ],
  "country": "NL",
  "email": ["wallet-intermediary@trustbridge.example"],
  "phone": ["+31200000000"],
  "infoURI": ["https://trustbridge.example"],
  "providerType": "WalletRelyingParty",
  "policy": [
    {
      "type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
      "policyURI": "https://trustbridge.example/terms"
    },
    {
      "type": "http://data.europa.eu/eudi/policy/privacy-policy",
      "policyURI": "https://trustbridge.example/privacy"
    }
  ],
  "tradeName": "TrustBridge",
  "supportURI": ["https://trustbridge.example/support"],
  "srvDescription": [
    [
      {
        "lang": "en",
        "content": "Intermediary services for wallet-relying parties operating in the Netherlands."
      },
      {
        "lang": "nl",
        "content": "Intermediaire diensten voor wallet-relying parties in Nederland."
      }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider"
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autoriteit Persoonsgegevens"]
    },
    "country": "NL",
    "email": ["info@autoriteitpersoonsgegevens.nl"],
    "infoURI": ["https://autoriteitpersoonsgegevens.nl"]
  },
  "registryURI": "https://registry.example.nl/api",
  "isIntermediary": true
}
Non-normative example: WRP object for a WRP using a designated Intermediary

A small e-commerce business that relies on TrustBridge (see example above) to conduct Wallet interactions on its behalf. It has usesIntermediary pointing to the Intermediary's registry entry, and isIntermediary: false.

{
  "legalPerson": {
    "legalName": ["ShopExample N.V."]
  },
  "identifier": [
    {
      "type": "http://data.europa.eu/eudi/id/EUID",
      "identifier": "NL-EUID-556677889"
    }
  ],
  "postalAddress": [
    "Damrak 50, 1012 LP Amsterdam, NL"
  ],
  "country": "NL",
  "email": ["wallet-rp@shopexample.example"],
  "infoURI": ["https://shopexample.example"],
  "providerType": "WalletRelyingParty",
  "policy": [
    {
      "type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
      "policyURI": "https://shopexample.example/terms"
    },
    {
      "type": "http://data.europa.eu/eudi/policy/privacy-policy",
      "policyURI": "https://shopexample.example/privacy"
    }
  ],
  "tradeName": "ShopExample",
  "supportURI": ["https://shopexample.example/support"],
  "srvDescription": [
    [
      { "lang": "en", "content": "Online retail services." },
      { "lang": "nl", "content": "Online detailhandel." }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider"
  ],
  "intendedUse": [
    {
      "intendedUseIdentifier": "iu-age-verification",
      "purpose": [
        { "lang": "en", "content": "Verify the customer is of legal age for restricted product purchases." }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://shopexample.example/privacy/wallet"
        }
      ],
      "credential": [
        {
          "format": "mso_mdoc",
          "meta": {
            "doctype_value": "org.iso.18013.5.1.mDL"
          },
          "claim": [
            { "path": ["org.iso.18013.5.1", "age_over_18"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    }
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autoriteit Persoonsgegevens"]
    },
    "country": "NL",
    "infoURI": ["https://autoriteitpersoonsgegevens.nl"]
  },
  "registryURI": "https://registry.example.nl/api",
  "isIntermediary": false,
  "usesIntermediary": [
    {
      "identifier": [
        {
          "type": "http://data.europa.eu/eudi/id/EUID",
          "identifier": "NL-EUID-112233445"
        }
      ],
      "tradeName": "TrustBridge",
      "registryURI": "https://registry.example.nl/api"
    }
  ]
}

Common Register API

This section documents a [TS05] aligned common Register API profile that satisfies [CIR 2025/848] Annex II and [CIR 2025/848-Amendment] constraints.

API Methods on Registration and Updating of WRP Data

The common API write methods (POST, PUT and DELETE) are defined for purposes of managing the Register information of MS Registrars.

Note

These methods SHALL be accessible by authorised users only.

POST /wrp — create (REQUIRED)

POST is for creating a new WRP entry in the Register. Method expects a request body with the WalletRelyingParty schema, and returns a 201 on success.

Request (body)

Type Presence Description
WalletRelyingParty REQUIRED Full WRP object compliant with [CIR 2025/848-Amendment], Annex VI Table 1 schema.

Response

HTTP Code Description
201 Created.
400 Bad request (invalid or incomplete payload).
401 Unauthorized (missing or invalid authentication).
403 Forbidden (caller not authorised by Member State).
PUT /wrp — update (REQUIRED)

PUT is for updating an existing WRP entry in the Register. Method expects a request body with the WalletRelyingParty schema, and can return 200 on success or 404 if not found.

Request (body)

Type Presence Description
WalletRelyingParty REQUIRED Full WRP object compliant with [CIR 2025/848-Amendment], Annex VI Table 1 schema.

Response

HTTP Code Description
200 Successfully updated.
400 Bad request (invalid or incomplete payload).
401 Unauthorized (missing or invalid authentication).
403 Forbidden (caller not authorised by Member State).
404 Not found.
DELETE /wrp — delete (REQUIRED)

DELETE is for deleting of an existing WRP entry in the Register. Method expects a request body with the WalletRelyingParty identifier, and returns a 204 on success.

Request (body)

Parameter Presence Description
identifier REQUIRED Identifier payload for the WRP to delete (profile-defined body shape, based on WalletRelyingParty.identifier).

Warning

For [TS05] and [CIR 2025/848-Amendment], this method expects a request body with the WalletRelyingParty identifier, while in the corresponding YAML file ts5-openapi31-registrar-api.yml the identifier is sent as a query parameter. This profile follows the [CIR 2025/848-Amendment].

Response

HTTP Code Description
204 Successfully deleted.
400 Bad request (invalid or incomplete payload).
401 Unauthorized (missing or invalid authentication).
403 Forbidden (caller not authorised by Member State).
404 Not found.
API Methods for Register Queries (Open API)

The common API read methods (GET) SHALL be open for public access (no prior authentication) and returns JWS-signed statements.

The public API SHALL provide methods for searching and querying complete data sets of registered WRPs matching with provided query parameters

GET /wrp — search/list (REQUIRED)

Get a list of WRPs (with optional filtering and pagination, list of all registered WRPs returned when no query parameters are provided).

Request (query parameters)

The common API SHALL support parameterised queries on GET /wrp. The following names align with the [CIR 2025/848-Amendment] Annex VI query parameter naming.

Parameter Type Presence Description
identifier string OPTIONAL Filter by official/business registration number / identifier.
legalname string OPTIONAL Filter by official company name.
tradename string OPTIONAL Filter by trade name.
policy string OPTIONAL Filter by privacy policy URL (or policy URI as profiled).
entitlement string OPTIONAL Filter by entitlement type (URI).
usesintermediary string OPTIONAL Filter by intermediary identifier.
isintermediary boolean OPTIONAL Filter by intermediary status.
intendeduseidentifier string OPTIONAL Filter by registrar-provided intended-use identifier.
claimpath string OPTIONAL Filter by intended-use requested claim path.
credentialmeta string OPTIONAL Filter by intended-use credential metadata (format-specific).
credentialformat string OPTIONAL Filter by intended-use credential format.
cursor string OPTIONAL Cursor for pagination (profile-defined token format).
limit integer OPTIONAL The number of items to return per page (profile-defined).
providesattestation Credential OPTIONAL Filter by attestation types provided.

Warning

The name of some query parameters differ from [TS05] and the corresponding YAML file ts5-openapi31-registrar-api.yml containing the OpenAPI specification of the JSON and REST based application programming interfaces (e.g., intendedusecredentialmeta vs credentialmeta). This profile follows the OpenAPI specification.

In addition, this specification adds providesattestation to cover the [CIR 2025/848-Amendment] requirement for filtering parameter: type of attestations provided, returning the complete data set of each of the registered wallet-relying parties matching the value provided for this parameter.

Requirement
If no query parameters are provided, GET /wrp SHALL return the full list of registered WRPs (subject to pagination profile).
The endpoint SHALL support cursor-based pagination.
The endpoint SHALL support combined filters in a single query.

Response A successful response (200) SHALL be JWS-signed response body.

HTTP Code Media Type Description
200 application/jwt JWS compact string. Decoded payload SHALL contain an array of WalletRelyingParty objects (matching the query), with address field excluded from published entries, and, where relevant, accompanied by WRPAC history information in the statement/profile used by the Member State. (strict Annex VI form: array; profile envelope also allowed if documented).

Note

The published API view excludes only postalAddress ([CIR 2025/848-Amendment], Annex I point 4). All other fields, including intended-use credential claims, are published as registered.

GET /wrp/check-intended-use — intended use check (REQUIRED)

A dedicated intended-use check endpoint for making narrowed-down intended use related queries from the Register.

Request

This profile uses the following mapping (strictly aligned names for intended-use filters):

Parameter Type Presence Description
rpidentifier string REQUIRED Identifier of the WRP whose intended-use registration is being checked.
intendeduseidentifier string OPTIONAL Intended-use identifier registered by the registrar.
claimpath string OPTIONAL Requested claim path to check (serialised representation of path array; profile-defined encoding).
credentialformat string OPTIONAL Credential format to check.
credentialmeta string OPTIONAL Credential metadata filter (profile-defined serialisation).
policyurl string OPTIONAL Used when checking if the privacy policy URL is registered for the identified WRP.

Response

HTTP Code Media Type Description
200 application/jwt JWS compact string; decoded payload is boolean true or false.
400 - Bad request (invalid or incomplete request parameter).
404 - WRP with the given rpidentifier not found.
GET /wrp/{identifier} — get by identifier (OPTIONAL)

Get WRP by identifier.

Note

This endpoint is useful, but it is not explicitly defined in the [CIR 2025/848-Amendment], Annex VI common API method list. If kept, mark it as a national/profile extension.

Request (query)

Parameter Type Presence Description
identifier string REQUIRED Identifier of the WRP to retrieve.

Response

HTTP Code Media Type Description
200 application/jwt JWS compact string; decoded payload contains one WalletRelyingParty entry (or profile envelope).
404 - Not found.

To preserve issuer/timestamp metadata and pagination in a stable schema, a Member State MAY define an envelope profile as follows (while still satisfying the endpoint semantics above):

SignedWRPArrayEnvelope (profile)
Parameter Type Presence Description
iss string REQUIRED Identifier of the Registry/Registrar issuing the statement.
iat integer REQUIRED Issued-at timestamp (Unix epoch seconds).
data WRPEntry[] REQUIRED Matching WRP entries (published view, address excluded), each bundled with its certificate history.
pagination Pagination OPTIONAL Cursor-based pagination metadata.
WRPEntry (per-WRP bundle)
Parameter Type Presence Description
wrp WalletRelyingParty REQUIRED WRP registration information (published view, address excluded).
wrpacHistory CertificateHistoryEntry[] OPTIONAL WRP access certificate history for this WRP (including CT-related references where available).
wrprcHistory CertificateHistoryEntry[] OPTIONAL WRP registration certificate history for this WRP (if provided by national profile).
SignedWRPEnvelope (profile, for non-common helper endpoints)
Parameter Type Presence Description
iss string REQUIRED Registry/Registrar identifier.
iat integer REQUIRED Issued-at timestamp.
data WalletRelyingParty REQUIRED Single WRP object (published view, address excluded).
wrpacHistory CertificateHistoryEntry[] OPTIONAL WRPAC history.
wrprcHistory CertificateHistoryEntry[] OPTIONAL WRPRC history (if supported).
SignedIntendedUseCheckEnvelope (profile)

Note

Annex VI strictly allows a JWS-signed boolean response. This object envelope is a non-normative profile convenience.

Parameter Type Presence Description
iss string REQUIRED Registry issuer.
iat integer REQUIRED Issued-at timestamp.
data boolean REQUIRED Result of intended-use check.
CertificateHistoryEntry (profile helper for certificate histories)
Parameter Type Presence Description
certificate string REQUIRED Certificate (e.g., PEM/DER-encoded representation, profile-defined).
x5c string[] OPTIONAL Certificate chain for the certificate entry.
status string REQUIRED Certificate status (e.g., current, revoked, expired, historic).
validFrom string OPTIONAL Validity start timestamp/date (profile-defined format).
validTo string OPTIONAL Validity end timestamp/date (profile-defined format).
ctLogEntries object[] OPTIONAL CT log / transparency references ([RFC 9162]-aligned, profile-defined structure).

Wallet-Relying Party Access Certificate

This section describes the purpose, format and content of Wallet-Relying Party Access Certificates (WRPACs).

According to the Article 2 of CIR (EU) 2025/848, a WRPAC, is a certificate for electronic seals or signatures authenticating and validating the Wallet-Relying Party (WRP). Issued by one or more designated provider under Member State supervision, the WRPAC serves to authenticate and verify the trustworthiness of the WRP when they interact with the EUDI Wallet. For more details on the authentication process, see Authentication Process. The suspension or cancellation of the WRP services, involves revocation of all valid WRPAC by the relevant issuing authority, such that the WRP is no longer able to interact with Wallet Units. For more detail on the Trust Management processes, see Trust Management and Lifecycle.

The Annex IV of [CIR 2025/848] also states that the WRPACs are meant for performing electronic signatures or seals and that they shall comply with at least the Normalised Certificate Policy ('NCP') requirements specified in the ETSI standards. Taking into account these minimal requirements, different scenarios are possible and specified in the following clauses: certificates issued to natural or legal persons, supporting advanced signatures/seals or even qualified signature/seals. Conditional requirements are defined according to the specific case the WRPACs fall into.

References

To guarantee the interoperability across all the wallets provided within the Union, WRPACs should adhere to common requirements, with respect to their content and format. The technical standard specific to these certificates is [ETSI TS 119 411-8]. However, multiple other standards are referenced either directly or indirectly by the [ETSI TS 119 411-8], containing requirements that are applicable to WRPACs as well. The list below enumerates all the applicable standards and specifications that have been used to populate the table below:

  • CIR 2025/848
  • ETSI EN 319 411-1
  • ETSI EN 319 411-2 (applicable if the certificate is qualified)
  • ETSI EN 319 412-1
  • ETSI EN 319 412-2 (applicable if the certificate is issued to natural persons)
  • ETSI EN 319 412-3 (applicable if the certificate is issued to legal persons)
  • ETSI EN 319 412-5 (applicable if the certificate is qualified)
  • ETSI TS 119 411-8
  • RFC 3647
  • RFC 3739
  • RFC 5280
  • RFC 9608

Dependency Considerations

The WRPAC attributes SHALL be derived from the information held in the Register as specified in clause 5.1.2 of [ETSI TS 119 475]. This also implies that for some specific attributes in the WRPAC the same value SHALL be encountered in the corresponding Wallet-Relying Party Registration Certificate if any.

Wallet Relying Party Access Certificate Content

The following table lists all the parameters and extensions that are mandatory in a WRPAC or mandatory with conditions. Optional parameters are not referenced and are not recommended, since they could cause conflicts with the content specified.

The column "Presence" contains the specification of the presence of the certificate parameter as follows:

  • REQUIRED: The parameter SHALL be present.
  • REQUIRED (C): The parameter SHALL be present if the condition specified in the "Description" column is fulfilled.
Parameter Defined in Presence Format Description
version [RFC 5280] clause 4.1.2.1 REQUIRED [0] EXPLICIT INTEGER Indicates the version of the encoded certificate. For this profile, it SHALL be v3 (2).
serialNumber [RFC 5280] clause 4.1.2.2 REQUIRED INTEGER The serial number of the certificate.
signature [RFC 5280] clause 4.1.2.3 REQUIRED SEQUENCE Identifies the signature algorithm used by the CA to sign the certificate. The signature algorithm SHOULD be selected according to [ETSI TS 119 312], but MAY be superseded by national recommendations.
signature.algorithm [RFC 5280] clause 4.1.1.2 REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm.
signature.parameters [RFC 5280] clause 4.1.1.2 OPTIONAL ANY Algorithm-specific parameters, dependent on the algorithm used.
issuer [ETSI EN 319 412-2] clause 4.2.3 REQUIRED Name Identifies the entity that has signed and issued the certificate.

If the issuer is a legal person, the following attributes SHALL be present:
  • countryName indicating the country in which the issuer of the certificate is established;
  • organizationName indicating the full registered name of the certificate issuing organization;
  • commonName indicating a name commonly used by the subject to represent itself;
  • conditionally, an organizationIdentifier if an appropriate registration number is known to exist and it has a value different from the organization name.

If the issuer is a natural person, the following attributes SHALL be present:
  • countryName indicating a country that is consistent with the legal jurisdiction under which certificates are issued;
  • choice of (givenName and/or surname) or pseudonym; if the given name or surname of the issuer is known, the respective attribute SHALL be present;
  • commonName;
  • serialNumber.
validity [RFC 5280] clause 4.1.2.5 REQUIRED SEQUENCE Time interval during which the CA warrants that it will maintain information about the status of the certificate.
validity.notBefore [RFC 5280] clause 4.1.2.5 REQUIRED UTCTime or GeneralizedTime The date on which the certificate validity period begins. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
validity.notAfter [RFC 5280] clause 4.1.2.5 REQUIRED UTCTime or GeneralizedTime The date on which the certificate validity period ends. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
subject [ETSI EN 319 412-2] clause 4.2.4 &
[ETSI EN 319 412-3] clause 4.2.1		 REQUIRED Name Identifies the entity associated with the public key stored in the subject public key field. If present, the size of organizationName, organizationalUnitName and commonName MAY be longer than the limit as stated in [RFC 5280].

If the subject is a natural person, the following attributes SHALL be present:
  • countryName indicating the general context in which other attributes are to be understood;
  • choice of (givenName and/or surname) or pseudonym;
  • commonName indicating a name of the subject;
  • conditionally, serialNumber if the above attributes are not sufficient to ensure subject name uniqueness.
When a natural person subject is associated with an organization, the attributes MAY also identify such organization using attributes like organizationName and organizationIdentifier.

If the subject is a legal person, the following attributes SHALL be present:
  • countryName indicating the country in which the subject is established;
  • organizationName indicating the full registered name of the subject;
  • organizationIdentifier indicating an identification of the subject organization different from the organization name;
  • commonName indicating a name commonly used by the subject to represent itself.
subjectPublicKeyInfo [RFC 5280] clause 4.1.2.7 REQUIRED SEQUENCE Carries the public key and identifies the algorithm with which the key is used. The subject public key SHOULD be selected according to ETSI TS 119 312 but MAY be superseded by national recommendations.
subjectPublicKeyInfo.algorithm [RFC 5280] clause 4.1.2.7 REQUIRED SEQUENCE The algorithm identifier for the public key.
subjectPublicKeyInfo.subjectPublicKey [RFC 5280] clause 4.1.2.7 REQUIRED BIT STRING The public key itself.
extensions [RFC 5280] clause 4.1.2.9 REQUIRED [3] EXPLICIT SEQUENCE A sequence of one or more certificate extensions.

The extensions field of the WRPAC SHALL contain various extensions, each of which is an ASN.1 SEQUENCE containing the following fields:

Parameter Defined in Presence Format Description
[extension_name].extnID [RFC 5280] clause 4.1.2.9 REQUIRED OBJECT IDENTIFIER The OID identifying the specific extension type.
[extension_name].critical [RFC 5280] clause 4.1.2.9 OPTIONAL BOOLEAN Indicates whether the extension is critical. DEFAULT is FALSE.
[extension_name].extnValue [RFC 5280] clause 4.1.2.9 REQUIRED OCTET STRING Contains the DER encoding of the ASN.1 value corresponding to the extension type identified by extnID.

Below there is a list of the mandatory extensions and their content, if applicable. The column "Criticality" of the certificate extensions takes the semantics defined in [RFC 5280, clause 4.2] and uses the following acronyms:

  • C: The extension SHALL be considered critical.
  • NC: The extension SHALL be considered non-critical.
Parameter Defined in Presence Criticality Format Description
authorityKeyIdentifier [ETSI EN 319 412-2, clause 4.3.1] REQUIRED Non-critical SEQUENCE Extension with the OID 2.5.29.35.

Key identifier for the issuing CA's public key.

Contains: keyIdentifier (OCTET STRING), authorityCertIssuer (GeneralNames), and authorityCertSerialNumber (INTEGER).
keyUsage [ETSI EN 319 412-2, clause 4.3.2] &
[ETSI EN 319 412-3, clause 4.3.1]		 REQUIRED Critical BIT STRING Extension with the OID 2.5.29.15.

It SHALL be one of the following:
  1. non-repudiation
  2. non-repudiation and digital signature
  3. digital signature
  4. digital signature and (key encipherment or key agreement)
  5. key encipherment or key agreement
  6. non-repudiation and digital signature and (key encipherment or key agreement)
Type A, C, or E should be used to avoid mixed usage of keys.

Certificates issued to natural persons and used to validate commitment to signed content (e.g., documents/agreements) SHALL be limited to type A, B, or F (type A should be used).

Certificates issued to legal persons and used to validate digital signatures over content SHALL be limited to type A, B, or F (type A should be used).

Certificate issuers are invited to take into account the security implications, particularly SC-1, when this parameter is set up.
cRLDistributionPoints [ETSI EN 319 412-2, clause 4.3.11] REQUIRED (C) Non-critical SEQUENCE Extension with the OID 2.5.29.31.

Sequence of distributionPoint represented by a CHOICE of FullName (GeneralNames) or nameRelativeToCRLIssuer, reasons (BIT STRING), and cRLIssuer (GeneralNames).

Applicable condition: If the certificate does not include any access location of an OCSP responder or the validity assured extension as defined in [ETSI EN 319 412-1].

It contains at least one reference to a publicly available CRL.
ext-etsi-valassured-ST-certs [ETSI EN 319 412-1, clause 5.2] REQUIRED (C) NC EXTENSION Extension with the OID 0.4.0.194121.2.1.

Applicable condition: For short-term certificates which cannot be revoked.

Indicates that the certificate issuer ensures the validity of the certificate is assured at time of use of the corresponding private key. Upon presence of such statement, the WRP can decide not to check the certificate revocation status (e.g., when validating a digital signature).
noRevAvail [RFC 9608] clause 2 REQUIRED (C) NC EXTENSION Extension with the OID 2.5.29.56.

Applicable condition: If the certificate includes the validity assured extension, but neither includes a CRL distribution point nor access location of an OCSP responder.
authorityInfoAccess [ETSI EN 319 412-2, clause 4.4.1] REQUIRED Non-critical SEQUENCE Extension with the OID 1.3.6.1.5.5.7.1.1.

Sequence of AccessDescription, containing an accessMethod (OID) and an accessLocation (GeneralName).

It SHALL at least include the id-ad-caIssuers OID specifying at least one access location of a valid CA certificate of the issuing CA.

If OCSP is supported, it SHALL include the id-ad-ocsp OID specifying at least one access location of an OCSP responder providing status information for the present certificate.

If the certificate does not include any CRL distribution point and does not include the validity assured extension, a reference to at least one OCSP responder SHALL be present.
certificatePolicies [RFC 3647, clause 3.3.1] &
[RFC 5280, clause 4.2.1.4]		 REQUIRED NC SEQUENCE Sequence of PolicyInformation elements, each being a SEQUENCE of policyIdentifier (OID) and policyQualifiers.

The extension is mandatory as stated in [ETSI TS 119 411-8], requirement GEN-6.6.1-03. [ETSI TS 119 411-8] defines the following policy identifiers:
  • 0.4.0.194118.1.1 for NCP-n-eudiwrp
  • 0.4.0.194118.1.2 for NCP-l-eudiwrp
  • 0.4.0.194118.1.3 for QCP-n-eudiwrp
  • 0.4.0.194118.1.4 for QCP-l-eudiwrp
The cpsURI under Certificate policies SHALL indicate a URL where the CPS of the Provider of WRPACs is located.
subjectAltName [RFC 5280, clause 4.2.1.6] REQUIRED NC SEQUENCE Extension with the OID 2.5.29.17.

Sequence of GeneralName elements, each representing a possible alternative name for the subject of the certificate.

Each GeneralName element contains contact information of the WRP and there SHALL be at least one element among the following:
  • uniformResourceIdentifier indicating a website where the WRP can be contacted for helpdesk/support matters.
  • otherName with type-id id-at-telephoneNumber indicating a phone number for WRP registration/usage matters.
  • rfc822Name indicating an email address for WRP registration/usage matters.
The extension is mandatory as stated in [ETSI TS 119 411-8] clause 6.6.1.
qcStatements (esi4-qcStatement-1) [RFC 3739, clause 3.2.6] &
[ETSI EN 319 412-5, clause 4.2.1]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.1.

Applicable condition: For qualified certificates. It indicates that the certificate is qualified within the defined legal framework. For the eIDAS regulatory environment, the QcCClegislation SHALL be absent.
qcStatements (esi4-qcStatement-4) [RFC 3739, clause 3.2.6] &
[ETSI EN 319 412-5, clause 4.2.2]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.4.

Applicable condition: For qualified certificates. It indicates that the private key related to the certified public key resides in a QSCD according to eIDAS regulation. The extension is mandatory as stated in ETSI EN 319 411-2, GEN-6.6.1-03.
qcStatements (esi4-qcStatement-6) [RFC 3739, clause 3.2.6] &
[ETSI EN 319 412-5, clause 4.2.3]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.6.

Applicable condition: Mandatory for qualified certificates issued to legal persons for the purpose of electronic seal ([ETSI EN 319 412-5, clause 5]). MAY be present for certificates issued to natural persons for the purpose of electronic signatures.

Declares that a certificate is issued for one and only one of the purposes: electronic signature, electronic seal, or web site authentication.

Examples

The following is an example of a WRPAC for legal persons following the NCP policy.

AccessCertificate cert = {

  tbsCertificate: {

    version: 2,                     // integer value 2 for v3  
    serialNumber: "0x6F3A0B91D2...", 
    signature: AlgorithmIdentifier { 
      oid: "1.2.840.113549.1.1.11",  // sha256WithRSAEncryption 
      params: NULL 
    }, 

    issuer: DistinguishedName {      // issuer attributes for legal person 
      countryName: "FR", 
      organizationName: "Example Trust Services CA S.A.", 
      commonName: "Example TS CA - Issuing", 
      organizationIdentifier: "VATFR-123456789" 
    }, 

    validity: { 
      notBefore: "2026-01-27T00:00:00Z", 
      notAfter:  "2027-01-27T00:00:00Z" 
    }, 

    subject: DistinguishedName {     // subject attributes for legal person 
      countryName: "FR", 
      organizationName: "Relying Party Example S.A.", 
      organizationIdentifier: "LEIXYZ-5493001KJTIIGC8Y1R12", 
      commonName: "RP Example" 
    }, 

    subjectPublicKeyInfo: { 
      algorithm: AlgorithmIdentifier { 
        oid: "1.2.840.113549.1.1.1", 
        params: NULL 
      }, 

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)" 
    }, 


    extensions: [

      Extension { 
        oid: "2.5.29.35",            // authorityKeyIdentifier 
        critical: false, 
        value: AuthorityKeyIdentifier { 
          keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)" 
        } 
      },

      Extension {
        oid: "2.5.29.15",            // keyUsage 
        critical: true, 
        value: KeyUsage { 
          nonRepudiation: true        // Type A 
          // all others false 
        } 
      }, 

      Extension {
        oid: "1.3.6.1.5.5.7.1.1",    // authority information access
        critical: false, 
        value: AuthorityInfoAccess [ 
          AccessDescription { 
            accessMethod: "1.3.6.1.5.5.7.48.2",            // id-ad-caIssuers 
            accessLocation: URI("https://ca.example.test/caIssuers/issuing-ca.cer") 
          }, 

          AccessDescription { 
            accessMethod: "1.3.6.1.5.5.7.48.1",            // id-ad-ocsp 
            accessLocation: URI("https://ocsp.example.test") 
          } 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.32",            // certificatePolicies 
        critical: false, 
        value: CertificatePolicies [ 
          PolicyInformation { 
            policyIdentifier: "0.4.0.194118.1.2",          // NCP-l-eudiwrp (legal person) 
            policyQualifiers: [ 
              CPSuri("https://rpca.example.test/cps") 
            ] 
          } 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.17",            // subjectAltName 
        critical: false, 
        value: SubjectAltName [ 
          GeneralName.uniformResourceIdentifier("https://rp.example.test/support"), 
          GeneralName.rfc822Name("wallet-support@rp.example.test"), 
          GeneralName.otherName( 
            typeId: "2.5.4.20",       // id-at-telephoneNumber 
            value: "+33-1-23-45-67-89" 
          ) 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.31",            // cRLDistributionPoints 
        critical: false,
        value: CRLDistributionPoints [ 
          DistributionPoint { 
            distributionPoint: URI("https://crl.example.test/issuing-ca.crl") 
          } 
        ] 
      } 
    ] 
  }, 

  signatureAlgorithm: AlgorithmIdentifier { 
    oid: "1.2.840.113549.1.1.11",    // must match/align with tbsCertificate.signature 
    params: NULL 
  }, 
  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))" 
}

Below there is an example of a WRPAC for natural persons following the QCP policy that is short-term and therefore non-revocable.

WRPAC cert = { 

  tbsCertificate: { 

    version: 2,                     // integer value 2 for v3  
    serialNumber: "0x02A94F10C3B7",
    signature: AlgorithmIdentifier { // M: per ETSI TS 119 312 (or national) 
      oid: "1.2.840.113549.1.1.11",  // example: sha256WithRSAEncryption 
      params: NULL 
    }, 

    issuer: DistinguishedName {      // issuer attributes for legal person 
      countryName: "FR", 
      organizationName: "Qualified Trust Service Provider CA S.A.", 
      commonName: "QTSP CA - Qualified Issuing", 
      organizationIdentifier: "VATFR-987654321" 
    }, 

      validity: {                    // short-term validity 
      notBefore: "2026-01-27T10:00:00Z", 
      notAfter:  "2026-01-27T22:00:00Z" 
    }, 

    subject: DistinguishedName { 
      countryName: "FR", 
      givenName: "Alice", 
      surname: "Martin", 
      commonName: "Alice Martin", 
      serialNumber: "PNO-FR-ALICEMARTIN-839201"
    }, 

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier { 
        oid: "1.2.840.10045.2.1",     // ecPublicKey 
        params: "1.2.840.10045.3.1.7" // prime256v1 
      }, 

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)" 
    }, 

    extensions: [ 

      Extension {                 // authority key identifier
        oid: "2.5.29.35", 
        critical: false, 
        value: AuthorityKeyIdentifier { 
          keyIdentifier: "HEX(ISSUING_CA_KEYID)" 
        } 
      }, 

      Extension { 
        oid: "2.5.29.15",           // key usage
        critical: true, 
        value: KeyUsage { 
          nonRepudiation: true        // Type A 
        } 
      }, 

      Extension {                 // subject alternative name
        oid: "2.5.29.17", 
        critical: false, 
        value: SubjectAltName [ 
          GeneralName.rfc822Name("helpdesk@relyingparty.example.test"), 
          GeneralName.uniformResourceIdentifier("https://relyingparty.example.test/support") 
        ] 
      }, 

      Extension {                  // authority information access 
        oid: "1.3.6.1.5.5.7.1.1", 
        critical: false, 
        value: AuthorityInfoAccess [ 
          AccessDescription { 
            accessMethod: "1.3.6.1.5.5.7.48.2",  // id-ad-caIssuers 
            accessLocation: URI("https://qtsp.example.test/caIssuers/qualified-issuing-ca.cer") 
          } 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.32",                      // certificate policies
        critical: false, 
        value: CertificatePolicies [ 
          PolicyInformation { 
            policyIdentifier: "0.4.0.194118.1.3",  // QCP-n-eudiwrp 
            policyQualifiers: [ 
              CPSuri("https://qtsp.example.test/cps") 
            ] 
          } 
        ] 
      }, 

      Extension { 
        oid: "0.4.0.194121.2.1",   // ext-etsi-valassured-ST-certs
        critical: false, 
        value:DER(NULL)             // (DER encoding: 0500)
      }, 

      Extension { 
        oid: "2.5.29.56",           // id-ce-noRevAvail
        critical: false, 
        value:DER(NULL)             // (DER encoding: 0500)
      }, 

      Extension { 
        oid: "1.3.6.1.5.5.7.1.3",   // qcStatements container 
        critical: false, 
        value: QCStatements [ 
          QCStatement {          // esi4-qcStatement-1
            statementId: "0.4.0.1862.1.1",
          }, 
          QCStatement { 
            statementId: "0.4.0.1862.1.4", // esi4-qcStatement-4
          }, 
          QCStatement { 
            statementId: "0.4.0.1862.1.6",  // esi4-qcStatement-6
            value: 0.4.0.1862.1.6.1  // purpose : electronicSignature
            } 
          } 
        ] 
      } 
    ] 
  }, 

  signatureAlgorithm: AlgorithmIdentifier { 
    oid: "1.2.840.113549.1.1.11", 
    params: NULL 
  }, 

  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))" 
}

Security Considerations

A WRPAC is a certificate for electronic seals or signatures that is used to authenticate and validate a WRP when interacting with Wallet Units. Because the corresponding private key is a signature/seal key, implementations SHALL prevent the WRPAC key from becoming a general-purpose signing oracle.

SC-1 — No blind signing of attacker-controlled inputs. The WRP (and any remote signing component used on its behalf, e.g., HSM/QSCD/remote seal) should only sign well-defined, locally constructed protocol artefacts and should not sign arbitrary bytes received from outside (e.g., random nonces, hashes, or opaque challenges supplied by an attacker). For instance, when the interaction with the Wallet Unit takes plase as described in the protocol [OpenID4VP], the WRP signs a self-constructed Request Object. Before signing, the WRP SHOULD validate that the Request Object is fully context-bound (e.g., correct aud, client_id/iss, exp, nonce, and correct endpoint binding such as response_uri/redirect_uri, and the intended presentation definition). Any signing API should enforce a strict schema/allowlist and reject unexpected fields. This is particularly important when the key usage is set to non-repudiation, since this protects against the signing entity falsely denying some action and allows a reliable third party to determine the authenticity of signed data in case of later conflict.

SC-2 — Bind signatures to the intended protocol context. Signed protocol objects should be clearly typed and scoped to the protocol to reduce cross-context misuse. In particular:

  • Use an explicit JOSE typ value appropriate for secured authorization requests / OpenID4VP Request Objects.
  • Constrain accepted JOSE algorithms and key types, and reject insecure or unexpected values (e.g., alg=none).

SC-3 — Key protection, access control, and monitoring. Private keys corresponding to WRPACs SHOULD be protected and operated under strong controls (access control for key use, audit logging, incident response, and operational monitoring). For remote signing, apply rate limiting and anomaly detection to reduce abuse.

Wallet-Relying Party Registration Certificate

This section defines Wallet-Relying Party Registration Certificates (WRPRC), as described in [ARF]. The WRPRC provides detailed information about the Attestation Provider's entitlements, the Attestations they issue, and their intended use.

References

  • CIR 2025/848
  • ETSI EN 319 411-1
  • ETSI TS 119 182-1
  • ETSI TS 119 475
  • ISO 3166-1
  • RFC 5646
  • RFC 7519
  • RFC 8392

Format

  1. The WRPRC shall be formatted as signed JSON Web Token (JWT) or CBOR Web Token (CWT).
  2. The WRPRC shall comply with the syntactic and semantic requirements specified in Annex V paragraph 3 of CIR (EU) 2025/848 [i.2].
  3. The WRPRC shall be signed with the digital signature of provider of the wallet-relying party registration certificates.
  4. The JWT shall be signed with a JSON Advanced Electronic Signature with the B-B profile as defined in [ETSI TS 119 182-1] [18].
  5. The CWT shall be signed with an Advanced Electronic Signature following structure as defined in [RFC 9052] and [RFC 9360].

Attribute Overview

Attribute group Description Required
Header Attributes Required header fields used to identify, sign, and validate WRPRC. Required
Core Identity Attributes Identity attributes of the WRP subject (natural person or legal entity). Required
Service Description Attributes Multilingual service descriptions defining the WRP’s provided services. Required
Entitlements Attribute Entitlements defining what the WRP is authorised to do. Required
Privacy and Policy Attributes Privacy policy information. Some of them
Supervisory Authority Attributes Supervisory authority contact details for reporting suspicious data-processing behaviour. Required
Service Provider Attributes Credential queries, purposes, and intended-use identifiers for service providers. Required for Service Provider
Attestation Provider Attributes Attributes describing attestations issued by an EAA provider. Required for EAA Provider
Technical Attributes Technical metadata such as policies, timestamps, and status-list configuration. Some of them
Uses Intermediary Attributes Attributes required when the WRP operates through an intermediary entity. Required if Intermediary is used

Header Attributes

JWT Header Attributes

Listed header attributes are mandatory.

Attribute Type Description Reference
typ string Specifies the type of the Web Token. The value is set to rc-wrp+jwt for JWT [ETSI TS 119 475] Table 5
alg string Indicates the algorithm used to sign the JWT as defined in clause 5.1.2 of [ETSI TS 119 182-1] [18]. [ETSI TS 119 475] Table 5
x5c array[string] Contains the whole certificate chain to verify the JWT or CWT as defined in clause 5.1.8 of [ETSI TS 119 182-1] [18] [ETSI TS 119 475] Table 5
CWT Header Attributes

Listed header attributes are mandatory.

Attribute Type Description Reference
typ string Specifies the type of the Web Token. The value is set to rc-wrp+cwt for CWT [ETSI TS 119 475] Table 6
alg string Indicates the algorithm used to sign the CWT as specified in [RFC 9052], clause 3.1 [ETSI TS 119 475] Table 6
x5chain array[string] Contains the whole certificate chain to verify the CWT as specified in [RFC 9360], clause 2 [ETSI TS 119 475] Table 6

Payload Attributes

Core Identity Attributes
Attribute Type Description Required Reference
name string The subject of the WRPRC trade name Required [ETSI TS 119 475] Table 7 - tradeName
sub_gn string Given Name of Natural Person Required for Natural Person [ETSI TS 119 475] Table 7 - givenName
sub_fn string Family Name of Natural Person Required for Natural Person [ETSI TS 119 475] Table 7 - familyName
sub_ln string Official legal name Required for Legal Entity [ETSI TS 119 475] Table 7 - legalName
sub string Organizational identifier per clause 5.1.3 Required for Legal Entity [ETSI TS 119 475] Table 7 - identifier
country string ISO 3166-1 alpha-2 code Required [ETSI TS 119 475] Table 7 - country
registry_uri string URL pointing to the national registry API endpoint of the registered WRP Required [ETSI TS 119 475] Table 7 - registryURI
info_uri string URL general-purpose web address Required [ETSI TS 119 475] Table 7 - infoURI
support_uri string URL or email address to use in data deletion or portability requests related to the WRP Required [ETSI TS 119 475] Table 7 - supportURI
Service Description Attributes
Attribute Type Description Required Reference
srv_description array[object] Multilingual service descriptions Required [ETSI TS 119 475] Table 7 - srvDescription
srv_description[].lang string Language identifier, referring the BCP47 language tag format defined in RFC 5646 [9] Required [ETSI TS 119 475] Table 7 - lang
srv_description[].value string Service description in specified language Required [ETSI TS 119 475] Table 7 - content
Entitlements Attribute
Attribute Type Description Required Reference
entitlements array[string] A list of entitlements assigned to the WRP as defined in [ETSI TS 119 475] - Annex A.2 Required [ETSI TS 119 475] Table 7 - entitlement
Privacy and Policy Attributes
Attribute Type Description Required Reference
privacy_policy string URL to the WRP's privacy policy explaining data processing and storage practices Required [ETSI TS 119 475] Table 7 - policyURI
public_body boolean Boolean indicating whether the WRP is a public sector body Optional [ETSI TS 119 475] Table 10 - isPSB
Supervisory Authority Attributes
Attribute Type Description Required Reference
supervisory_authority object DPA Info Required [ETSI TS 119 475] Table 7 - supervisoryAuthority
spervisory_authority.uri string The URL of web form provided by the Data Protection Authority supervising the Relying Party, which Users can use to report suspicious attribute presentation requests Required [ETSI TS 119 475] Table 7 - infoURI
supervisory_authority.email string An e-mail address of that DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users Required [ETSI TS 119 475] Table 7 - email
supervisory_authority.phone string A telephone number of that DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users Required [ETSI TS 119 475] Table 7 - phone
Service Provider Attributes
Attribute Type Description Required Reference
credentials array[object] A set of credential queries, used to request credentials from the Wallet. The EUDIW will use this information to perform an over-asking validation Required for Service Provider [ETSI TS 119 475] Table 9 - credential
credentials[].format string Format of the attestation Required for Service Provider [ETSI TS 119 475] Table 9 - format
credentials[].meta object Object defining additional properties. Required for Service Provider [ETSI TS 119 475] Table 9 - meta
credentials[].claim array[object] Array of objects that specifies attributes in the requested attestation. If claim is absent, the WRPRC does not declare any specific attributes intended to be requested by the WRP Required for Service Provide [ETSI TS 119 475] Table 9 - claim
purpose array[object] A list describing the data processing associated with the intended use Required for Service Provider [ETSI TS 119 475] Table 9 - purpose
purpose[].lang string Language identifier, referring the BCP 47 language tag format defined in [RFC 5646] Required for Service Provider [ETSI TS 119 475] Table 9 - lang
purpose[].value string Purpose description provided in the language specified above Required for Service Provider [ETSI TS 119 475] Table 9 - value
intended_use_id string Unique identifier of the intended use if provided by the registry. Used to fetch the intented use directly from the registry Required for Service Provider only if provided by registry [ETSI TS 119 475] Table 9 - intendedUserIdentifier
Attestation Provider Attributes
Attribute Type Description Required Reference
provides_attestations array[object] A set of credentials issued by the WRP with EAA entitlements. Required for EAA Provider [ETSI TS 119 475] Table 8 - providesAttestations
provides_attestations[].format string Format of the credential. Required for EAA Provider [ETSI TS 119 475] Table 8 - format
provides_attestations[].meta object Metadata to identify the credential type. Required for EAA Provider [ETSI TS 119 475] Table 8 - meta
provides_attestations[].claim array[object] Objects that specifies attributes in the requested attestation. Required for EAA Provider only if provided by registry [ETSI TS 119 475] Table 8 - claim
Technical Attributes
Attribute Type Description Required Reference
policy_id array[string] List of policy identifiers as defined in clause 6.1.3 Required [ETSI TS 119 475] Table 7 - technical
certificate_policy string URL to the certificate policy and certificate practice statement Required [ETSI TS 119 475] Table 7 - technical
iat unix_timestamp Unix timestamp indicating when the WRP was issued Required [ETSI TS 119 475] Table 7 - technical
exp unix_timestamp Expiration time of the JWT/CWT as a Unix timestamp Optional [ETSI TS 119 475] Table 10 - technical
status object A URI to a status list presenting information about validity of the WRPRC Required [ETSI TS 119 475] Table 7 - technical
status.status_list.idx int Position in status bitstring Required [ETSI TS 119 475] GEN-6.2.6.1-04, GEN-6.2.6.1-05
status.status_list.uri string Status list credential URI Required [ETSI TS 119 475] GEN-6.2.6.1-04
Uses Intermediary Attributes
Attribute Type Description Required Reference
intermediary object Used when the WRP operates via an intermediary Required if Intermediary is used [ETSI TS 119 475] Table 10 - usesIntermediary
intermediary.sub string Identifier of the intermediary as specified by the intermediary WRPAC Required if Intermediary is used [ETSI TS 119 475] Table 10 - usesIntermediary
intermediary.sname string commonName of the intermediary as specified by the intermediary WRPAC Required if Intermediary is used [ETSI TS 119 475] Table 10 - usesIntermediary

Examples

JWT Header
{
  "typ": "rc-wrp+jwt",
  "alg": "ES256",
  "x5c": ["<base64-encoded-certificate-chain>"]
}
CWT Header
{
  1: -7,    / alg: ES256 /,
  16: "rc-wrp+cwt", / typ /
  33: [     / x5chain /
    h'...', / binary end cert /
    h'...', / binary intermediate cert /
    h'...'  / binary root cert /
  ]
}
JWT Payload Example - Service Provider
{
  "name": "Online Shop AG",
  "sub_ln": "Online Shop AG",
  "sub": "LEIXG-529900T8BM49AURSDO55",
  "country": "DE",
  "registry_uri": "https://wrp-register.de/api/v1/relying-parties/DE-WRP-00789",
  "srv_description": [
    { "lang": "de-DE", "value": "Online-Einkaufsplattform mit Altersverifikation" },
    { "lang": "en-US", "value": "Online shopping platform with age verification" }
  ],
  "entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
  "purpose": [
    { "lang": "de-DE", "value": "Altersverifikation für altersbeschränkte Produkte gemäß JuSchG" },
    { "lang": "en-US", "value": "Age verification for age-restricted products" }
  ],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [{ "path": ["age_over_18"] }]
    }
  ],
  "privacy_policy": "https://shop.example.de/privacy",
  "info_uri": "https://shop.example.de",
  "support_uri": "https://shop.example.de/support",
  "supervisory_authority": {
    "uri": "https://www.bfdi.bund.de",
    "email": "poststelle@bfdi.bund.de",
    "phone": "+49 228 997799 0"
  },
  "public_body": false,
  "policy_id": ["0.4.0.19475.3.1"],
  "certificate_policy": "https://wrp-register.de/policies/service-provider",
  "iat": 1704067200,
  "exp": 1735689600,
  "status": { "status_list": { "idx": 156, "uri": "https://status.wrp-register.de/statuslist/1" } }
}
JWT Payload Example - Qualified EAA Provider
{
  "name": "Spanish Driving License Attestation Service",
  "sub_ln": "Ministerio del Interior - Dirección General de Tráfico",
  "sub": "VATES-S2800001J",
  "country": "ES",
  "registry_uri": "https://registro.mineco.gob.es/wrp/api/v1/relying-parties/ES-WRP-00123",
  "srv_description": [
    {
      "lang": "es-ES",
      "value": "Servicio de emisión de permisos de conducir digitales y attestaciones relacionadas con la conducción"
    },
    {
      "lang": "en-US",
      "value": "Digital driving license and driving-related attestation issuance service"
    }
  ],
  "entitlements": [
    "https://uri.etsi.org/19475/Entitlement/QEAA_Provider",
    "https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider"
  ],
  "provides_attestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.dgt.es/mobile-driving-license"
        ]
      },
      "claim": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["birth_date"] },
        { "path": ["portrait"] },
        { "path": ["driving_privileges"] },
        { "path": ["issue_date"] },
        { "path": ["expiry_date"] },
        { "path": ["issuing_authority"] },
        { "path": ["document_number"] },
        { "path": ["issuing_country"] }
      ]
    },
    {
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      },
      "claim": [
        { "path": ["org.iso.18013.5.1", "family_name"] },
        { "path": ["org.iso.18013.5.1", "given_name"] },
        { "path": ["org.iso.18013.5.1", "birth_date"] },
        { "path": ["org.iso.18013.5.1", "portrait"] },
        { "path": ["org.iso.18013.5.1", "driving_privileges"] }
      ]
    }
  ],
  "privacy_policy": "https://dgt.es/privacy-policy",
  "info_uri": "https://dgt.es",
  "supervisory_authority": {
    "uri": "https://www.aepd.es",
    "email": "ciudadano@aepd.es",
    "phone": "+34 91 266 35 17"
  },
  "public_body": true,
  "policy_id": [
    "0.4.0.19475.3.1"
  ],
  "certificate_policy": "https://pki.dgt.es/wrprc-policy",
  "iat": 1704067200,
  "exp": 1735689600,
  "status": {
    "status_list": {
      "idx": 42,
      "uri": "https://status.dgt.es/wrprc/statuslist/1"
    }
  }
}
JWT Payload Example - Non-Qualified EAA Provider (University)
{
  "name": "University of Amsterdam Credential Service",
  "sub_ln": "Universiteit van Amsterdam",
  "sub": "NTRNLD-KVK34567890",
  "country": "NL",
  "registry_uri": "https://wrp-register.nl/api/v1/relying-parties/NL-WRP-00456",
  "srv_description": [
    {
      "lang": "nl-NL",
      "value": "Uitgifte van digitale studentenkaarten en academische credentials"
    },
    {
      "lang": "en-US",
      "value": "Issuance of digital student cards and academic credentials"
    }
  ],
  "entitlements": [
    "https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider"
  ],
  "provides_attestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.uva.nl/student-id"
        ]
      },
      "claim": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["student_id"] },
        { "path": ["faculty"] },
        { "path": ["program"] },
        { "path": ["enrollment_date"] },
        { "path": ["expected_graduation"] },
        { "path": ["student_status"] }
      ]
    },
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.uva.nl/diploma"
        ]
      },
      "claim": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["degree_title"] },
        { "path": ["field_of_study"] },
        { "path": ["graduation_date"] },
        { "path": ["honors"] },
        { "path": ["diploma_number"] }
      ]
    }
  ],
  "privacy_policy": "https://uva.nl/privacy",
  "info_uri": "https://credentials.uva.nl",
  "supervisory_authority": {
    "uri": "https://autoriteitpersoonsgegevens.nl",
    "email": "info@autoriteitpersoonsgegevens.nl",
    "phone": "+31 70 888 85 00"
  },
  "public_body": false,
  "policy_id": [
    "0.4.0.19475.3.1"
  ],
  "certificate_policy": "https://pki.uva.nl/wrprc-policy",
  "iat": 1704067200,
  "exp": 1735689600,
  "status": {
    "status_list": {
      "idx": 78,
      "uri": "https://status.uva.nl/wrprc/statuslist/1"
    }
  }
}
JWT Payload Example - Banking KYC (Multiple Credentials)
{
  "name": "Dutch Bank Customer Onboarding",
  "sub_ln": "Dutch Bank N.V.",
  "sub": "LEIXG-724500VKKSH9QOLTFR81",
  "country": "NL",
  "registry_uri": "https://wrp-register.nl/api/v1/relying-parties/NL-WRP-00234",
  "entitlements": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider",
    "https://uri.etsi.org/19475/SubEntitlement/psp/psp-as"
  ],
  "purpose": [
    { "lang": "en-US", "value": "Identity verification and KYC check for bank account opening" }
  ],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [
        { "path": ["family_name"] }, { "path": ["given_name"] },
        { "path": ["birth_date"] }, { "path": ["nationality"] },
        { "path": ["resident_address"] }, { "path": ["personal_identifier"] }
      ]
    },
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/address-attestation"] },
      "claim": [
        { "path": ["resident_address"] }, { "path": ["resident_country"] }
      ]
    }
  ],
  "privacy_policy": "https://dutchbank.nl/privacy",
  "supervisory_authority": {
    "uri": "https://autoriteitpersoonsgegevens.nl",
    "email": "info@autoriteitpersoonsgegevens.nl"
  },
  "public_body": false,
  "policy_id": ["0.4.0.19475.3.1"],
  "iat": 1704067200,
  "status": { "status_list": { "idx": 89, "uri": "https://status.wrp-register.nl/statuslist/1" } }
}
JWT Payload Example - With Intermediary
{
  "name": "Small Business Verification",
  "sub_ln": "Small Business GmbH",
  "sub": "VATDE-DE123456789",
  "country": "DE",
  "entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [{ "path": ["age_over_18"] }]
    }
  ],
  "intermediary": {
    "sub": {
      "id": "LEIXG-529900INTERMEDIARY01",
      "name": "Verification Services AG"
    }
  },
  "policy_id": ["0.4.0.19475.3.1"],
  "iat": 1704067200,
  "status": { "status_list": { "idx": 567, "uri": "https://status.wrp-register.de/statuslist/2" } }
}
JWT Payload Example - Natural Person (Notary)
{
  "name": "Notaio Marco Rossi",
  "sub_gn": "Marco",
  "sub_fn": "Rossi",
  "sub": "TINIT-RSSMRC80A01H501U",
  "country": "IT",
  "registry_uri": "https://wrp-register.gov.it/api/v1/relying-parties/IT-WRP-00890",
  "entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
  "purpose": [
    { "lang": "it-IT", "value": "Identificazione delle parti per atti notarili" }
  ],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [
        { "path": ["family_name"] }, { "path": ["given_name"] },
        { "path": ["birth_date"] }, { "path": ["personal_identifier"] }
      ]
    }
  ],
  "privacy_policy": "https://notaio-rossi.it/privacy",
  "supervisory_authority": { "uri": "https://www.garanteprivacy.it", "email": "protocollo@gpdp.it" },
  "public_body": false,
  "policy_id": ["0.4.0.19475.3.1"],
  "iat": 1704067200,
  "status": { "status_list": { "idx": 345, "uri": "https://status.wrp-register.gov.it/statuslist/1" } }
}

Other Information

Algorithms

Algorithms used should be one of the algorithms for digital signatures recommended by in [ETSI TS 119 312].

[OpenID4VC High Assurance Interoperability Profile 1.0] also defines its own requirements for digital signatures. However, those requirements are not directly related to WRPRCs.

List of Possible Entitlements

Per [ETSI TS 119 475, Annex A.2]:

Entitlement URI OID ETSI Reference Description
Service_Provider https://uri.etsi.org/19475/Entitlement/Service_Provider id-etsi-wrpa-entitlement 1 Annex A.2.1 General service provider
QEAA_Provider https://uri.etsi.org/19475/Entitlement/QEAA_Provider id-etsi-wrpa-entitlement 2 Annex A.2.2 Qualified EAA provider
Non_Q_EAA_Provider https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider id-etsi-wrpa-entitlement 3 Annex A.2.3 Non-qualified EAA provider
PUB_EAA_Provider https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider id-etsi-wrpa-entitlement 4 Annex A.2.4 Public sector EAA provider
PID_Provider https://uri.etsi.org/19475/Entitlement/PID_Provider id-etsi-wrpa-entitlement 5 Annex A.2.5 Provider of person identification data
QCert_for_ESeal_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESeal_Provider id-etsi-wrpa-entitlement 6 Annex A.2.6 QTSP issuing qualified certificates for electronic seals
QCert_for_ESig_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESig_Provider id-etsi-wrpa-entitlement 7 Annex A.2.7 QTSP issuing qualified certificates for electronic signatures
rQSealCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSealCDs_Provider id-etsi-wrpa-entitlement 8 Annex A.2.8 QTSP managing remote qualified electronic seal creation devices
rQSigCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSigCDs_Provider id-etsi-wrpa-entitlement 9 Annex A.2.9 QTSP managing remote qualified electronic signature creation devices
ESig_ESeal_Creation_Provider https://uri.etsi.org/19475/Entitlement/ESig_ESeal_Creation_Provider id-etsi-wrpa-entitlement 10 Annex A.2.10 Non-qualified provider for remote signature/seal creation
Organizational Identifier Formats

Per [ETSI TS 119 475] clause 5.1.3 - Table 2 and 5.1.5 - Table 4:

Type URI (B.2.5) Semantic Prefix ETSI Reference EU Regulation
http://data.europa.eu/eudi/id/EUID NTR GEN-5.1.3-02, Table 2 CIR 2020/2244
http://data.europa.eu/eudi/id/LEI LEI GEN-5.1.3-02, Table 2 CIR 2022/1860
http://data.europa.eu/eudi/id/VATIN VAT GEN-5.1.3-02, Table 2 Directive 2006/112/EC
http://data.europa.eu/eudi/id/TIN TIN GEN-5.1.5-02, Table 4
CBOR Web Token (CWT) Claims

CWT token claims must be registered in a register created by IANA.

The register is available at https://www.iana.org/assignments/cwt/cwt.xhtml

List of Trusted Entities and List of Trusted Lists

This section describes the format and contents of the Trusted Lists and how they are used for the purpose of the List Of Trusted Lists (LOTL) and List of Trusted Entities (LoTE) within the context of the EUDI Wallet.

Regulatory Background

The Trusted List is defined in article 22 of eIDAS regulation EU 910/2014 as the means to keep current and historical information about the accredited trust service providers in each Member State. One Trusted List must be maintained and published by each Member State.

Furthermore, according to Chapter II of Annex I of The CID (EU) 2015/1505, further amended by CID (EU) 2025/2164, Trusted Lists must follow the technical specification [ETSI TS 119 612] version 2.4.1, becoming effective and live on April 29th, 2026.

Also in CID (EU) 2015/150, article 4(3) establishes that the Commission publishes the information received from MS about their Trust Lists in machine-readable format for automated processing. This is what is known by "List Of Trusted Lists (LOTL)". Under article 4(4), the Commission may also publish the same information in human-readable format.

Specifically for the EUDI Wallet, the Commission defines the additional "List of Trusted Entities (LoTE)". The principles of the LoTEs are established under Articles 4 and 5 in [CIR 2024/2980], which points the direction to the creation and publishing of two lists:

  1. one list to include: - Registrars of Wallet-Relying Parties - Registers of Wallet-Relying Parties
  2. another list to include: - Wallet Providers - PID Providers - and Providers of Wallet Relying Party Access Certificate

Trusted List

The Trusted List (TL) is a mechanism to convey information about trust anchors in an wide interoperable ecosystem such as the eIDAS framework. It was originally designed to hold current and historical information about the accreditation of trust service providers, particularly Qualified Trust Service Providers (QTSP), albeit other non-qualified can also be included, including those recognized exclusively at a national level.

For each trust service provider included, the following services can be listed:

  1. Qualified certificates issuing
  2. OCSP for qualified certificates (e.g. if the OCSP responder is external to the QTSP or is not listed in the OCSP URL is not indicated in the Authority Information Access extension)
  3. CRL for qualified certificates (e.g. if the CRL issuing is delegated or the CRL publishing URL is not included in the CRL Distribution Point extension)
  4. Qualified timestamping
  5. Qualified electronic registered delivery
  6. Qualified electronic registered mail delivery
  7. Qualified preservation for qualified electronic signatures and/or qualified electronic seals
  8. Qualified validation of qualified electronic signatures and/or qualified electronic seals
  9. Remote qualified electronic signature creation device, also known as "remote signing"
  10. Remote qualified electronic seal creation device, also known as "remote sealing"
  11. Qualified electronic attestations of attributes issuing
  12. Qualified electronic archiving
  13. Qualified electronic ledgers

Further to the qualified services, a similar set of services can be listed for non-qualified trust services as well as the following additional services:

  1. Not qualified electronic attestation of attributes issued by or on behalf of a public sector body responsible for an authentic source (usually referred by "Pub-EAA")
  2. Certificate validation
  3. Preservation of certificates
  4. Validation of electronic attestation of attributes
  5. Validation of timestamps
  6. Validation of data transmitted through electronic registered delivery services and the validation of related evidences
  7. Certificates issuing for purposes other than electronic signing/sealing
  8. Validation of certificates issued for purposes other than electronic signing/sealing

A TL may also include additional trust services defined at national level:

  1. Registration service
  2. Attribute certificates issuing
  3. Policy authority for issuing, publishing and maintaining signature policies
  4. Archiving
  5. Identity verification
  6. Key escrow
  7. Identity credentials based on static passwords
  8. Trusted List issuing (e.g. a sector specific national Trusted List)
  9. National Root CA
  10. Other trust services

The structure and semantics of the TL are defined in [ETSI TS 119 612]. For automated processing, the TL is provided in XML format. A browsable and human-readable format is also available on the eIDAS Dashboard at https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls.

Within eIDAS, one TL is maintained per Member State, responsible for keeping record of the trusted services providers under their respective jurisdiction. TLs are numbered and renewed periodically, and published in a website for unrestricted download. To protect their integrity and assure authenticity TLs are also signed with trusted certificates.

List of Trusted Lists

The Trusted List standard [ETSI TS 119 612] allows a hierarchy of Trusted Lists by means of referencing to other TLs from a parent TL.

Within eIDAS, a decentralized trust model is established, where the parent TL is the List Of Trusted Lists (LOTL), managed and operated by the Commission. For each Member State, the LOTL contains a URL that points to the respective EU Member State Trusted List (EUMS TL).

Currently, the LOTL is published in the following URI: https://ec.europa.eu/tools/lotl/eu-lotl.xml.

LOTL Signing and Pivot XML

The LOTL is electronically signed with a XAdES-B-B signature as defined by [ETSI EN 319 132-1]. For verification of the signature, the original signing certificates were initially published on the Official Journal of the European Union, here https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.276.01.0001.01.ENG.

Afterwards, a follow up method of providing traceable changes to the LOTL is provided through the "Pivot LOTL". Whenever the LOTL signing certificates are changed (as they expire over time and are replaced by new certificates), and/or the LOTL publishing URL is changed, a "Pivot LOTL" is created. A "snapshot" of the current LOTL is created and published at a specific URL and a reference to that Pivot LOTL is added to the new (main) LOTL. The LOTL contains the history of Pivot LOTLs, which allows participants in the eIDAS ecosystem to rebuild the history of the LOTL trust any given point in time. More information about the Pivot LOTL mechanism is available here: https://ec.europa.eu/tools/lotl/pivot-lotl-explanation.html.

List of Trusted Entities

The LoTE is a compilation of the information submitted by Member States about the following entities:

  1. PID Providers;
  2. Wallet Providers;
  3. Providers of Wallet Relying Party Access Certificate;
  4. Public sector bodies issuing electronic attestations of attributes.

The LoTE follows the same structure defined for TLs on [ETSI TS 119 612], yet a specific data model is defined in [ETSI TS 119 602] and 2 formats - JSON or XML - are allowed, depending on the type of LoTE.

The LoTE types can be one of the following, as defined in annex C.2:

Tools

This section presents a non-exhaustive list of tools to processing Trusted Lists.

TLManager: The TLManager is a tool for creating Trusted Lists compliant with [ETSI TS 119 612]. Examples of use of the TLManager are:

  • non-EU countries willing to establish a national Trusted List compatible with eIDAS. Following the same standard may facilitate bilateral trust.
  • setup of a sector specific Trusted List - for example, healthcare, energy production and distribution, transportation, etc.
  • setup of a lab Trusted List for testing purposes

TLManager is licenced under LGPL and is available for download here:

https://ec.europa.eu/digital-building-blocks/sites/spaces/TLSO/pages/75665517/Trusted+List+Manager+non-EU

eIDAS Dashboard: The eIDAS Dashboard is a platform in the format of a dynamic website where all information and tools necessary to make use of the EUDI Wallet, Trust Services and eID schemes are openly available.

The eIDAS Dashboard is available online here: https://eidas.ec.europa.eu/efda/home. Specifically for the EUDI Wallet ecosystem, the eIDAS Dashboard already has the placeholders for the several types of entities to be listed in the LoTEs, here: https://eidas.ec.europa.eu/efda/wallet.

Data Models

This section specifies the profiles and formats that the various Trusted Lists defined above SHALL utilize, depending on their specific use cases.

The following table dictates the governing standard, publication scope (i.e., at the Member State or European Union level), and the mandated data format for each list type.

List Type Governing Standard Publication Scope Format
Traditional eIDAS Trusted Lists TS 119 612 Member State XML
List of Trusted Lists (LOTL) TS 119 612 European Union XML
PID Provider Lists TS 119 602 Annex D European Union JSON
Wallet Provider (WP) Lists TS 119 602 Annex E European Union JSON
Provider of WRPAC TS 119 602 Annex F European Union JSON
Provider of WRPRC TS 119 602 Annex G European Union JSON
Pub-EAA Provider Lists TS 119 602 Annex H European Union JSON or XML
Registrar and Register Provider Lists TS 119 602 Annex I European Union JSON
Trusted List and List of Trusted Lists

The following URLs provide the normative XML schemas required for implementing the EU Member State Trusted Lists (EUMS TLs) and the List Of Trusted Lists (LOTL):

List of Trusted Entities

The following repository provides the normative JSON and XML schemas required for implementing the List of Trusted Entities (LoTE):

Trusted List Terminology Comparison

The LoTE and the LOTL / EUMS TL differ not only in their underlying schemas but also in their parameter nomenclature. The following table maps the equivalent terms between the two standards:

TS 119 602 (LoTE) TS 119 612 (TSL)
LoTE TSL
Trusted Entity (TE) Trust Service Provider (TSP)
Trusted Entity Service Trust Service
LoTE Version Identifier TSL Version Identifier
LoTE Sequence Number TSL Sequence Number
LoTE Type TSL Type
Scheme Operator Scheme Operator
Service Digital Identity Service Digital Identity
Specific Formats and Uses

The following table details the governing standards, publication scopes, and mandated data formats regarding the specific provider lists utilized within the ecosystem:

List Type Governing Standard Publication Scope Format
Traditional eIDAS Trusted Lists TS 119 612 Member State XML
List of Trusted Lists (LOTL) TS 119 612 European Union XML
PID Provider Lists TS 119 602 Annex D European Union JSON
Wallet Provider (WP) Lists TS 119 602 Annex E European Union JSON
Provider of WRPAC Lists TS 119 602 Annex F European Union JSON
Provider of WRPRC Lists TS 119 602 Annex G European Union JSON
Pub-EAA Provider Lists TS 119 602 Annex H European Union JSON or XML
Registrar and Register Provider Lists TS 119 602 Annex I European Union JSON

Note

Within the APTITUDE project, the PuB-EAA Provider Lists are published in JSON format.

LoTE Additional Requirements

Following Annexes D - I in [ETSI TS 119 602], below are detailed the additional requirements spelled out by type. As seen in List of Trusted Entities, the LoTE contains a sequence of two components: ListAndSchemeInformation and TrustedEntitiesList. Depending on the LoTE type, the ListAndSchemeInformation component is further specified by the following parameters:

Parameter Defined in Presence Format Description
LoTEVersionIdentifier [ETSI TS 119 602] clause 6.3.1 REQUIRED Integer The value of the LoTEVersionIdentifier component SHALL be 1.
LoTESequenceNumber [ETSI TS 119 602] clause 6.3.2 REQUIRED Integer The first instance of the PID providers list SHALL be issued with the value of the LoTESequenceNumber component number set to 1.
LoTEType [ETSI TS 119 602] clause 6.3.3 REQUIRED String Depending on the LoTE type, the value of the LoTEType component SHALL be one of the following URIs:
  • "http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList" for PID Providers;
  • "http://uri.etsi.org/19602/LoTEType/EUWalletProvidersList" for Wallet Providers;
  • "http://uri.etsi.org/19602/LoTEType/EUWRPACProvidersList" for Providers of WRPAC;
  • "http://uri.etsi.org/19602/LoTEType/EUWRPRCProvidersList" for Providers of WRPRC;
  • "http://uri.etsi.org/19602/LoTEType/EUPubEAAProvidersList" for Pub-EAA Providers;
  • "http://uri.etsi.org/19602/LoTEType/RegistrarsAndRegistersList" for Registrars.
SchemeOperatorName [ETSI TS 119 602] clause 6.3.4 REQUIRED Object No additional requirements.
SchemeOperatorAddress [ETSI TS 119 602] clause 6.3.5 REQUIRED Object No additional requirements.
SchemeName [ETSI TS 119 602] clause 6.3.6 REQUIRED Object No additional requirements.
SchemeInformationURI [ETSI TS 119 602] clause 6.3.7 REQUIRED Object Depending on the LoTE type, the SchemeInformationURI component SHALL contain a URI where users can receive information about the respective list (PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, Pub-EAA Provider, Registrar and Registers), and a URI where users can retrieve all previous instances of those lists.
StatusDeterminationApproach [ETSI TS 119 602] clause 6.3.8 REQUIRED String Depending on the LoTE type, the value of the StatusDeterminationApproach component SHALL be one of the following URIs:
  • "http://uri.etsi.org/19602/PIDProvidersList/StatusDetn/EU" for PID Providers;
  • "http://uri.etsi.org/19602/WalletProvidersList/StatusDetn/EU" for Wallet Providers;
  • "http://uri.etsi.org/19602/WRPACProvidersList/StatusDetn/EU" for Providers of WRPAC;
  • "http://uri.etsi.org/19602/WRPRCProvidersList/StatusDetn/EU" for Providers of WRPRC;
  • "http://uri.etsi.org/19602/PubEAAProvidersList/StatusDetn/EU" for Pub-EAA Providers;
  • "http://uri.etsi.org/19602/RegistrarsAndRegistersList/StatusDetn/EU" for Registrars.
SchemeTypeCommunityRules [ETSI TS 119 602] clause 6.3.9 REQUIRED Object Depending on the LoTE type, the value of the SchemeTypeCommunityRules component SHALL be one of the following URIs:
  • "http://uri.etsi.org/19602/PIDProvidersList/schemerules/EU" for PID Providers;
  • "http://uri.etsi.org/19602/WalletProvidersList/schemerules/EU" for Wallet Providers;
  • "http://uri.etsi.org/19602/EUWRPACProviders/schemerules/EU" for Providers of WRPAC;
  • "http://uri.etsi.org/19602/WRPRCProvidersList/schemerules/EU" for Providers of WRPRC;
  • "http://uri.etsi.org/19602/EUPubEAAProvidersList/schemerules/EU" for Pub-EAA Providers;
  • "http://uri.etsi.org/19602/RegistrarsAndRegistersList/schemerules/EU" for Registrars.
SchemeTerritory [ETSI TS 119 602] clause 6.3.10 REQUIRED String The value of the SchemeTerritory component SHALL be EU.
LoTEPolicyLegalNotice [ETSI TS 119 602] clause 6.3.11 REQUIRED Object No additional requirements.
HistoricalInformationPeriod [ETSI TS 119 602] clause 6.3.12 REQUIRED Integer For the PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, Registrar and Registers LoTE, the HistoricalInformationPeriod component SHALL NOT be present.

For the Pub-EAA Providers LoTE, the HistoricalInformationPeriod component value SHALL be 65535 (representing a year).
PointersToOtherLoTEs [ETSI TS 119 602] clause 6.3.13 REQUIRED Object For the PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, Registrar and Registers LoTE, the PointersToOtherLoTE component SHALL contain (at least) a pointer to the present LoTE itself.

For the Pub-EAA Provider LoTE, the PointersToOtherLoTE component SHALL NOT be present.
ListIssueDateTime [ETSI TS 119 602] clause 6.3.14 REQUIRED String No additional requirements.
NextUpdate [ETSI TS 119 602] clause 6.3.15 REQUIRED String The maximum value between the list issue date and time and the next update SHALL be 6 months.
DistributionPoints [ETSI TS 119 602] clause 6.3.16 REQUIRED Object No additional requirements.
SchemeExtensions [ETSI TS 119 602] clause 6.3.17 REQUIRED Object No additional requirements.

The TrustedEntitiesList is an Array of Objects, each possessing two primary subcomponents: the TrustedEntityInformation and TrustedEntityServices components. The following table details the additional requirements the TrustedEntityInformation Object component MUST satisfy depending on the LoTE type.

Parameter Defined in Presence Format Description
TEName [ETSI TS 119 602] clause 6.5.1 REQUIRED Array Depending on the LoTE type, the value of the TEName component SHALL be the name of the PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, Pub-EAA Provider, or Registrar.
TETradeName [ETSI TS 119 602] clause 6.5.2 REQUIRED Array Depending on the LoTE type, the value of the TETradeName component SHALL include an official registration identifier as registered in official records (where such a registered identifier exists) that unambiguously identifies the entity.

In the case of a legal entity, the TETradeName component SHALL have the same semantics as the organizationIdentifier attribute in [ETSI EN 319 412-1].

In the case of a natural person, the TETradeName component SHALL have the same semantics as the serialNumber attribute in [ETSI EN 319 412-1].

For Pub-EAA Providers, the TETradeName SHALL additionally include the reference to the Union or national law under which the Public Sector Body is established as responsible for the Authentic Source, formatted as a URI: OJ for the scheme part, followed by either EU or the 2 ISO 3166-1 country code characters, terminating with the unique identifier of the law.
TEAddress [ETSI TS 119 602] clause 6.5.3 REQUIRED Array Depending on the LoTE type, the TEAddress component SHALL contain:
  • the postal address of the provider;
  • the contact email and contact phone number of the provider.
TEInformationURI [ETSI TS 119 602] clause 6.5.4 REQUIRED Object Depending on the LoTE type, the TEInformationURI component SHALL contain:
  • The URL of the webpage that contains the policies, terms, and conditions of the respective provider applying to the provision and use of their services/components;
  • where applicable, the URL of the webpage that contains additional information about the provider;
  • a URI formatted as http://uri.etsi.org/19602/ListOfTrustedEntities/[Type]/CC, where [Type] aligns with the provider type and CC is replaced by the ISO 3166-1 Alpha 2 country code of the responsible Member State.
TEInformationExtensions [ETSI TS 119 602] clause 6.5.5 REQUIRED Array No additional requirements.

Warning

The TEAddress component's description for the Pub-EAA Providers LoTE differs from c) of the TEAddress component's description in ETSI 119 602 Annex H.3, Table H.2, which states "the URI "http://uri.etsi.org/19602/ListOfTrustedEntities/PubEAAProvider/CC" where "CC" is replaced by the ISO 3166-1 [2] Alpha 2 code of the Member State which is responsible for that Pub-EAA provider". For conformance to the other LoTE types, this has been moved to the TEInformationURI component's description, as it is more appropriate for the information it conveys.

The TrustedEntityServices is an Array of TrustedEntityService Objects. Each TrustedEntityService Object possesses two primary subcomponents: the ServiceInformation and ServiceHistoryInstance components. The following table details the additional requirements the ServiceInformation Object component SHALL satisfy depending on the LoTE type.

Parameter Defined in Presence Format Description
ServiceTypeIdentifier [ETSI TS 119 602] clause 6.6.1 REQUIRED String Depending on the LoTE type, specific URIs MAY be used as the value of the ServiceTypeIdentifier component, to the exclusion of any other (e.g., .../SvcType/PID/Issuance and .../Revocation for PID services).
ServiceName [ETSI TS 119 602] clause 6.6.2 REQUIRED Array For a Wallet Provider (WP), the ServiceName component SHALL be the name of the Wallet Solution it provides.

For a Registrar, the ServiceName component SHALL contain the name of the Register for which the Registrar is responsible.

No additional requirements for the other LoTE types.
ServiceDigitalIdentity [ETSI TS 119 602] clause 6.6.3 REQUIRED Object Depending on the LoTE type, the ServiceDigitalIdentity component SHALL contain one or more X.509 (Trust Anchor) certificates used to verify the signature or seal created by the provider to validate and authenticate their respective artifacts. The certified identity data MUST include the name and registration number as specified in the TEName and TETradeName components.

Pub-EAA Provider LoTE types MAY contain one or more X.509 certificates, which SHALL nonetheless be referenced on a QTSP EUMS TL.
ServiceStatus [ETSI TS 119 602] clause 6.6.4 REQUIRED String The ServiceStatus component SHALL be present for Pub-EAA Provider LoTE. Specific URIs MAY be used as the value to indicate if the entity is notified or withdrawn.

The ServiceStatus component SHALL NOT be used for the other LoTE types.
StatusStartingTime [ETSI TS 119 602] clause 6.6.5 REQUIRED String The StatusStartingTime component SHALL be present for Pub-EAA Provider LoTE.

The StatusStartingTime component SHALL NOT be used for the other LoTE types.
SchemeServiceDefinitionURI [ETSI TS 119 602] clause 6.6.6 REQUIRED Array No additional requirements.
ServiceSupplyPoint [ETSI TS 119 602] clause 6.6.7 REQUIRED Array For the Registrar LoTE, the ServiceSupplyPoint component SHALL contain the URI where the Register is available in a machine-processable manner. Any signed or sealed Register data obtained at this URI SHALL be able to be authenticated using one of the certificates listed in the ServiceDigitalIdentity component.

No additional requirements for the other LoTE types.
TEServiceDefinitionURI [ETSI TS 119 602] clause 6.6.8 REQUIRED Array No additional requirements.
ServiceInformationExtensions [ETSI TS 119 602] clause 6.6.9 REQUIRED Array For a Wallet Provider (WP), the ServiceInformationExtensions component SHALL be used to provide the reference number of the Wallet Solution identified by the ServiceName component.

No additional requirements for the other LoTE types.

The following table details the additional requirements the ServiceHistory.ServiceHistoryInstance Object component SHALL satisfy depending on the LoTE type.

Parameter Defined in Presence Format Description
ServiceName [ETSI TS 119 602] clause 6.6.2 REQUIRED Array No additional requirements.
ServiceDigitalIdentity [ETSI TS 119 602] clause 6.6.3 REQUIRED Object The ServiceDigitalIdentity of a Pub-EAA Provider LoTE SHALL contain at least the X509SKI component and SHALL NOT contain an X509Certificate component.

No additional requirements for the other LoTE types.
ServiceStatus [ETSI TS 119 602] clause 6.6.4 REQUIRED String No additional requirements.
StatusStartingTime [ETSI TS 119 602] clause 6.6.5 REQUIRED String No additional requirements.

Embedded Disclosure Policy

This section specifies the Embedded Disclosure Policy (EDP) for the EUDI Wallet ecosystem. It defines the following aspects:

  • What an EDP is, and which policy types are supported.
  • The data model and structure.
  • The distribution mechanism.
  • The lifecycle rules.

The authorization evaluation logic that the WI applies when processing an EDP during presentation is defined in the Authorization Process section of this specification.

Definition and Applicability

An Embedded Disclosure Policy is defined in Article 2(9) of [CIR 2024/2979] as:

"A set of rules, embedded in an electronic attestation of attributes by its provider, that indicates the conditions that a wallet-relying party has to meet to access the electronic attestation of attributes".

The EDP allows APs to indicate which RPs can access specific Attestations. APs can optionally express an EDP for their Attestations (EDP_01). The Article 10 of [CIR 2024/2979] establishes that Wallet Providers SHALL ensure that Attestations with common EDPs (as listed in Annex III of [CIR 2024/2979]) can be processed by their Wallet Instances.

EDPs are applicable to QEAAs, PuB-EAAs, and non-qualified EAAs. They are not applicable to PIDs as the EUDIW Regulation does not provide any requirement for PIDs to contain an EDP (EDP_01 note).

The main use cases enabled by EDPs are:

  • Implementing sector-specific access control (e.g., only public sector RPs or only healthcare RPs).
  • Implementing Member-State-specific access control (e.g., only RPs registered within a specific Member State).

Policy Types

Annex III of [CIR 2024/2979] defines three common EDP types:

No Policy. No EDP is present, or the EDP explicitly indicates that no restrictions apply (ISS-MDATA-EBD-4.2.5.2-06).

Authorized Relying Parties Only. The EDP contains a list of RPs that are allowed to access the Attestation. According to [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07), authorized RPs are identified by their subject distinguished name as held in the WRPAC, in LDAP string form as defined in RFC 4514. For legal persons, the relevant DN attributes are commonName, organizationName, organizationIdentifier, and countryName. For natural persons: commonName, givenName, surname, serialNumber, and countryName. The organizationIdentifier attribute type is represented by the LDAP string "ORGID"; the serialNumber attribute type is represented by "SN" (according to [ETSI TS 119 472-3] NOTE 1 and NOTE 2 to ISS-MDATA-EBD-4.2.5.2-07).

Note

[ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) also allows identifying authorized RPs by URI-encoded entitlements as specified in [ETSI TS 119 475], held in the WRPRC. [ETSI TS 119 475] Annex A.3 defines sub-entitlements for Service Providers, currently for Payment Service Providers (e.g. https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai). Future versions may include additional sector-specific sub-entitlements at national or EU level. This specification supports both the subject DN and the entitlement URI identification mechanisms.

Note

[ARF] HLR EDP_02 refers to "EU-wide unique identifiers", as defined in Reg_32, for the authorized RP list. [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) identifies authorized RPs by their subject DN from the WRPAC. The organizationIdentifier attribute within the DN has the same semantics as the identifier given in Reg_32. This specification aligns with the [ETSI TS 119 472-3] formulation. Future ARF versions are expected to align accordingly.

Specific Root of Trust. The EDP contains a list of trusted roots or intermediate certificates. Only RPs whose WRPACs chain to one of these roots are allowed to access the Attestation. According to [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-08/09), each authorized root is identified by its issuer distinguished name in LDAP string form as defined in RFC 4514 and the issuer's certificate serial number.

Data Model

The data model of the EDP is defined in [ETSI TS 119 472-3] section 4.2.5.2 through requirements ISS-MDATA-EBD-4.2.5.2-01 to ISS-MDATA-EBD-4.2.5.2-13.

Data Model Requirements

The data model defines the following elements:

  • The EDP SHALL be identified by a unique URI (ISS-MDATA-EBD-4.2.5.2-01). The EDP MAY be accessible through this URI (ISS-MDATA-EBD-4.2.5.2-02).
  • The EDP association with an EAA SHALL be established by including its unique URI. The AP SHALL either include the URI together with the full policy data set, or provide only the URI if the policy data set has already been pre-loaded into the WI (ISS-MDATA-EBD-4.2.5.2-03).
  • The EDP MAY include a description of the applicability of the policy to a particular community and/or class of application with common security requirements (ISS-MDATA-EBD-4.2.5.2-04).
  • The EDP MAY include an identifier of the authority responsible for the policy (ISS-MDATA-EBD-4.2.5.2-05).
  • The EDP MAY indicate that no policy restrictions apply for the associated EAA (ISS-MDATA-EBD-4.2.5.2-06).
  • The EDP MAY contain a list of authorized RPs, identified by subject DN as described in the Policy Types section (ISS-MDATA-EBD-4.2.5.2-07).
  • The EDP MAY define a specific list of roots of trust, identified by issuer DN and certificate serial number (ISS-MDATA-EBD-4.2.5.2-08/09).
  • Other information MAY be included in an EDP Extension which MAY be ignored by the WI (ISS-MDATA-EBD-4.2.5.2-10). The WI SHOULD be able to process the EDP even if unrecognized extensions are present (ISS-MDATA-EBD-4.2.5.2-11).
  • An EDP Extension MAY contain alternative policy rules to be applied to specified attributes within the EAA which are subject to selective disclosure (ISS-MDATA-EBD-4.2.5.2-12).
  • The EDP SHOULD contain a link to a website of the AP explaining the disclosure policy in layman's terms (ISS-MDATA-EBD-4.2.5.2-13, EDP_05).

Note

[ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-12) provides for attribute-level policies, where alternative policy rules (no policy, authorized RP only, or specific root of trust) can be defined for specific attributes within an EAA that are subject to selective disclosure. This capability is recognized but is not further detailed in this specification. Detailed handling of attribute-level EDP will be addressed when the ETSI JSON schema for EDP is finalized and the policy mechanisms are fully defined.

Structure and Encoding

The following JSON structure is derived from the [ETSI TS 119 472-3] data model requirements.

Warning

The JSON schema and the parameter names are defined in this section and are not based on a normative ETSI specification. [ETSI TS 119 472-3] section 4.2.5.2 defines the high level requirements for data model, but the final JSON schema will be published separately by ETSI (see Annex C of [ETSI TS 119 472-3]). The structure defined here is an implementation profile based on the ETSI data model requirements, and parameter names MAY change when the ETSI schema is published.

Parameter Type Description Based on
policy_uri string (URI) REQUIRED. Unique identifier of the EDP. ISS-MDATA-EBD-4.2.5.2-01
policy_type string REQUIRED. Policy type. Values: "no_policy", "authorized_rp_only", "specific_root_of_trust". ISS-MDATA-EBD-4.2.5.2-06/07/08
description string OPTIONAL. Description of the applicability of the policy to a particular community or class of application. ISS-MDATA-EBD-4.2.5.2-04
policy_authority string OPTIONAL. Identifier of the authority responsible for the policy. ISS-MDATA-EBD-4.2.5.2-05
policy_info_url string (URL) OPTIONAL. Link to a website explaining the policy in layman's terms. ISS-MDATA-EBD-4.2.5.2-13, EDP_05
authorized_parties array of objects REQUIRED if policy_type is "authorized_rp_only". List of authorized RPs. ISS-MDATA-EBD-4.2.5.2-07
authorized_parties[].subject_dn string OPTIONAL. Subject DN of the RP from the WRPAC, in LDAP string form as defined in RFC 4514. At least one of subject_dn or entitlement_uri SHALL be present in each element. ISS-MDATA-EBD-4.2.5.2-07
authorized_parties[].entitlement_uri string (URI) OPTIONAL. URI-encoded entitlement or sub-entitlement as specified in [ETSI TS 119 475] Annex A, held in the WRPRC. At least one of subject_dn or entitlement_uri SHALL be present in each element. ISS-MDATA-EBD-4.2.5.2-07
trusted_roots array of objects REQUIRED if policy_type is "specific_root_of_trust". List of trusted roots. ISS-MDATA-EBD-4.2.5.2-08
trusted_roots[].issuer_dn string REQUIRED. Issuer DN in LDAP string form compliant with RFC 4514. ISS-MDATA-EBD-4.2.5.2-09
trusted_roots[].serial_number string REQUIRED. Certificate serial number of the issuer. ISS-MDATA-EBD-4.2.5.2-09

Distribution

The EDP is distributed through Credential Issuer Metadata at issuance time. The AP SHALL include the EDP (if any) by value in the Issuer Metadata, within the credential_configurations_supported parameter, in compliance with [OpenID4VCI] or the extension thereof specified in [ETSI TS 119 472-3] (EDP_09). The EDP SHALL NOT be revealed to the RP through the presentation protocol (per [ETSI TS 119 472-3] section 4.2.5.1).

Warning

According to ISS-MDATA-EBD-4.2.5.2-03, the AP may provide only the policy_uri if the policy data set has already been pre-loaded into the WI. As the mechanism for pre-loading policies into a WI is not specified in the current normative references, this option SHALL be considered out-of-scope of this specification, at least until further implementation details are provided by ETSI.

As described in section Authorization Process, during attestation issuance, the EDP (if available) is stored locally by the WI and it is associated with the specific Attestation for which it was retrieved.

Lifecycle

Validity Binding

The locally stored EDP SHALL remain valid as long as the Attestation it is associated with is valid and not revoked. The EDP SHALL NOT have an independent validity status or revocation mechanism separate from the Attestation.

Update Mechanism

If an AP adds, changes, or deletes an EDP for an Attestation, the AP SHALL revoke that Attestation (EDP_11). The WI detects the policy change indirectly through the normal Attestation status checking mechanism (Status List), which will report that the Attestation as revoked. The locally stored EDP is then implicitly invalidated together with the Attestation. The User needs to request a new issuance to obtain the Attestation with the updated policy.

Even a minor policy change (e.g., adding a single RP to the authorized list) requires revocation and re-issuance. The timing of detection depends on when the WI checks the Attestation status: if the WI checks only at presentation time, a policy change will not be detected until the next presentation attempt.

Warning

Proactive refresh. The AP MAY provide EDP though its URI. In this case, the WI MAY proactively fetch the policy content at the policy_uri to check for updates, without waiting for an Attestation revocation signal. However, this mechanism SHALL NOT be used in this specification for the following reason:

  • It enables AP to unilaterally change an EDP, and it may introduce privacy risks and management overhead (as stated in the Discussion Topic D)
  • Technical details of this mechanism are not defined within ETSI standard.

Normative References

Reference Description
[CIR 2024/2979] Article 2(9) Definition of Embedded Disclosure Policy
[CIR 2024/2979] Article 10 Wallet Provider (WP) obligations for EDP processing
[CIR 2024/2979] Annex III Common EDP types
[ETSI TS 119 472-3] section 4.2.5 EDP data model requirements (ISS-MDATA-EBD-4.2.5.2-01 through 13)
[ETSI TS 119 475] Annex A.2 Common entitlement URIs
[ETSI EN 319 412-1] section 5.1.4 organizationIdentifier semantics
RFC 4514 LDAP string representation of Distinguished Names

6. Trust Evaluation Process

This section describes the Trust Evaluation Process, which establish trust between two interacting entities by ensuring that their identities are verified against a recognized Root of Trust, and they are eligible to perform a particular operation (e.g., issuing or requesting an Attestation of a certain type). This process comprises three distinct sub-processes:

  1. Trust Anchor Validation Process
  2. Authentication Process, and
  3. Authorization Process.

Trust Anchor Validation Process

The Trust Anchor Validation Process establishes the cryptographic integrity and authenticity of Trusted Lists, which serve as the authoritative sources for Trust Anchors. A Trust Anchor is a self-signed X.509 certificate containing the names and public key used by a Wallet Unit or Wallet-Relying Party (WRP) to validate an artifact or Attestation.

Depending on the artifact or Attestation being verified, the validating Entity SHALL fetch, download, and validate the appropriate Trusted List:

  1. List of Trusted Entities (LoTE), used to retrieve Trust Anchors for validating the following: - Infrastructure Certificates: WRPAC or WRPRC. - Wallet Artifacts: Wallet Unit Attestation (WUA) or Wallet Instance Attestation (WIA). - PID Signatures: Person Identification Data (PID). - Registrar-signed artifacts: Register informations.
  2. EU Member State Trusted Lists (EUMS TL); used to retrieve Trust Anchors for validating the following: - seal or signature on a Qualified Electronic Attestation of Attributes (QEAA); or - seal or signature on a Public Electronic Attestation of Attributes (PuB-EAA).

To verify the authenticity of the retrieved Trusted Lists, the Entity SHALL perform the following validations:

To support continuous key rotation, both artifacts implement a pivoting mechanism. This ensures that an Entity possessing the last known valid version can reliably discover the location of the next version and validate it using the unbroken chain of trust rooted in the OJEU.

List of Trusted Entities Validation

This section defines the validation of the EU-level List of Trusted Entities (LoTE). The LoTE is a digitally signed/sealed artifact (JWT format) containing metadata and public keys for entities operating at the EU level.

Prior to validating the LoTE, the Wallet Unit SHALL download the LoTE from the protected location (URI) published in the OJEU.

List of Trusted Entities Retrieval and Validation Sequence Diagram
sequenceDiagram
  participant Client as Wallet/WRP
  participant EU_API as EU LoTE Distribution Point

  Client->>EU_API: Request LoTE (URL from OJEU or Bookmark)
  EU_API-->>Client: Return LoTE (JWT)
  Client->>Client: 1. Pivot Discovery (Find path to Trust Anchor)
  Client->>Client: 2. Validate Trust Chain (OJEU -> Pivot n ... -> LoTE)
  Client->>Client: 3. Parse Payload for Target Entity
List of Trusted Entities Validation Process

The validator initializes the following variables as described in [ETSI TS 119 615].

Input Variables:

  • OJEU-Loc: URI of the latest (known) OJEU publication.
  • OJEU-LoTE-Loc: URI of the last processed LoTE. Defaults to the value in OJEU-Loc.
  • OJEU-LoTE-Certs-Set: The set of Trust Anchor certificates from the OJEU-Loc publication.
  • LoTE: The LoTE JWT currently being processed. Initialized as NULL.
  • LoTE-Signer-Cert: The certificate extracted from the x5c header parameter of the LoTE.
  • LoTESO-Cert: Temporary variable for the Scheme Operator certificate being validated. Initialized as NULL.
  • LoTESO-Certs-Set: Trusted certificates extracted from the PointersToOtherLoTE claim (SchemeTerritory EU) of a LoTE or Pivot. Initialized as NULL.

Output Variables:

  • Authenticated-LoTE: The validated JSON payload.
  • LoTE-Status: The validation result (e.g., LoTE_VERIFICATION_PASSED).
  • LoTE-Sub-Status: detailed error codes.

Validation Steps: The validation SHALL perform the following steps:

  1. (Initialization) Download the JWT file from OJEU-LoTE-Loc and assign it to LoTE.
  2. (Parsing) Extract the first certificate from the x5c header of LoTE and assign it to LoTE-Signer-Cert.
  3. (Pivot Discovery) Iterate through the uriValue claims in the SchemeInformationURI object. Count the number of valid URIs found before encountering the URI matching OJEU-Loc. Let $n$ be that count.
    • If no URI matches OJEU-Loc: Validation SHALL fail with LoTE-Status set to LoTE_VERIFICATION_FAILED and LoTE-Sub-Status set to OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE. (This implies a Trust Anchor migration is required).
  4. (LoTE Location Conflict) Check the condition: OJEU-LoTE-Loc != LoTELocation AND LoTE != Content at LoTELocation.
    • (LoTELocation is the URI in the PointersToOtherLoTE claim of LoTE with SchemeTerritory = EU).
    • If TRUE: Validation SHALL stop with LoTE-Status set to LoTE_VERIFICATION_FAILED and LoTE-Sub-Status set to LoTE_FILE_CONFLICT.
    • If FALSE, proceed to the next step.
  5. (LoTE Freshness) Check the condition: OJEU-LoTE-Loc == LoTELocation AND LoTE != Content at LoTELocation.
    • If TRUE: Set OJEU-LoTE-Loc to LoTELocation and restart from Step 1.
    • If FALSE, proceed to the next step.
  6. (Digital Signature Validation) Validate the cryptographic signature of the current LoTE using the public key from LoTE-Signer-Cert.
    • If validation fails: Stop with LoTE-Status set to LoTE_VERIFICATION_FAILED and LoTE-Sub-Status set to LoTE_SIGNATURE_VERIFICATION_FAILED.
    • If successful:
      • Set LoTESO-Cert to LoTE-Signer-Cert.
      • Set LoTESO-Certs-Set to the certificates found in the PointersToOtherLoTE claim (territory EU) of the current LoTE payload.
  7. (Intermediate Pivot Validation)
    • Case $n=0$ (No Pivots): Proceed directly to Step 8.
    • Case $n>0$ (History Chain):
      • Iterate $i$ from 1 to $n$ (from most recent Pivot to oldest). Let Pivot be the file downloaded from the $i$-th URI.
      • (Link Check) Set Pivot-Certs-Set to the certificates in the PointersToOtherLoTE claim (territory EU) of Pivot. If LoTESO-Cert (the signer of the previous file in the chain) is not in Pivot-Certs-Set, validation SHALL fail with LoTE-Sub-Status set to PIVOT_i-1_SIGNER_CERT_NOT_AUTHENTICATED_BY_PIVOT_i.
      • (Update Signer) Set LoTESO-Cert to the first certificate in the x5c header parameter of Pivot.
      • (Verify Signature) Validate the signature of Pivot using LoTESO-Cert. If it fails, validation SHALL fail with LoTE-Status set to LoTE_VERIFICATION_FAILED, and LoTE-Sub-Status set to PIVOT_i_SIGNATURE_VERIFICATION_FAILED.
      • The loop continues, walking backwards until LoTESO-Cert represents the signer of the oldest Pivot.
  8. (Trust Anchor Validation) Verify the end of the chain. If LoTESO-Cert (from the last Pivot or current LoTE) is not in OJEU-LoTE-Certs-Set (the Trust Anchor), validation SHALL fail with LoTE-Sub-Status set to PIVOT_n_SIGNER_CERT_NOT_AUTHENTICATED_BY_OJEU.
  9. (Expiration) If current time > NextUpdate claim of LoTE, validation SHALL fail.
  10. (Success) Set Authenticated-LoTE to LoTE, LoTE-Status to LoTE_VERIFICATION_PASSED.
  11. (Update Bookmark) If OJEU-LoTE-Loc does not match the LoTELocation in Authenticated-LoTE (territory EU), update OJEU-LoTE-Loc to that value.
  12. (Update Anchor) [Caution: This step modifies the Root of Trust configuration]
    • If OJEU-Loc does not match the first URI in SchemeInformationURI, update OJEU-LoTE-Loc.
    • Update OJEU-LoTE-Certs-Set according to the new Trust Anchor either in Authenticated-LoTE or from a new OJEU publication.

Remarks:

  • Steps 4, 5 and 11 allow modifying the location of the LoTE file without changing the Trust Anchor, as long as the both the old and the new location have the same content (otherwise the validation fails with LoTE_FILE_CONFLICT status). This allows the LoTE to be retrieved from different locations (e.g., mirrors) without affecting the Trust Anchor validation as long as the content is the same.
  • In case of OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE error, it is likely that the OJEU publication has been updated with a new location for the LoTE, and the validation process needs to be restarted with the new location.
  • In step 8, the validator established the binding of the signer certificate of the LoTE XML with the certificate referenced in the OJEU, effectively using the latter as a Trust Anchor.

To validate a Pub-EAA LoTE in XML format (XAdES) containing the sought Trust Anchor, the Wallet Unit or WRP SHALL perform the same steps as described in List of Trusted Lists Validation Process for the LoTE, with the following difference: the variables and status codes used throughout have LoTE in place of LOTL.

Below is a flowchart summarizing the above steps for the validation of the LoTE:

graph TD
    classDef failure fill:#f8d7da,stroke:#721c24,color:#721c24,font-weight:bold;
    classDef success fill:#d4edda,stroke:#155724,color:#155724,font-weight:bold;
    classDef warning fill:#fff3cd,stroke:#856404,color:#856404;
    classDef process fill:#fff,stroke:#333,stroke-width:1px;
    classDef decision fill:#e7f3fe,stroke:#0056b3,stroke-width:1px;

    Start([Start LoTE JWT Validation]) --> Init[1. Init & Download LoTE<br/>from OJEU-LoTE-Loc]:::process
    Init --> Parse[2. Parse Header:<br/>Extract Signer Cert x5c]:::process

    %% Step 3: Pivot Discovery
    Parse --> S3{3. Found OJEU-Loc URI in history?}:::decision
    S3 -- "No (NotFound)" --> F3[Fail: OJEU Loc Not Found<br/>Trust Anchor Migration Needed]:::failure

    %% Steps 4 & 5: Location & Freshness Checks
    S3 -- "Yes (Set n)" --> S4{4. Location Conflict?<br/>Old-LoTE-Loc != New-LoTE-Loc AND <br/> Old-LoTE != New-LoTE}:::decision
    S4 -- Yes --> F4[Fail: File Conflict / Spoofing]:::failure
    S4 -- No --> S5{5. Freshness Check<br/>Old-LoTE-Loc == New-LoTE-Loc AND <br/> Old-LoTE != New-LoTE}:::decision
    S5 -- "Yes (New Version Detected)" --> UpdateLoc[Update OJEU-LoTE-Loc]:::warning
    UpdateLoc --> Init
    S5 -- "No (Current is Fresh)" --> S6

    %% Step 6: Signature & Setup
    S6{6. Validate current LoTE Signature}:::decision
    S6 -- Invalid --> F6[Fail: LoTE Sig Verification Failed]:::failure
    S6 -- Valid --> SetupVars[Set Variables:<br/>Current Signer = LoTE-Signer-Cert<br/>Extract Trusted Set from Payload]:::process

    %% Step 7: The Loop
    SetupVars --> S7Check{"7. Is n = 0 (no Pivots)?"}:::decision
    S7Check -- Yes --> S8
    S7Check -- "No (n > 0, Start Loop)" --> LoopStart[Start Pivot Loop i=1 to n]:::process

    subgraph Pivot Validation Chain
        LoopStart --> DownloadPivot[Download Pivot i]:::process
        DownloadPivot --> LinkCheck{Link Check:<br/>Is Current Signer trusted by Pivot i payload?}:::decision
        LinkCheck -- No --> FLink[Fail: Broken Trust Chain]:::failure
        LinkCheck -- Yes --> UpdateSigner[Update Current Signer:<br/>Extract Signer from Pivot i Header]:::process
        UpdateSigner --> SigCheckPivot{Validate Pivot i Signature}:::decision
        SigCheckPivot -- Invalid --> FSigPivot[Fail: Pivot Sig Invalid]:::failure
        SigCheckPivot -- Valid --> LoopNext{i < n ?<br/>More Pivots?}:::decision
    end

    LoopNext -- "Yes (i++)" --> DownloadPivot
    LoopNext -- No --> S8

    %% Step 8: Trust Anchor Validation
    S8{8. Trust Anchor Validation:<br/>Is Final Signer in OJEU-LoTE-Certs-Set?}:::decision
    S8 -- No --> F8[Fail: Not authenticated by OJEU]:::failure

    %% Step 9: Expiration
    S8 -- Yes --> S9{9. Expiration Check:<br/>Now > NextUpdate?}:::decision
    S9 -- Yes --> F9[Fail: LoTE Expired]:::failure

    %% Step 10: Success
    S9 -- No --> Success[10. Validation PASSED]:::success

    %% Steps 11 & 12: Updates
    Success --> UpdateBM[11. Update Local Bookmark OJEU-LoTE-Loc<br/>if changed in payload]:::process
    UpdateBM --> UpdateTA[12. Update Trust Anchor <br/> Config if OJEU moved]:::warning
    UpdateTA --> End([End Process])

    %% Consolidation of failure endpoints
    F3 --> EndFail([Stop: Validation FAILED]):::failure
    F4 --> EndFail
    F6 --> EndFail
    FLink --> EndFail
    FSigPivot --> EndFail
    F8 --> EndFail
    F9 --> EndFail

European Union Member State Trusted List Validation

This section defines the validation of EU Member State Trusted Lists (EUMS TLs). The EUMS TL is an XML artifact signed by a Member State Scheme Operator. In order to validate the EUMS TL, the Wallet Unit or WRP uses the following validation hierarchy:

  1. The Wallet/WRP SHALL first validate the EU List of Trusted Lists (LOTL).
  2. The Wallet/WRP uses the authenticated LOTL to discover and validate the EUMS TL.
European Union Member State Trusted List Retrieval and Validation Sequence Diagram
sequenceDiagram
    participant Client
    participant EU_API as EU LOTL Distribution Point
    participant MS_Repo as MS TL Distribution Point

    Client->>EU_API: Request LOTL (URL from OJEU) 
    EU_API-->>Client: Returns EU List of Trusted Lists (XML)
    Client->>Client: Validate LOTL
    Client->>Client: Parse LOTL to find Target MS TL Pointer & Signing Keys

    Client->>MS_Repo: Request EUMS TL (URL from LOTL)
    MS_Repo-->>Client: Returns EUMS Trusted List (XML)
    Client->>Client: Validate EUMS TL Signature using LOTL certificate

In the diagram above, a Wallet Unit or WRP downloads and validates an EUMS Trusted List by performing the following steps:

  1. requests the LOTL at the location indicated by the URL published in the OJEU;
  2. the LOTL distribution point returns the LOTL XML document;
  3. validates the signature/seal on the downloaded LOTL and verifies its validity;
  4. parses the LOTL to retrieve the location (TSLLocation) and the associated validation certificates (DigitalId) for the target Member State's Trusted List Service Operator.
  5. requests the EUMS TL at the location indicated by the TSLLocation field in the LOTL;
  6. the EUMS TL distribution point returns the EUMS TL XML document;
  7. validates the signature/seal on the downloaded MS TL using the certificates obtained from the LOTL in Step 4.
  8. parses the EUMS TL to retrieve the metadata and public key certificates of the relevant entities (e.g., QEAA Providers, Pub-EAA Providers) and use them as trustworthy Trust Anchors for verifying signatures/seals on QEAAs or Pub-EAAs.

If any of the above verifications fail, the validation process SHALL be aborted and the LoTE SHALL be considered invalid. If all verifications succeed, the Wallet Unit or WRP can parse the EUMS TL to retrieve the metadata and public key certificates of the relevant entities (i.e., QEAA Providers or Pub-EAA Providers) and use them as trustworthy Trust Anchors for verifying signatures/seals on QEAAs or Pub-EAAs.

European Union Member State Trusted List Validation Process

To validate a EUMS TL containing the sought Trust Anchor, the Wallet Unit or Relying Party SHALL validate both the LOTL and the EUMS TL. The validation of the LOTL is a prerequisite for the validation of the EUMS TL, as the Trust Anchor for validating the EUMS TL is obtained from the LOTL.

List of Trusted Lists Validation Process

Remarks: The logic mirrors the LoTE validation but uses XML signatures and TL-specific elements. The validation process is as described in [ETSI TS 119 615].

  • The XML Pivot logic (Step 6) includes a "Self-Consistency Check" not present in the JWT logic due to the fact that the Signature element is not integrity protected.

The Wallet Unit or Relying Party initializes the following input variables for the LOTL validation:

  • OJEU-Loc: URI value referencing the latest publication of the Official Journal of the European Union (OJEU) related to data on EUMS TL.
  • OJEU-LOTL-Loc: URI value representing the location where the last processed instance of the LOTL XML file is available. If not available, this is initialized from the OJEU-Loc publication.
  • OJEU-LOTL-Certs-Set: The set of certificates used to ensure the authenticity and integrity of the LOTL. Initialized from the OJEU-Loc publication.
  • LOTL: The XML file of the LOTL currently being processed. Initialized as null.
  • LOTL-Signer-Cert: Extracted from ds:X509Certificate in the LOTL signature. Initialized as null.
  • LOTLSO-Cert: The certificate of the LOTL Scheme Operator (LOTLSO) extracted from the KeyInfo element of the LOTL signature. Initialized as null.
  • LOTLSO-Cert-Sets: The set of trusted certificates extracted from the PointersToOtherTSL element (with SchemeTerritory = EU) within a LOTL or Pivot file. Initialized as null.

The operations described below produce the following output variables:

  • Authenticated-LOTL: The authenticated XML version of the current instance of the LOTL.
  • LOTL-Status: The status indication of the process of authenticating the current instance of the LOTL.
  • LOTL-Sub-Status: A list of indications supplementing LOTL-Status indication of the process of authenticating the current instance of the LOTL.

The validation operations for the LOTL SHALL perform the following steps (see [ETSI TS 119 615, clause 4.1.4] for reference):

  1. [PRO-4.1.4-1] (Initialization) Set LOTL to the XML file downloaded from OJEU-LOTL-Loc.
  2. [PRO-4.1.4-2] (Parsing) Set LOTL-Signer-Cert to the certificate extracted from the ds:X509Certificate element within the ds:Signature of the LOTL.
  3. [PRO-4.1.4-3, PRO-4.1.4-4] (Pivot Discovery) Iterate through the URIs in the SchemeInformationURI element. Count the number of successive valid XML URIs found before encountering the URI matching OJEU-Loc. Let $n$ be that count. If no URI matches OJEU-Loc, the validation SHALL fail with LOTL-Status set to LOTL_VERIFICATION_FAILED and LOTL-Sub-Status set to OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LOTL.
  4. [PRO-4.1.4-5] (LOTL Location Conflict) Check the condition: OJEU-LOTL-Loc != TSLLocation AND LOTL != Content at TSLLocation.
    • (TSLLocation is the URI in the PointersToOtherTSL element of LOTL with SchemeTerritory = EU).
    • If TRUE: Validation SHALL stop with LOTL-Status set to LOTL_VERIFICATION_FAILED and LOTL-Sub-Status set to LOTL_FILE_CONFLICT.
    • If FALSE: Proceed to the next step.
  5. [PRO-4.1.4-6] (LOTL Freshness) Check the condition: OJEU-LOTL-Loc == TSLLocation AND LOTL != Content at TSLLocation.
    • If TRUE: Set OJEU-LOTL-Loc to TSLLocation and restart from Step 1.
    • If the result is FALSE, proceed to the next step.
  6. [PRO-4.1.4-7] Validate the digital signature of the current LOTL using the public key from LOTL-Signer-Cert.
    • [PRO-4.1.4-8] If validation fails: Stop with LOTL-Status set to LOTL_VERIFICATION_FAILED.
    • [PRO-4.1.4-9] If successful: Set LOTLSO-Cert to LOTL-Signer-Cert. Set LOTLSO-Certs-Set to the certificates found in the PointersToOtherTSL tuple (territory EU) of the current LOTL.
  7. (Intermediate Pivot Validation)
    • [PRO-4.1.4-10] If $n = 0$ (No Pivots):
      • If LOTLSO-Cert is not in OJEU-LOTL-Certs-Set, validation SHALL fail (Signer not authorized by Trust Anchor). Otherwise, proceed to Step 8.
    • [PRO-4.1.4-11] If $n > 0$ (History Chain):
      • Iterate $i$ from 1 to $n$ (from most recent Pivot to oldest). Let Pivot be the file at the $i$-th URI.
      • (Link Check) Set Pivot-Certs-Set to the certificates in the PointersToOtherTSL (territory EU) of Pivot. If LOTLSO-Cert (from the previous step) is not in Pivot-Certs-Set, validation SHALL fail with LOTL-Sub-Status set to PIVOT_i-1_SIGNER_CERT_NOT_AUTHENTICATED_BY_PIVOT_i.
      • (Extract Signer) Set LOTLSO-Cert to the certificate extracted from the signature of Pivot.
      • (Self-Consistency Check) If LOTLSO-Cert is not in Pivot-Certs-Set, validation SHALL fail with LOTL-Sub-Status set to PIVOT_i_SIGNER_CERT_NOT_AUTHENTICATED_BY_PIVOT_i.
      • (Verify Signature) Validate the signature of Pivot using LOTLSO-Cert. If it fails, validation SHALL fail with LOTL-Sub-Status set to PIVOT_i_SIGNATURE_VERIFICATION_FAILED.
      • The loop continues with the new LOTLSO-Cert acting as the input for the next Pivot or the Anchor.
  8. [PRO-4.1.4-12] (Trust Anchor Validation) If LOTLSO-Cert (from the last Pivot) is not in OJEU-LOTL-Certs-Set (the Trust Anchor), validation SHALL fail with LOTL-Sub-Status set to PIVOT_n_SIGNER_CERT_NOT_AUTHENTICATED_BY_OJEU.
  9. [PRO-4.1.4-13] (Expiration) If current time > NextUpdate of LOTL, validation SHALL fail with LOTL-Sub-Status set to LOTL_NEXTUPDATE_PASSED.
  10. [PRO-4.1.4-14, 15] (Success) Set Authenticated-LOTL to LOTL, LOTL-Status to LOTL_VERIFICATION_PASSED.
  11. [PRO-4.1.4-16] (Location Update) If OJEU-LOTL-Loc does not match the TSLLocation in Authenticated-LOTL (territory EU), update OJEU-LOTL-Loc to that value.
  12. [PRO-4.1.4-17] (Update Anchor) [Caution: This step modifies the Root of Trust configuration]
    • If the OJEU-Loc does not match the URI to the first SchemeInformationURI tuple, set the OJEU-Loc variable to that URI.
    • Update OJEU-LOTL-Certs-Set to the certificates found in Authenticated-LOTL (or from the new OJEU publication).
European Union Member State Trusted List Validation Process

The validation operations for the EUMS TL SHALL perform the following steps (see [ETSI TS 119 615, clause 4.2.4] for reference).

Input variables: [PRO-4.2.4-01, PRO-4.2.4-02]

  • Authenticated-LOTL: The authenticated XML version of the current instance of the LOTL obtained from the validation of the LOTL.
  • EUTL-Status: The XML file of the EUMS TL currently being processed. This variable is initialized as null.
  • EUTL-Sub-Status: A list of indications supplementing EUTL-Status indication of the process of authenticating the current instance of the EUMS TL.
  • EUTL: The XML file of the EUMS TL currently being processed. This variable is initialized as null.
  • EUTL-Certs-Set: The full set of certificates used for ensuring authenticity and integrity of the EUMS TL. This variable is initialized as null.
  • EUTL-Signer-Cert: The certificate extracted from the XML signature of the EUMS TL. This variable is initialized as null.

Validation Steps:

  1. [PRO-4.2.4-03] (Parsing) Parse the Authenticated-LOTL to find the TSLLocation field in the PointersToOtherTSL element with SchemeTerritory value matching the target Member State.
  2. [PRO-4.2.4-04] (EUMS TL Download) Download the XML file from the TSLLocation found in the previous step and set the EUTL variable to the downloaded XML file.
  3. [PRO-4.2.4-05, PRO-4.2.4-06] (EUMS TL Parsing) Parse the Authenticated-LOTL to find the X509Certificates tuple in the ServiceDigitalIdentity element of the PointersToOtherTSL element with SchemeTerritory value matching the target Member State, and set the EUTL-Certs-Set variable to the full set of certificates available in that tuple. The set the EUTL-Signer-Cert variable to the certificate extracted from the XML in the ds:X509Certificate element in the ds:KeyInfo element in the Signature element of the EUTL.
  4. [PRO-4.2.4-07, PRO-4.2.4-08, PRO-4.2.4-09] (EUMS TL Integrity and Authenticity Validation)
    • Validate the digital signature of the EUTL using the EUTL-Signer-Cert. If the signature validation fails, or it is undetermined, the validation SHALL fail with EUTL-Status set to EUTL_VERIFICATION_FAILED, and EUTL-Sub-Status set to EUTL_SIGNATURE_VERIFICATION_FAILED.
    • If the signature validation is successful, check that the EUTL-Signer-Cert is in the EUTL-Certs-Set (i.e., the signing certificate of the EUMS TL has not been tampered with). If the check fails, the validation SHALL fail with EUTL-Status set to EUTL_VERIFICATION_FAILED, Authenticated-LOTL set to null, and EUTL-Sub-Status set to EUTLSO_SIGNER_CERT_NOT_AUTHENTICATED_BY_LOTL.
  5. [PRO-4.2.4-10] (EUMS TL Validity Check) Check the NextUpdate field in the EUTL.
    • If the current date/time is greater than the NextUpdate value, the validation SHALL fail with EUTL-Status set to EUTL_VERIFICATION_FAILED, and EUTL-Sub-Status set to WARNING_EUTL_NEXTUPDATE_PASSED.
  6. [PRO-4.2.4-11, PRO-4.2.4-12] If all the above checks are successful, set Authenticated-EUTL to the value of the currently validated EUTL, EUTL-Status to EUTL_VERIFICATION_PASSED, and EUTL-Sub-Status to an empty list.

Below is a flowchart summarizing the above steps for the validation of the EUMS TL:

graph TD
    Start([Start EUMS TL Validation]) --> Init[Initialize Variables:<br/>Authenticated-LOTL<br/>EUTL-Status = null<br/>EUTL = null<br/>EUTL-Sub-Status = null<br/>EUTL-Certs-Set = null<br/>EUTL-Signer-Cert = null]

    %% Step 1: Parse LOTL for Location
    Init --> Step1[Step 1: Parse Authenticated-LOTL<br/>Find TSLLocation for target Member State]
    Step1 --> Step2[Step 2: Download EUMS TL<br/>Set EUTL = Downloaded XML]

    %% Step 3: Parse Certs
    Step2 --> Step3[Step 3: Extract Certificates<br/>1. Set EUTL-Certs-Set from LOTL<br/>2. Set EUTL-Signer-Cert from EUTL Signature]

    %% Step 4: Integrity & Authenticity
    Step3 --> Step4_Sig{Step 4a: Validate EUTL Signature<br/>using EUTL-Signer-Cert}

    %% 4a Failure
    Step4_Sig -- Invalid/Undetermined --> FailSig([FAILED<br/>Status: EUTL_VERIFICATION_FAILED])

    %% 4b Trust Check
    Step4_Sig -- Valid --> Step4_Trust{Step 4b: Trust Check<br/>Is EUTL-Signer-Cert in<br/>EUTL-Certs-Set?}

    %% 4b Failure
    Step4_Trust -- No --> FailTrust([FAILED<br/>Status: EUTL_VERIFICATION_FAILED])

    %% Step 5: Validity Check
    Step4_Trust -- Yes --> Step5_Time{Step 5: Check NextUpdate<br/>Is Current Time > NextUpdate?}

    %% 5 Failure
    Step5_Time -- Yes (Expired) --> FailTime([FAILED<br/>Status: EUTL_VERIFICATION_FAILED])

    %% Step 6: Success
    Step5_Time -- No (Valid) --> Success([SUCCESS<br/>Set Authenticated-EUTL = EUTL<br/>Status: EUTL_VERIFICATION_PASSED])

    %% Styling
    classDef process fill:#e1f5fe,stroke:#01579b,stroke-width:1px;
    classDef decision fill:#fff9c4,stroke:#fbc02d,stroke-width:1px;
    classDef success fill:#dcedc8,stroke:#33691e,stroke-width:2px;
    classDef fail fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px;

    class Init,Step1,Step2,Step3 process;
    class Step4_Sig,Step4_Trust,Step5_Time decision;
    class Success success;
    class FailSig,FailTrust,FailTime fail;

Authentication Process

The Authentication Process enables the Wallet Unit to authenticate a Wallet-Relying Party (WRP) during an interaction. It establishes trust by validating the WRP's X.509 certificate chain—from a trusted Provider of Wallet-Relying Party Access Certificates (WRPAC) down to the presented WRPAC—and verifying the WRP's possession of the corresponding private key.

To authenticate the WRP, the Wallet Unit SHALL verify the authenticity and integrity of the presented WRPAC by performing the following steps:

  1. Retrieve the Trust Anchor: Obtain the Provider of WRPAC's entry from the validated List of Trusted Entities (LoTE) (see Trust Anchor Validation Process). The certificate(s) found in the ServiceDigitalIdentity field of the LoTE's TrustedEntitiesList constitute the Trust Anchor.
  2. Construct the Certification Path: Build a path starting from the certificate issued by the Provider of WRPAC (C_1) and ending with the WRPAC presented by the WRP (C_n). (Note: The simplest path consists of just one certificate, where n=1).
  3. Execute Path Validation: Run the algorithm defined in Wallet Relying Party Access Certificate Path Validation using the retrieved Trust Anchor.
  4. Verify the Signature: Use the public key from the validated WRPAC to verify the WRP's signature on the metadata presented during the specific interaction.

The method by which the WRP presents its WRPAC chain depends on the specific interaction flow:

  • OpenID4VP (Remote Flow): The certificate chain is presented in the x5c field of the WRP-signed Request Object.
  • ISO 18013-5 (Proximity Flow): The certificate chain is presented within the WRP-signed ReaderAuth element of the mdoc request message.
  • OpenID4VCI (Issuance Flow): The certificate chain is presented in the x5c field of the WRP-signed Issuer Metadata.

Mitigating Blind Signing Attacks

Implementers SHALL distinguish between transient authentication (e.g., access control) and content commitment (non-repudiation). To prevent an attacker from disguising a legal commitment (like a debt acknowledgment) as a protocol nonce, the WRP SHALL NOT use the WRPAC private key to sign arbitrary data that could be controlled by an external party.

Wallet Relying Party Authentication Sequence Diagram

Below is a sequence diagram illustrating the Authentication Process, including the retrieval and validation of the LoTE, path construction, and certificate validation steps. The diagram also highlights the decision points for successful or failed authentication.

sequenceDiagram
    participant WRP as WRP (Entity)
    participant Wallet as Wallet Unit
    participant LoTE as LoTE Distribution Point

    WRP->>Wallet: Signed Artifact + WRPAC Chain
    Wallet->>LoTE: Retrieve/Check LoTE
    LoTE-->>Wallet: Return Valid LoTE

    Note over Wallet: 1. Trust Anchor Discovery
    Wallet->>Wallet: Extract Provider of WRPAC Cert (Trust Anchor) from LoTE

    Note over Wallet: 2. Path Construction
    Wallet->>Wallet: Build Path: [Intermediate CAs] -> WRPAC

    Note over Wallet: 3. Validation
    Wallet->>Wallet: Validate Path ([RFC 5280], [RFC 6960])
    Wallet->>Wallet: Verify WRP Artifact Signature

    alt Validation Successful
        Wallet-->>WRP: Proceed with Interaction
    else Validation Failed
        Wallet-->>WRP: Abort / Error Response
    end

Wallet Relying Party Access Certificate Path Validation

This section defines the validation of the certification path.

  • The Trust Anchor is the certificate of the Provider of WRPAC obtained from the LoTE.
  • The Certification Path is the sequence of $n$ certificates ($C_1 \dots C_n$) provided by the WRP, where:
    • $C_1$ is the certificate issued by the Trust Anchor.
    • $C_n$ is the WRPAC (the target certificate).
    • For any $i$ in $1 \dots n-1$, $C_i$ is the issuer of $C_{i+1}$.

The Wallet Unit initializes the validation with:

  • path: The sequence $C_1 \dots C_n$.
  • trust_anchor: The certificate of the Provider of WRPAC.
  • current_time: The current date and time.

Step 1: Initialization Initialize the state variables:

  • valid_policy_tree: A single node (depth 0, valid_policy=anyPolicy, qualifier_set={}, expected_policy_set={ anyPolicy }).
  • explicit_policy (how many certificates in the chain are allowed to lack a specific, valid policy): $n+1$.
  • inhibit_any_policy (how many certificates are allowed to use the anyPolicy OID): $n+1$ (no inhibition of policies allowed).
  • policy_mapping: $n+1$ (no policy mapping allowed).
  • working_public_key: The public key of the trust_anchor.
  • working_public_key_parameters: The parameters of the trust_anchor public key.
  • working_issuer_name: The subject Distinguished Name (DN) of the trust_anchor.
  • max_path_length: $n$.

Step 2: Certificate Processing Iterate through the path for $i$ from $1$ to $n$:

  1. Basic Integrity & Binding Checks:
    • Verify the signature of $C_i$ using working_public_key, working_public_key_parameters, and the algorithm identifier.
    • Ensure current_time falls within the notBefore and notAfter validity period of $C_i$.
    • Check revocation status (CRL or OCSP) as defined in Revocation Checking.
    • Verify that the issuer name of $C_i$ matches working_issuer_name.
  2. Policy Processing:
    • If certificatePolicies extension is present and valid_policy_tree is not NULL:
      • Process policy constraints, qualifiers, and mappings according to [RFC 5280] Section 6.1.3.
      • for each policy $P$ not equal to anyPolicy in the certificate policies extension, let $P$-OID denote the OID for policy $P$ and $P$-Q denote the qualifier set for policy $P$.
        • for each node of depth $i-1$ in the valid_policy_tree where $P$-OID is in the node's expected_policy_set, create a child node with valid_policy $P$-OID, qualifier_set $P$-Q, and expected_policy_set set to {$P$-OID}.
        • If no match is found for $P$-OID in any node of depth $i-1$ and the valid_policy_tree has a node of depth $i-1$ with valid_policy set to anyPolicy, generate a child node with valid_policy $P$-OID, qualifier_set $P$-Q, and expected_policy_set set to {anyPolicy}.
      • if the certificatePolicies extension contains anyPolicy with the qualifier set $AP$-Q, $i \leq n$, and the certificate is self issued, then for each node of depth $i-1$ in the valid_policy_tree and each value in the expected_policy_set of that node, generate a child node with valid_policy and expected_policy_set set to the expected_policy_set value, set the qualifier_set set to $AP$-Q.
      • Update the valid_policy_tree by pruning nodes that do not match the policies in $C_i$.
    • If certificatePolicies is missing, set valid_policy_tree to NULL.
  3. Policy State Verification:
    • Verify that either explicit_policy > 0 OR valid_policy_tree is not NULL. If this fails, abort.

Step 3: Preparation for Next Certificate

  1. If $i < n$ (i.e., $C_i$ is an intermediate CA), perform the following updates:
    • Set working_issuer_name to the Subject DN of $C_i$.
    • Set working_public_key to the Subject Public Key of $C_i$.
    • Update working_public_key_parameters and working_public_key_algorithm from $C_i$.
  2. Constraint Checks (Intermediates Only):
    • Verify basicConstraints extension is present and cA is set to TRUE.
    • If keyUsage extension is present, verify the keyCertSign bit is set.
    • Path Length: Verify max_path_length > 0. Decrement max_path_length by 1.
      • If $C_i$ contains pathLenConstraint, set max_path_length to $\min(\text{current}, \text{pathLenConstraint})$.
  3. Policy Counters:
    • Decrement explicit_policy and inhibit_any_policy (if > 0).

Step 4: Wrap-up After processing $C_n$:

  1. If explicit_policy > 0, decrement it.
  2. If explicit_policy > 0 OR valid_policy_tree is not NULL, the path is VALID.
  3. Otherwise, the path is INVALID.
graph TD
    Start([Start Validation]) --> DefineInputs[Inputs:<br/>path C1..Cn, trust_anchor, current_time]

    %% Step 1: Initialization
    DefineInputs --> Step1[Step 1: Initialization<br/>Initialize state variables:<br/>valid_policy_tree, explicit_policy=n+1,<br/> inhibit_any_policy=n+1, policy_mapping=n+1, <br/> working_public_key,<br/>working_public_key_parameters, <br/> working_issuer_name, max_path_length=n, etc.]
    Step1 --> SetIndex[Set loop index i = 1]

    %% Start Loop
    SetIndex --> LoopCondition{Is i <= n?}

    %% Loop Body - Step 2: Certificate Processing
    LoopCondition -- Yes --> GetCi[Process Certificate Ci]
    GetCi --> Step2_1[Step 2.1: Basic Integrity & Binding Checks<br/><br/>- Verify signature using working_public_key<br/>- Check validity period against current_time<br/>- Check revocation status<br/>- Verify issuer name matches working_issuer_name]

    Step2_1 --> Check2_1{Basic Checks Pass?}
    Check2_1 -- No --> AbortFailure([Validation FAILED])

    Check2_1 -- Yes --> Step2_2[Step 2.2: Policy Processing<br/>- If present, process certificatePolicies<br/>- Update/prune valid_policy_tree based on Ci]

    Step2_2 --> Step2_3[Step 2.3: Policy State Verification<br/>Check if explicit_policy > 0 OR valid_policy_tree is not NULL]

    Step2_3 --> Check2_3{Policy State Verified?}
    Check2_3 -- No --> AbortPolicy([Validation FAILED])

    %% Loop Body - Step 3: Preparation for Next Certificate
    Check2_3 -- Yes --> CheckIntermediate{Is i < n?<br/>Intermediate CA check}

    %% Branch: Intermediate CA (i < n)
    CheckIntermediate -- Yes --> Step3_1[Step 3.1: Update Working State<br/><br/>- Update working_issuer_name from Ci<br/>- Update working_public_key parameters from Ci]
    Step3_1 --> Step3_2[Step 3.2: Constraint Checks<br/>- Verify basicConstraints cA=TRUE<br/>- Verify keyUsage keyCertSign bit<br/>- Verify max_path_length > 0, decrement it<br/>- Handle pathLenConstraint if present]

    Step3_2 --> Check3_2{Constraints Pass?}
    Check3_2 -- No --> AbortConstraints([Validation FAILED])

    Check3_2 -- Yes --> Step3_3[Step 3.3: Policy Counters<br/>Decrement explicit_policy and inhibit_any_policy if > 0]
    Step3_3 --> IncrementIndex

    %% Branch: Target Certificate (i = n) skip Step 3
    CheckIntermediate -- No (Target Cert Cn)--> IncrementIndex[Increment i : i = i + 1]

    %% Loop back
    IncrementIndex --> LoopCondition

    %% Loop Finished - Step 4: Wrap-up
    LoopCondition -- No --> Step4_1[Step 4. Wrap-up<br/>If explicit_policy > 0, decrement it.]
    Step4_1 --> FinalDecision{Final Decision:<br/>Is explicit_policy > 0 OR<br/>valid_policy_tree is NOT NULL?}

    FinalDecision -- Yes --> Success([Path Validation SUCCESSFUL])
    FinalDecision -- No --> Failure([Path Validation FAILED])

    %% Styling
    classDef process fill:#e1f5fe,stroke:#01579b,stroke-width:1px;
    classDef decision fill:#fff9c4,stroke:#fbc02d,stroke-width:1px;
    classDef terminator fill:#dcedc8,stroke:#33691e,stroke-width:2px;
    classDef abort fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px;

    class Step1,SetIndex,GetCi,Step2_1,Step2_2,Step2_3,Step3_1,Step3_2,Step3_3,IncrementIndex,Step4_1 process;
    class LoopCondition,Check2_1,Check2_3,CheckIntermediate,Check3_2,FinalDecision decision;
    class Start,DefineInputs,Success terminator;
    class AbortFailure,AbortPolicy,AbortConstraints,Failure abort;
Revocation Checking

The Wallet Unit SHALL determine the revocation status for every certificate in the path with one of the following methods:

  • If the certificate contains the noRevAvail extension AND the ETSIValAssuredCertMod extension (see Wallet Relying Party Access Certificate Content), revocation checking SHOULD be skipped (as the certificate's status is determined solely by validity period).
  • If the cRLDistributionPoints extension is present, the Wallet Unit MAY retrieve and validate the CRL.
  • If the authorityInfoAccess extension (with id-ad-ocsp) is present, the Wallet Unit MAY perform an OCSP lookup.

For details regarding the formats and parameters of CRLs and OCSP responses, see Revocation Mechanism.

CRL Validation

When using a CRL, the Wallet Unit SHALL:

  1. Verify current_time is between thisUpdate and nextUpdate. If the CRL is expired, the Wallet Unit SHOULD attempt to retrieve an updated CRL.
  2. Verify the CRL is signed by the certificate issuer (or an authorized CRL issuer) by:
    • matching the issuer field of the CRL with the issuer field of the certificate being checked;
  3. Verify the issuingDistributionPoint matches the certificate's distribution point.
    • distributionPoint field of the cRLDistributionPoints extension matches the distributionPoint field of the IssuingDistributionPoint extension of the CRL (if present);
    • if the BasicConstraints extension is present in the certificate being checked, and has cA set to TRUE (respectively FALSE), the CRL Issuing Distribution Point extension SHALL have the onlyContainsCACerts field set to TRUE (respectively have the onlyContainsUserCerts field set to TRUE)
  4. Validate the CRL signature using the issuer's public key. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set.
  5. Check if the certificate's serial number is listed in revokedCertificates. If an entry is found then the certificate status is set to revoked.

Note

In this case it is assumed that the issuer of both the CRL and certificate do coincide, and that the CRL is not signed by a delegated CRL issuer.

If any of the steps 1-4 fail or the CRL is unavailable, the Wallet Unit SHALL consider the certificate status as unknown. When all steps 1-4 succeed and the certificate serial number is not found in the CRL, the certificate SHALL be considered good.

graph TD
    Start([Start CRL Validation]) --> Step1{Step 1: Time Check<br/>Is current_time between<br/>thisUpdate and nextUpdate?}

    %% Step 1: Time Verification and Update Logic
    Step1 -- Yes --> Step2
    Step1 -- No --> FetchUpdate[Attempt to retrieve updated CRL]
    FetchUpdate --> GotUpdate{Update Retrieved?}
    GotUpdate -- Yes --> Step1
    GotUpdate -- No --> Revoked([Certificate status: unknown<br/>Reason: CRL Expired/Unavailable])

    %% Step 2: Issuer Verification
    Step2[Step 2: Verify Issuer] --> CheckIssuer{Does CRL Issuer match<br/>Certificate Issuer?}
    CheckIssuer -- Yes --> Step3
    CheckIssuer -- No --> Revoked2([Certificate status: UNKNOWN<br/>Reason: Issuer Mismatch])

    %% Step 3: Distribution Point Verification
    Step3[Step 3: Verify Distribution Point] --> CheckDP{Do Distribution Points match?}
    CheckDP -- No --> Revoked3([Certificate status: UNKNOWN<br/>Reason: Distribution Point Mismatch])
    CheckDP -- Yes --> CheckBasicConstraints{Check BasicConstraints}

    CheckBasicConstraints -- Certificate<br/>has `CA=TRUE` --> CheckCRL_CA{Is CRL onlyContainsCACerts=TRUE?}
    CheckBasicConstraints -- Certificate defaults<br/>to `CA=FALSE` --> CheckCRL_User{Is CRL onlyContainsUserCerts=TRUE?}

    CheckCRL_CA -- No --> Revoked3
    CheckCRL_User -- No --> Revoked3
    CheckCRL_CA -- Yes --> Step4
    CheckCRL_User -- Yes --> Step4

    %% Step 4: Signature & Key Usage
    Step4[Step 4: Signature & Key Usage] --> ValidateSig{Validate CRL Signature}
    ValidateSig -- Invalid --> Revoked4([Certificate status: UNKNOWN<br/>Reason: Invalid CRL Signature])
    ValidateSig -- Valid --> CheckKeyUsage{If KeyUsage present:<br/>Is cRLSign bit set?}
    CheckKeyUsage -- No --> Revoked4
    CheckKeyUsage -- Yes --> Step5

    %% Step 5: Revocation Lookup
    Step5[Step 5: Revocation Lookup] --> LookupSerial{Is Certificate Serial Number<br/>in revokedCertificates?}

    LookupSerial -- Yes --> Revoked5([Certificate status: REVOKED])
    LookupSerial -- No --> Valid([Certificate status: GOOD])

    %% Styling
    classDef process fill:#e1f5fe,stroke:#01579b,stroke-width:1px;
    classDef decision fill:#fff9c4,stroke:#fbc02d,stroke-width:1px;
    classDef valid fill:#dcedc8,stroke:#33691e,stroke-width:2px;
    classDef revoked fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px;

    class Start,FetchUpdate,Step2,Step3,Step4,Step5 process;
    class Step1,GotUpdate,CheckIssuer,CheckDP,CheckBasicConstraints,CheckCRL_CA,CheckCRL_User,ValidateSig,CheckKeyUsage,LookupSerial decision;
    class Valid valid;
    class Revoked,Revoked2,Revoked3,Revoked4,Revoked5 revoked;
OCSP Response Validation

When using OCSP, the Wallet Unit SHALL:

  1. Verify responseStatus is successful (0). If the responseStatus is not successful, the Wallet Unit SHOULD attempt to retrieve an updated OCSP response, and if that fails, the certificate status SHALL be considered unknown.
  2. Verify responseType is id-pkix-ocsp-basic.
  3. Verify the response signature using the Responder's public key (certs field in the OCSP response).
    • Note: To ensure the OCSP Responder is authorized, match the Issuer's key or check the delegation certificate signed by the Issuer.
  4. Verify responderID matches the signer, and the CertID hash fields match the certificate being checked.
    • issuerNameHash field value is the hash (via hashAlgorithm) of the DER encoding of the issuer’s Name.
    • issuerKeyHash field value is the hash (via hashAlgorithm) of the issuer’s subjectPublicKey BIT STRING (excluding tag/length/unused-bits).
    • serialNumber field value is the certificate’s serial number.
  5. Check thisUpdate and nextUpdate (or producedAt) against local freshness policies.

Note

It is assumed that only basic OCSP responses (i.e., where responseType is id-pkix-ocsp-basic) are supported.

If any of the checks in 2-4 fail, the certificate status SHALL be considered unknown. If all checks succeed, update the status of each certificate by matching the certStatus value in the SingleResponse to the requested CertID.

graph TD
    Start([Receive OCSP Response]) --> Step1{Step 1: Verify response Status}

    %% Step 1: Status Verification & Retry Logic
    Step1 -- "Status == successful (0)" --> Step2{"Step 2: Verify response Type"}
    Step1 -- "Status != successful" --> Retry{Retry Available?}

    Retry -- Yes --> FetchNew[Attempt to retrieve<br/>updated OCSP response]
    FetchNew --> Step1
    Retry -- No --> StatusUnknown([Certificate Status: UNKNOWN])

    %% Step 2: Response Type
    Step2 -- "id-pkix-ocsp-basic" --> Step3["Step 3: Verify Signature & Auth"]
    Step2 -- Other --> Invalid([Certificate Status: UNKNOWN<br/>Reason: Invalid Response Type])

    %% Step 3: Signature Verification
    Step3 --> CheckSig{Signature Valid?}

    CheckSig -- Yes --> Step4["Step 4: Verify ResponderID & CertID"]
    CheckSig -- No --> InvalidSig([Certificate Status: UNKNOWN<br/>Reason: Invalid Signature])

    %% Step 4: ID Matching
    Step4 --> CheckIDs{Do IDs Match?}

    CheckIDs -- Yes --> Step5["Step 5: Check Freshness"]
    CheckIDs -- No --> InvalidIDs([Certificate Status: UNKNOWN<br/>Reason: ID Mismatch])

    %% Step 5: Freshness
    Step5 --> CheckTime{"Time Check<br/>Is current_time between<br/>thisUpdate and nextUpdate?"}

    CheckTime -- No --> Stale([Certificate Status: UNKNOWN<br/>Reason: OCSP Response Expired])
    CheckTime -- Yes --> ProcessStatus[Parse SingleResponse certStatus]

    %% Final Status Mapping
    ProcessStatus --> CheckCertStatus{Check certStatus Value}
    CheckCertStatus -- good --> StatusGood([Certificate Status: GOOD])
    CheckCertStatus -- revoked --> StatusRevoked([Certificate Status: REVOKED])
    CheckCertStatus -- unknown --> StatusUnknownResponse([Certificate Status: UNKNOWN])

    %% Styling
    classDef process fill:#e1f5fe,stroke:#01579b,stroke-width:1px;
    classDef decision fill:#fff9c4,stroke:#fbc02d,stroke-width:1px;
    classDef outcome fill:#dcedc8,stroke:#33691e,stroke-width:2px;
    classDef fail fill:#ffcdd2,stroke:#b71c1c,stroke-width:2px;

    class Start,FetchNew,Step3,Step4,Step5,ProcessStatus process;
    class Step1,Step2,Retry,CheckSig,CheckIDs,CheckTime,CheckCertStatus decision;
    class StatusGood outcome;
    class Invalid,InvalidSig,InvalidIDs,Stale,StatusRevoked,StatusUnknown,StatusUnknownResponse fail;

Authorization Process

This section specifies the authorization process that a Wallet Instance (WI) SHALL execute to determine whether an interaction with a Wallet-Relying Party (WRP) is allowed within the EUDI Wallet ecosystem. A Wallet Instance SHALL implement all the authorization-processing rules defined in this section [AUTHZ-GEN-03].

Authorization covers:

Note

Authentication process is out of scope. This section does not define access certificate validation rules, LoTE validation procedures, certificate-path validation algorithms, revocation checking procedures for access certificates, the full trust-anchor validation model, nor the internal structure and encoding of the WRPRC (covered in section Wallet-Relying Party Registration Certificate), nor Registrar online service API definition.

Preconditions

The authorization process SHALL start only after the WRP has been successfully authenticated according to the applicable specifications (see section Authentication Process) [AUTHZ-GEN-01]. If the WRP has not been authenticated, the authorization process SHALL NOT start [AUTHZ-GEN-02]. This section does define how the WI SHALL use the already-authenticated WRP context as an input to authorization, including binding checks between the authenticated WRP, the authorization subject, and the WRPRC or Register-derived authorization context.

Authorization Framework

This subsection defines the conceptual model that defines all authorization decisions. It introduces the key concepts (authorization subject, data source hierarchy, decision outcomes, and override principles) that the subsequent subsections build upon.

Authentication Prerequisite and Authorization Subject

The WI SHALL distinguish between the authenticated WRP and the authorization subject [AUTHZ-GEN-04]. The authorization subject is the entity whose authorization is being evaluated:

  • In issuance: the PID Provider or AP.
  • In direct presentation: the RP.
  • In intermediated presentation: the final (intermediated) RP. The authenticated WRP in this case is the intermediary.
Source-Model Neutrality

The WI SHALL support authorization-context resolution from a WRPRC (where available) and from the Register (where a WRPRC is not available or cannot be relied upon) [AUTHZ-GEN-05]. The substantive authorization logic SHALL NOT change based on the data source [AUTHZ-GEN-06]. Where both sources are available, the WI SHALL normalize both into the same internal authorization model before applying rules [AUTHZ-GEN-07].

Input Model

The WI SHALL base authorization decisions only on information derived from [AUTHZ-IN-01]:

  • Already authenticated WRP context.
  • A verified WRPRC or a verified Register response.
  • Explicitly identified self-declared fallback information.
  • A verified EDP, if provided by AP during issuance.

The WI SHALL maintain an internal distinction between the following input classes [AUTHZ-IN-02]:

  • Authenticated WRP context: authoritative only for the identity of the WRP [AUTHZ-IN-03].
  • Verified WRPRC-derived or Register-derived information: authoritative for subject identity, entitlements, intended use, registered scope, intermediary relationship, issuance-type information, and privacy-policy references [AUTHZ-IN-04 and AUTHZ-IN-05].
  • Self-declared information: non-authoritative. The WI SHALL NOT rely solely on self-declared information for checks that require registered information [AUTHZ-IN-06].
  • Verified EDP: authoritative only if available. The WI SHALL rely on RP information to determine access permission [AUTHZ-EDP-06].

Where authoritative sources conflict with non-authoritative sources, the authoritative sources SHALL supersede [AUTHZ-IN-07]. Where the authenticated WRP context conflicts with the identity or intermediary binding in the verified authorization context, the WI SHALL produce NOT_AUTHORIZED (non-overridable) [AUTHZ-IN-08].

A request-carried Registrar URL SHALL NOT be treated as sufficient proof of registered information by itself; it MAY be used only as a discovery hint unless confirmed by an authoritative source [AUTHZ-IN-09].

Decision Model

The WI SHALL provide an authorization decision expressed as AUTHORIZED or NOT_AUTHORIZED [AUTHZ-UI-01].

Each evaluation procedure (defined later in this section) gives a granular verification result code when it detects a negative condition. These codes feed into the final decision and into the advisories presented to the User.

Code Phase Meaning
CERTIFICATE_INVALID Both WRPRC validation failed
FAILED Both Registration data could not be obtained or verified
WRONG_ENTITLEMENT Both Entity entitlement does not match expected role
ATTESTATION_TYPE_NOT_REGISTERED Issuance Requested attestation type is not in registered list
BINDING_FAILED Both Authorization subject does not match authenticated identity
INTERMEDIARY_NOT_AUTHORIZED Presentation Intermediary association verification failed
VERIFICATION_PASSED Presentation All requested attributes are registered
OVERASKING_DETECTED Presentation Some requested attributes are not registered
EDP_SATISFIED Presentation Embedded Disclosure Policy conditions met
EDP_NOT_SATISFIED Presentation Embedded Disclosure Policy conditions not met

The authorization process SHALL support transparent decision-making and SHALL NOT be a purely hidden backend check [AUTHZ-UI-05].

Override Principles

A NOT_AUTHORIZED decision can be either non-overridable (the WI blocks the interaction) or overridable (the WI presents the negative outcome and the User can choose to proceed).

In issuance phase, all negative verification outcomes are non-overridable: the WI protects the User from providers whose registration cannot be confirmed (per ISSU_24a, ISSU_34a, ISSU_34b).

In presentation phase, two specific cases are overridable:

  1. Negative scope comparison (per RPRC_21: the User is informed of unregistered attributes but can proceed).
  2. Negative EDP evaluation (per EDP_07: the User can deny or allow).

All other presentation failures (binding failures and intermediary binding failures) are non-overridable because they indicate an integrity problem rather than a user-facing choice.

In case of non-overridable failures, the WI SHALL clearly inform the User about the negative outcome. User-relevant information about overridable outcomes SHALL be presented as advisories, and the User approval SHALL be a separate step from the authorization decision [AUTHZ-UI-02, AUTHZ-UI-03, AUTHZ-UI-04].

User opt-in

The Scope Comparison Procedure is executed only if the User enabled registration verification (RPRC_16). Override mechanisms define what happens when the procedure produces a negative result.

The detailed override rules are provided in the Override Rules section.

Authorization Evidences

This section describes the data objects that carry authorization information such as where they originate, how they are distributed, and what parameters are relevant for authorization decisions. The evaluation procedures that operate on these data objects are defined in the section Evaluation Procedures.

Registration Overview

WRPs are registered with a Registrar in their Member State before operating in the EUDI Wallet ecosystem. Relying Parties declare one or more intended uses, each with a user-friendly description, the attestation type and optionally the list of attributes needed, the purpose, and a privacy policy link. A WRPRC is issued for each intended use (RPRC_09). Attestation Providers declare which Attestation types they intend to issue (RPRC_15, RPRC_22a). Intermediaries are registered as RPs that act on behalf of other RPs; the WRPRC of the intermediated RP contains the intermediary structure identifying the authorized intermediary per [ETSI TS 119 475, Table 10].

Data Object Lifecycle

The following diagram shows the authorization evidences and how they flow between the entities in the ecosystem.

graph LR
    subgraph Entities
    AP([Attestation Provider])
    RP([Relying Party])
    REG([Registrar])
    WI([Wallet Instance])
    WRPRC_PROV([Provider of WRPRCs])
    end

    subgraph Authorization Evidences
    REGDATA[Registration Data]
    WRPRC_OBJ[WRPRC]
    EDP_OBJ[Embedded Disclosure Policy]
    end

    subgraph Transport Structures
    META[Credential Issuer Metadata<br/>issuer_info array]
    PRES[Presentation Request<br/>verifier_info / euWrprc]
    end

    REGDATA -.created by.-> REG
    REGDATA -.input to.-> WRPRC_PROV
    REGDATA -.queried from register by.-> WI
    WRPRC_OBJ -.issued by.-> WRPRC_PROV
    WRPRC_OBJ -.verified by.-> WI
    WRPRC_OBJ -.included in.-> PRES
    WRPRC_OBJ -.included in.-> META
    EDP_OBJ -.defined by.-> AP
    EDP_OBJ -.stored and evaluated by.-> WI
    EDP_OBJ -.included in.-> META
    META -.published by.-> AP
    PRES -.created by.-> RP
    PRES -.sent to.-> WI
    META -.fetched by.-> WI

classDef ent fill:#90ee90,stroke:#228b22,stroke-width:1px;
classDef obj fill:#ffe1e1,stroke:#333,stroke-width:2px;
classDef transport fill:#fafad2,stroke:#d4c368,stroke-width:1px;

class AP,RP,WRPRC_PROV,REG,WI ent
class REGDATA,WRPRC_OBJ,EDP_OBJ obj
class META,PRES transport

Registration data is collected at the Registrar and the Provider of WRPRCs get it from Registrar to provide it through a WRPRC. Registration data can also be queried directly by the WI using Registrar online services as a fallback mechanism. WRPRCs are distributed to the WI through presentation requests (for RPs) or through Credential Issuer Metadata (for APs). EDPs are defined by the AP, distributed through Credential Issuer Metadata, stored locally by the WI during issuance, and evaluated at presentation time.

WRPRC Parameters for Authorization

The following table lists the WRPRC payload parameters used in authorization processing, with field names as defined in [ETSI TS 119 475] V1.2.1 section 5.2.4. Details about the WRPRC data structure and lifecycle are provided in section Wallet-Relying Party Registration Certificate. The Authorization Use column indicates how each parameter is consumed: Decision rule means the WI enforces an automated check, User transparency means the information is displayed to support the User's decision, and Wallet operation means the WI uses it internally (e.g. for fallback query).

Field Applicability Authorization Use Reference
sub WRPs (REQUIRED) Decision rule: binding verification; entity identification for EDP evaluation [ETSI TS 119 475, Table 7] RPRC_07
sub_ln WRPs (REQUIRED) User transparency: legal name displayed to User [ETSI TS 119 475, Table 7], [CIR 2025/848, Annex I.1]
name WRPs (OPTIONAL) User transparency: trade name displayed to User [ETSI TS 119 475, Table 7], [CIR 2025/848, Annex I.2]
entitlements WRPs (REQUIRED) Decision rule: entitlement verification against expected role [ETSI TS 119 475, Table 7, Annex A.2] ISSU_24a, ISSU_34a
srv_description WRPs (REQUIRED) User transparency: service description displayed to User [ETSI TS 119 475, Table 7], [CIR 2025/848, Annex I.8]
registry_uri WRPs (REQUIRED) Wallet operation: Registrar URL for fallback query [ETSI TS 119 475, Table 7] RPRC_18
support_uri WRPs (REQUIRED) User transparency: support contact for rights and data deletion [ETSI TS 119 475, Table 7], [CIR 2025/848, Annex I.7(a)]
supervisory_authority WRPs (REQUIRED) User transparency: DPA information displayed to User [ETSI TS 119 475, Table 7], [CIR 2025/848, Annex IV.3(g)]
public_body WRPs (OPTIONAL) User transparency: public sector identification shown to User [ETSI TS 119 475, Table 10], [CIR 2025/848, Annex I.11]
privacy_policy RPs (REQUIRED if IntendedUse is present) User transparency: privacy policy link displayed to User [ETSI TS 119 475, Table 9]
purpose RPs (REQUIRED if IntendedUse is present) User transparency: purpose description displayed to User [ETSI TS 119 475, Table 9] RPRC_18
intended_use_id RPs (OPTIONAL) Wallet operation: Registrar query key for intended-use lookup [ETSI TS 119 475, Table 9] RPRC_19a
credentials[] RPs (OPTIONAL) Decision rule: scope comparison bertween claim[] paths and meta.vct_values/doctype_value and requested attributes [ETSI TS 119 475, Table 9] RPRC_09, RPRC_21
provides_attestations[] APs (REQUIRED) Decision rule: attestation type verification of registered types against requested type during issuance [ETSI TS 119 475, Table 8] RPRC_15, RPRC_23, ISSU_34b
intermediary WRPs (OPTIONAL) Decision rule: intermediary.sub used to check against authenticated intermediary identity [ETSI TS 119 475, Table 10], [CIR 2025/848, Annex I.14]
status WRPs (REQUIRED) Decision rule: WRPRC revocation check via Status List [ETSI TS 119 475] GEN-6.2.6.1-04, RPRC_17
iat / exp WRPs (REQUIRED) Decision rule: temporal validity check [ETSI TS 119 475]
Distribution Methods

Presentation flows. RPs include the WRPRC in the presentation request by value (RPRC_19) in the:

  • verifier_info parameter included in the Request Object JWT within the authorization request (remote flow, [ETSI TS 119 472-2] and [OpenID4VP] section 5.1). This is an array of JSON Objects containg WRPRC in base64-encoded format and RPRC_19a data including the URL of Registrar online service.
  • euWrprc (CBOR byte string with serialized WRPRC) member of requestInfo included in the ISO DeviceRequest (proximity flow, [ETSI TS 119 472-2] section 5.3).

Warning

Currently, the mapping of RPRC_19a data in the requestInfo map is not defined in [ETSI TS 119 472-2]

Issuance flow. APs include authorization data in Credential Issuer Metadata through the issuer_info array ([ETSI TS 119 472-3] section 4.2.3). This array contains:

  • An element with format "registration_cert" containing the WRPRC by value (ISS-MDATA-REG_CERT-4.2.3-04/05) (OPTIONAL).
  • An element with format "registrar_dataset" containing self-declared registration information including identifier, srvDescription, registryURI, and providesAttestations (ISS-MDATA-REG_CERT-4.2.3-07 through 13) (REQUIRED).

Metadata is signed with the AP WRPAC private key (ISSU_22a). Authorization data cointained in the EDP is also distributed through Credential Issuer Metadata within credential_configurations_supported field.

Registrar Online Service

Each Registrar provides an online service accessible via URL, obtained as described in the Distribution Methods section.

The WI SHALL use this service when the WRPRC is not available or validation fails. The service is queried using the entity unique identifier and, for presentation, the intended_use_id. The response provides the same authorization-relevant data as a WRPRC. Registrar online service is available through an API interface which is defined in TS5.

Note

The WI SHOULD inform the User that an external query will be made (privacy consideration per RPRC_18).

Embedded Disclosure Policy

The EDP is a set of rules defined by the AP that restricts which RPs can access specific Attestations. The EDP definition, data model, structure, encoding, and lifecycle are specified in the dedicated Embedded Disclosure Policy section of this specification.

For authorization purposes, the following aspects are relevant:

  • EDPs are applicable to QEAAs, PuB-EAAs, and non-qualified EAAs. They are not applicable to PIDs [AUTHZ-EDP-01].
  • During issuance, when the User confirms, the WI SHALL retrieve and store locally the EDP if present in the Credential Issuer Metadata [AUTHZ-EDP-02].
  • At presentation time, for each Attestation matching a request, the WI SHALL check its locally stored EDP and evaluate it against the requesting RP according to the EDP Evaluation Procedure defined in this section.
  • Annex III of [CIR 2024/2979] defines three policy types that the WI SHALL support. In particular:
    • No Policy.
    • Authorized Relying Parties Only.
    • Specific Root of Trust.

Evaluation Procedures

This section defines the individual verification procedures that are composed into end-to-end flows in the Operational Flows section. Each procedure is self-contained: it specifies its inputs, its processing logic, and its output (a verification result code). The override behaviour for each procedure's negative outcome is detailed in the Override Rules section.

WRPRC Validation Procedure

When a WRPRC is available, the WI SHALL validate it before relying on it [AUTHZ-GEN-08]:

  1. Format verification: confirm typ is rc-wrp+jwt (remote) or rc-wrp+cwt (proximity) ([ETSI TS 119 475] section 5.2.1).
  2. Algorithm verification: verify the conformance of signature algorithm (neither "none" nor deprecated).
  3. Signature and Certificate chain validation: verify the WRPRC signature and validate the chain.
  4. Trust anchor resolution: fetch the trust anchor for the Provider of WRPRCs from LoTE. The WI SHALL accept Trust Anchors from all Provider of WRPRCs LoTE (ISSU_33a).
  5. Temporal validity: check iat and exp (if present).
  6. Status verification: check revocation status via the status field (RPRC_17).
  7. Coherence check: verify WRPRC subject and fields are coherent with the scenario [AUTHZ-GEN-09].

If any step fails, the procedure outputs CERTIFICATE_INVALID. This is not a final authorization decision; it triggers the Register Validation Procedure as fallback.

Register Validation Procedure

When the WRPRC is not available or validation has failed, the WI SHALL attempt to contact the Register APIs [AUTHZ-GEN-10]:

  1. Extract Registrar URL from the presentation request (verifier_info in remote scenario or requestInfo in proximity scanario) during presentation flow, or from Credential Issuer Metadata (issuer_info.registry_uri) during issuance flow. See Distribution Methods section for details.
  2. Connect to the Registrar online service using HTTPS.
  3. Query using entity identifier and intended_use_id (presentation) or AP identifier (issuance).
  4. Verify response signature: the WI SHALL verify the signature of the response data according to TS5.
  5. Resolve Registrar trust chain: the WI SHALL resolve the trust chain of the signing certificate and verify that the Registrar Trust Anchor is contained in the applicable Registrar LoTE.
  6. Verify pertinence: the WI SHALL verify that the response pertains to the relevant authorization subject and intended use [AUTHZ-REG-01], [AUTHZ-REG-02].
  7. Normalize Register-derived data into the same internal model used for WRPRC data [AUTHZ-REG-03].

If the URL is not present, connection fails, or validation fails, the procedure outputs FAILED [AUTHZ-REG-04].

Three-tier fallback (issuance only) (ISSU_24a and ISSU_34a): self-declared data from registrar_dataset (advisory only, SHALL NOT be presented as verified) [AUTHZ-IN-10].

Binding Verification Procedure

The WI SHALL verify coherence between the authenticated WRP identity and the authorization context, regardless of whether the authorization context is derived from a WRPRC or from the Register [AUTHZ-GEN-11]. This procedure ensures that the authenticated entity (through WRPAC) is the same as the entity described in the authorization data.

Common Principle

The WI SHALL compare the WRP identifier extracted from the WRPAC subject (the organizationIdentifier in the subject DN, following [ETSI EN 319 412-1, clause 5.1.4]) against the authorization subject identifier available from:

  • the WRPRC sub field (if available).
  • The authorization data (RPRC_19a) extracted from authentication request (verifier_info or requestInfo) in presentation scenario or in registrar_dataset field in issuance scenario.
  • The Register response (if queried).

All available sources SHALL be mutually consistent.

Issuance Binding

During issuance, the WI SHALL verify that the AP that signed the Credential Issuer Metadata (identified by the WRPAC in the x5c header of the JWS) is the same entity described in the authorization data [AUTHZ-GEN-11]. The WI SHALL check coherence between:

  • The AP identifier from the WRPAC subject (extracted during metadata signature verification).
  • The sub field from the WRPRC in issuer_info (if present).
  • The identifier field from the registrar_dataset element in issuer_info (if present).

If any pair of these identifiers is inconsistent, the procedure outputs BINDING_FAILED. Intermediary detection does not apply to issuance.

Presentation Binding -- Intermediary Detection

In presentation, before verifying binding, the WI SHALL check whether the interaction is direct or intermediated [AUTHZ-INT-01] by comparing:

  • The authenticated WRP identifier, extracted from the WRPAC subject DN.
  • The claimed RP identifier, extracted from the presentation request fields according to RPRC_19a (item b). Following RPI_06, in an intermediated scenario these fields pertain to the intermediated RP.

If the two identifiers match, the direct RP scenario applies. If they differ, the intermediary scenario applies.

Direct RP Binding

In the direct RP scenario, the WI SHALL verify that the WRPRC (if present in verifier_info or requestInfo) is coherent with the already-established identities [AUTHZ-GEN-12]:

  • The WRPRC sub field SHALL match the authenticated WRP identifier and the claimed RP identifier from authorization data (RPRC_19a).

If the WRPRC sub does not match, the WRPRC is not valid for this RP. The procedure outputs BINDING_FAILED and the WI SHALL discard the WRPRC and fall back to the Register Validation Procedure.

Intermediary Binding

In the intermediary scenario, the WI SHALL perform the following verifications [AUTHZ-INT-02]:

Step 1: Identify the parties. The WI identifies:

  • The intermediary: the entity authenticated via WRPAC. Its identifier is extracted from the WRPAC subject DN.
  • The intermediated (final) RP: the authorization subject. Its identifier and other data are obtained from the WRPRC sub field and/or from the presentation request fields.

Step 2: Verify intermediary association. The WI SHALL verify that the intermediary is authorized to act on behalf of the intermediated RP. The verification depends on the available data source:

  • If a valid WRPRC is available: the WRPRC of the intermediated RP SHALL contain the intermediary structure (per [ETSI TS 119 475] Table 10). The WI SHALL verify that intermediary.sub matches the authenticated intermediary identifier from the WRPAC. The presence of the intermediary field in the WRPRC, signed by the Provider of WRPRCs, is authoritative evidence that the relationship is registered.
  • If the WRPRC is not available or invalid: the WI SHALL query the Register using the intermediated RP identifier (from RPRC_19a item b) and verify in the Register response that the authenticated intermediary is listed as an authorized intermediary for that RP.
  • If both WRPRC and Register verification fail: the WI SHALL NOT confirm the intermediary relationship.

On failure of intermediary association verification, the procedure outputs SHALL be INTERMEDIARY_NOT_AUTHORIZED [AUTHZ-INT-03].

Step 3: Verify authorization subject coherence. The WI SHALL additionally verify that the intermediated RP identifier is consistent across all available sources: the WRPRC sub field (if available), the presentation request fields per RPRC_19a, and the Register response (if queried). If any inconsistency is found, the procedure SHALL output BINDING_FAILED.

Step 4: Apply authorization context. Once the intermediary association is confirmed, all subsequent authorization checks (entitlement verification, scope comparison, EDP evaluation) SHALL use the intermediated RP data, not the intermediary data [AUTHZ-INT-02].

Step 5: Display both identities. The WI SHALL display to the User both the intermediary identity and the intermediated RP identity (RPI_07). The display SHOULD follow the pattern: "[intermediary name] acting on behalf of [intermediated RP name] for [intended use description]". The names are obtained from:

  • Intermediary: intermediary.sname from the WRPRC, or the intermediary name from the Register response.
  • Intermediated RP: name (or sub_ln) from the WRPRC, or the RP name from the presentation request fields per RPRC_19a (item a), or the Register response.

If any name is not available, the WI SHALL display the identifier instead of the name.

Warning

[ETSI TS 119 475, Table 10] defines the intermediary name subfield > as sname. The example in Annex C of the same standard uses name instead. This specification follows the normative Table 10 and uses sname.

Note

The Registrar online service API, including the specific parameters for querying intermediary relationships, is defined in TS5. This specification does not define the Register API; it only defines how the WI uses the Register response for authorization purposes.

Entitlement Verification Procedure

The WI SHALL verify that the entitlements of the authorization subject match the expected role [AUTHZ-GEN-13].

For issuance, the expected entitlement depends on the provider type:

Request type Expected entitlement URI
PID https://uri.etsi.org/19475/Entitlement/PID_Provider
QEAA https://uri.etsi.org/19475/Entitlement/Q_EAA_Provider
PuB-EAA https://uri.etsi.org/19475/Entitlement/PuB_EAA_Provider
Non-qualified EAA https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider

For presentation, the expected entitlement is https://uri.etsi.org/19475/Entitlement/Service_Provider.

If the entitlements array does not contain the expected value, the procedure SHALL output WRONG_ENTITLEMENT.

Attestation Type Verification Procedure (Issuance Only)

The WI SHALL verify that the PID or Attestation type being requested is registered for the provider [AUTHZ-ISS-02]:

  • For PID Providers issuing PIDs, the WI MAY skip this step.
  • Otherwise, the WI SHALL match the provides_attestations[] array against the credential_configurations_supported keys in Credential Issuer Metadata. Matching SHALL be case-sensitive and exact (vct_value for SD-JWT VC, doctype for mDL).

If not found, the procedure SHALL output ATTESTATION_TYPE_NOT_REGISTERED.

Scope Comparison Procedure (Presentation Only, user-optional)

The WI SHALL [AUTHZ-PRES-01]:

  1. Extract requested attributes: from credential_queries[].claims[] (remote/DCQL) or from namespaces (proximity).
  2. Compare against registered scope: match credentials[].claim[] and credentials[].meta.vct_values or doctype_value in the authorization context. Matching SHALL be case-sensitive and exact.

If all match, the WI SHALL output VERIFICATION_PASSED. Otherwise, the WI SHALL output OVERASKING_DETECTED and identify the unregistered attributes [AUTHZ-PRES-02].

EDP Evaluation Procedure

For each Attestation matching a presentation request, the WI SHALL check for a locally stored EDP [AUTHZ-EDP-03]. If no EDP exists, the Attestation is allowed (subject to User approval). Otherwise:

In case of Authorized Relying Parties Only policy type [AUTHZ-EDP-04]:

  • Detect intermediary scenario.
  • Extract the identity information of the RP (direct) or intermediated RP. The WI SHALL NOT use intermediary identity.
  • Match against the authorized_parties list: compare the RP subject DN from WRPAC against subject_dn entries, and/or compare the RP entitlements or sub-entitlements from WRPRC against entitlement_uri entries. A match on either criterion is sufficient.

If the checks are successful, the WI SHALL provide EDP_SATISFIED as output result, otherwise the WI SHALL provide EDP_NOT_SATISFIED.

In case of Specific Root of Trust policy type [AUTHZ-EDP-05] and according to direct/intermediary scenario:

  • For direct RP, the WI SHALL extract issuer DN and serial number from the root or intermediate certificates in the WRPAC chain.
  • For intermediary, the WI SHALL retrieve root certificate information of the Provider of WRPRCs for the intermediated RP. Then, the WI SHALL compare against the trusted_roots list and match issuer_dn using LDAP DN comparison and serial_number using integer comparison (as defined ISS-MDATA-EBD-4.2.5.2-09). If the check is satisfied, the WI SHALL output: EDP_SATISFIED or EDP_NOT_SATISFIED.

The WI SHALL evaluate EDP together with RP information to determine access permission (EDP_06) [AUTHZ-EDP-06]. If EDP_SATISFIED, the WI SHALL allow the Attestation presentation (subject to User approval) and display explanatory link if present (EDP_05) [AUTHZ-EDP-07]. If EDP_NOT_SATISFIED, the WI SHALL produce NOT_AUTHORIZED, present the outcome, and allow User override (EDP_07) [AUTHZ-EDP-08]. If the User denies, the WI SHALL behave as if the Attestation does not exist (RPA_11).

Override Rules

This section details the override behaviour for each procedure when it provides a negative outcome. Each row identifies a procedure, the phase in which it applies, the result code produced on failure, and whether the User can override that outcome.

Evaluation Procedure Phase Negative Outcome User Override
WRPRC Validation Both CERTIFICATE_INVALID It triggers Register Validation as fallback. User is not involved
Register Validation Issuance FAILED Non-overridable [AUTHZ-ISS-01], [AUTHZ-UI-06]
Register Validation Presentation FAILED Overridable. Advisory to User [AUTHZ-PRES-06]
Binding Verification Issuance BINDING_FAILED Non-overridable [AUTHZ-UI-06]
Binding Verification (direct RP) Presentation BINDING_FAILED Non-overridable [AUTHZ-UI-06]
Binding Verification (intermediary) Presentation INTERMEDIARY_NOT_AUTHORIZED Non-overridable [AUTHZ-INT-03], [AUTHZ-UI-06]
Entitlement Verification Issuance WRONG_ENTITLEMENT Non-overridable [AUTHZ-ISS-01], [AUTHZ-UI-06]
Entitlement Verification Presentation WRONG_ENTITLEMENT Overridable. Advisory to User
Attestation Type Verification Issuance ATTESTATION_TYPE_NOT_REGISTERED Non-overridable [AUTHZ-ISS-03], [AUTHZ-UI-06]
Scope Comparison Presentation OVERASKING_DETECTED Overridable. Advisory to User [AUTHZ-PRES-02]
EDP Evaluation Presentation EDP_NOT_SATISFIED Overridable. User can deny or allow [AUTHZ-EDP-08]

Operational Flows

This section combines the evaluation procedures defined above into end-to-end flows for issuance and presentation.

Authorization During Issuance
Interaction Flow
sequenceDiagram
    %%autonumber
    participant User
    participant WI as Wallet Instance
    participant AP as Attestation Provider
    participant TL as WRPRC LoTE
    participant Reg as Register

    User->>WI: 1. Request issuance
    WI->>AP: 2. Fetch Credential Issuer Metadata (OpenID4VCI)
    AP-->>WI: 3. Signed Credential Issuer Metadata

    Note over WI: 4. Verify metadata signature (WRPAC)

    alt WRPRC in issuer_info (format "registration_cert")
        Note over WI: 5a. Extract WRPRC
        WI->>TL: 6a. Fetch trust anchor
        TL-->>WI: 7a. Trust anchor
        Note over WI: 8a. WRPRC Validation Procedure
    else WRPRC absent or invalid
        Note over WI: 5b. Extract registryURI from registrar_dataset
        WI->>Reg: 6b. Query registration data
        Reg-->>WI: 7b. Registration data
        Note over WI: 8b. Register Validation Procedure
    end

    Note over WI: 9. Binding Verification Procedure
    Note over WI: 10. Entitlement Verification Procedure
    Note over WI: 11. Attestation Type Verification Procedure

    alt All verifications passed
        WI->>User: 12a. Show provider info, request confirmation
        User-->>WI: 13. User confirms
        Note over WI: 14. Store EDP if present
        WI->>AP: 15. Proceed with issuance
    else Verification failed
        WI->>User: 12b. Display warning, block issuance
    end
Step-by-step Operations

Steps 1-3: Obtain Credential Issuer Metadata. The WI SHALL fetch metadata from the AP using [OpenID4VCI] (ISSU_01) [AUTHZ-ISS-04]. These steps are not required if the WI already has the Credential Issuer Metadata stored locally, for example if it is already fetched during authentication process.

Step 4: Verify metadata signature. The WI SHALL verify the metadata signature and WRPAC certificate chain [AUTHZ-ISS-05]. If verification fails, the WI provides NOT_AUTHORIZED code (non-overridable) [AUTHZ-ISS-06].

Steps 5-8: Extract authorization data. The WI SHALL extract data from the issuer_info array [AUTHZ-ISS-07]. If a WRPRC is present (steps 5a-8a), apply the WRPRC Validation Procedure. If absent or invalid (steps 5b-8b), apply the Register Validation Procedure. If both fail, apply the three-tier fallback; self-declared data SHALL be treated as advisory only [AUTHZ-ISS-08], [AUTHZ-ISS-09].

Step 9: Binding verification. Apply the Binding Verification Procedure (issuance binding): verify that the AP identifier from the WRPAC (used to sign the metadata) is coherent with the sub in the WRPRC and the identifier in the registrar_dataset [AUTHZ-GEN-11]. If incoherent, the WI returns NOT_AUTHORIZED code (non-overridable).

Step 10: Entitlement verification. Apply the Entitlement Verification Procedure. If not confirmed, the WI provides NOT_AUTHORIZED code(non-overridable) [AUTHZ-ISS-01].

Step 11: Attestation type verification. Apply the Attestation Type Verification Procedure. If not found, the WI returns NOT_AUTHORIZED code (non-overridable) [AUTHZ-ISS-02], [AUTHZ-ISS-03].

Steps 12-15: User confirmation and EDP storage. Display AP information [AUTHZ-ISS-10], [AUTHZ-UI-09]. On confirmation, the WI store EDP locally if present (EDP_09) [AUTHZ-EDP-02] and proceed. On cancellation, terminate.

Authorization During Presentation
Common Authorization Semantics

The authorization logic is the same for remote and proximity flows [AUTHZ-PRES-03]. Main Differences are limited to:

  • Transport mechanism.
  • Where the WRPRC is extracted from.
  • WRPRC format (JWT vs CWT).
  • WRPRC data structure.
Interaction Flow
sequenceDiagram
    %%autonumber
    participant RP as Relying Party
    participant WI as Wallet Instance
    participant TL as WRPRC LoTE
    participant Reg as Register
    participant User

    RP->>WI: 1. Presentation Request

    alt User opted-in to verify
        alt WRPRC present
            WI->>TL: 2a. Fetch trust anchor
            TL-->>WI: 3a. Trust anchor
            Note over WI: 4a. WRPRC Validation Procedure
        else WRPRC missing or invalid
            WI->>Reg: 2b. Query registration data
            Reg-->>WI: 3b. Registration data
            Note over WI: 4b. Registrar Validation Procedure
        end
        Note over WI: 5. Binding Verification Procedure
        Note over WI: 6. Entitlement Verification Procedure
        Note over WI: 7. Scope Comparison Procedure
    else User NOT opted-in
        Note over WI: Skip registration verification
    end

    Note over WI: 8. EDP Evaluation Procedure (always)
    WI->>User: 9. Display results + advisories + request approval
    User-->>WI: 10. User decision
Step-by-step Operations

Step 1: Receive request and check User opt-in. The WI SHALL offer a User setting for RP verification, enabled by default [AUTHZ-PRES-04]. If opted-in, proceed to step 2. Otherwise skip to step 8.

Note

If opted-in, the WI executes the full registration verification block: evidence collection, binding verification, entitlement verification, and scope comparison (steps 2-7). If not opted-in, the WI skips these steps and proceeds directly to EDP evaluation (step 8), which is always executed.

Steps 2-4: Collect authorization evidence. Extract the WRPRC from the request [AUTHZ-PRES-05]: from verifier_info (remote) or euWrprc in requestInfo (proximity). If present, apply the WRPRC Validation Procedure. If absent or invalid, apply the Register Validation Procedure using registry_uri from the request extension and the RP identifier with intended_use_id. If lookup fails, notify User, record FAILED, proceed with advisory [AUTHZ-PRES-06].

Step 5: Binding verification. Apply the Binding Verification Procedure (direct or intermediary) [AUTHZ-PRES-07].

Step 6: Entitlement verification. Apply the Entitlement Verification Procedure for Service_Provider [AUTHZ-PRES-08].

Step 7: Scope comparison. Apply the Scope Comparison Procedure. Inform User of results [AUTHZ-PRES-09].

Step 8: EDP evaluation. Always executed regardless of registration verification [AUTHZ-EDP-09]. Apply the EDP Evaluation Procedure for each matching Attestation.

Steps 9-10: User approval. Present all results and request approval [AUTHZ-UI-07], [AUTHZ-UI-10]. Display at least [AUTHZ-UI-08],[AUTHZ-INT-05]:

  • RP/final RP identity,
  • intermediary identity where applicable,
  • requested attributes,
  • intended-use description,
  • privacy-policy link,
  • advisories.

If AUTHORIZED, the WI SHALL proceed to normal User approval. If NOT_AUTHORIZED and override is allowed, the WI SHALL present the negative outcome and MAY allow continuation [AUTHZ-UI-11]. If NOT_AUTHORIZED and override is not allowed, the WI SHALL NOT allow continuation [AUTHZ-UI-12].

Remote Flow Specifics

The RP Instance SHALL include RPRC_19a extension fields and, if available, the WRPRC by value (RPRC_19) [AUTHZ-PRES-10]. The WRPRC SHALL be JWT (typ = "rc-wrp+jwt"). Requested attributes SHALL be extracted from DCQL credential_queries[].claims[] paths.

Proximity Flow Specifics

The WRPRC is extracted from euWrprc in requestInfo according to [ETSI TS 119 472-2] [AUTHZ-PRES-11]. The WRPRC SHALL be CWT (typ = "rc-wrp+cwt"), signing algorithm from COSE header. Requested attributes SHALL be extracted from docRequest.itemRequest.nameSpaces.

Intermediary Handling

Intermediary handling applies to both flows [AUTHZ-INT-04]. The WI SHALL:

  • Authenticate the intermediary through its Access Certificate.
  • Detect the intermediary scenario.
  • Apply all authorization checks using the intermediated RP context.
  • Display both identities (RPI_07).

Negative cases SHALL result in NOT_AUTHORIZED code [AUTHZ-INT-06]. Override is allowed only for negative scope and negative EDP [AUTHZ-INT-07].

Combined Mechanisms Flowchart
flowchart TD
    Start([Presentation request received]) --> UserOptIn{User opted-in<br/>to verify?}

    UserOptIn -->|Yes| ObtainData[Obtain authorization data<br/>WRPRC or Register]
    UserOptIn -->|No| SkipVerif[Skip registration verification]

    ObtainData --> DataOK{Data<br/>obtained?}
    DataOK -->|No| WarnNoData[Advisory: cannot verify RP]
    DataOK -->|Yes| Binding[Binding Verification]

    Binding --> BindOK{Binding<br/>OK?}
    BindOK -->|No| BlockBinding[NOT_AUTHORIZED]
    BindOK -->|Yes| Entitlement[Entitlement Verification]

    Entitlement --> EntOK{Entitlement<br/>OK?}
    EntOK -->|No| WarnEnt[Advisory: wrong entitlement]
    EntOK -->|Yes| Scope[Scope Comparison]

    Scope --> ScopeOK{All attributes<br/>registered?}
    ScopeOK -->|Yes| RegPassed[Verification PASSED]
    ScopeOK -->|No| WarnScope[Advisory: unregistered attributes]

    WarnNoData --> UserReg{User decision}
    WarnEnt --> UserReg
    WarnScope --> UserReg

    UserReg -->|Deny| Deny[Deny presentation]
    UserReg -->|Proceed| RegWarning[Proceed with warning]

    RegPassed --> EDP
    RegWarning --> EDP
    SkipVerif --> EDP

    EDP[EDP Evaluation<br/>for each Attestation]
    EDP --> HasEDP{Has EDP?}
    HasEDP -->|No| Allow[Allow Attestation]
    HasEDP -->|Yes| EvalEDP[Evaluate policy]

    EvalEDP --> EDPOk{Satisfied?}
    EDPOk -->|Yes| Allow
    EDPOk -->|No| Flag[Flag with advisory]

    Allow --> More{More<br/>Attestations?}
    Flag --> More
    More -->|Yes| HasEDP
    More -->|No| Approval[Show results + advisories<br/>Request User approval]

    Approval --> Final{User decision}
    Final -->|Approve| Present[Present Attestations]
    Final -->|Deny| Deny

    Present --> End([End])
    Deny --> End
    BlockBinding --> End

    style Flag fill:#ffffcc
    style Deny fill:#ffcccc
    style BlockBinding fill:#ffcccc
    style WarnNoData fill:#ffffcc
    style WarnEnt fill:#ffffcc
    style WarnScope fill:#ffffcc
    style Present fill:#ccffcc
    style RegPassed fill:#ccffcc

Authorization Requirements

Note

This table is provided for implementation and conformance-verification purposes. It consolidates the normative requirements defined throughout the specification body. In case of interpretative ambiguity between this table and the normative sections of the specification, the normative sections SHALL prevail.

ID Requirement Phase Related HLRs
AUTHZ-GEN-01 The authorization process SHALL start only after the WRP has been successfully authenticated. Both --
AUTHZ-GEN-02 If the WRP has not been authenticated, the authorization process SHALL NOT start. Both --
AUTHZ-GEN-03 A conformant wallet SHALL implement all authorization-processing rules defined in this specification. Both --
AUTHZ-GEN-04 The WI SHALL distinguish between the authenticated WRP and the authorization subject. Both --
AUTHZ-GEN-05 The WI SHALL support authorization-context resolution from WRPRC and Register. Both RPRC_16, RPRC_18
AUTHZ-GEN-06 The authorization logic SHALL NOT change based on the data source. Both --
AUTHZ-GEN-07 Where both WRPRC and Register data are available, the WI SHALL normalize both into the same model. Both --
AUTHZ-GEN-08 When a WRPRC is available, the WI SHALL validate its authenticity, integrity, temporal validity, and status before relying on it. Both RPRC_17
AUTHZ-GEN-09 WRPRC validation SHALL include coherence check between WRPRC subject and scenario context. Both --
AUTHZ-GEN-10 When WRPRC is not available or validation failed, the WI SHALL attempt querying the Register. Both RPRC_18
AUTHZ-GEN-11 The WI SHALL verify coherence between authenticated WRP and authorization context in both issuance and presentation. Both --
AUTHZ-GEN-12 For direct RP in presentation, the WI SHALL verify RP identifier from WRPAC matches sub in authorization context and RPRC_19a identifier. For issuance, the WI SHALL verify AP identifier from WRPAC matches sub in WRPRC and identifier in registrar_dataset. Both RPRC_07, RPRC_08
AUTHZ-GEN-13 The WI SHALL verify that entitlements match the expected role. Both ISSU_24a, ISSU_34a
AUTHZ-IN-01 Authorization decisions SHALL be based only on authenticated context, verified WRPRC, verified Register, verified EDP, or identified self-declared fallback. Both --
AUTHZ-IN-02 The WI SHALL maintain internal distinction between input classes. Both --
AUTHZ-IN-03 Authenticated WRP context is authoritative only for WRP identity. Both --
AUTHZ-IN-04 Verified WRPRC-derived information is authoritative for subject identity, entitlements, scope, etc. Both --
AUTHZ-IN-05 Verified Register-derived information is authoritative for the same data set. Both --
AUTHZ-IN-06 The WI SHALL NOT rely solely on self-declared information for checks requiring registered information. Both ISSU_24a note, ISSU_34a note
AUTHZ-IN-07 Authoritative sources SHALL prevail over non-authoritative sources. Both --
AUTHZ-IN-08 Identity conflict between authenticated context and authorization context produces NOT_AUTHORIZED (non-overridable). Both --
AUTHZ-IN-09 A request-carried Register URL SHALL NOT be treated as proof of registration; MAY be used as a discovery hint. Both --
AUTHZ-IN-10 Self-declared fallback information SHALL NOT be presented as verified registration information. Issuance ISSU_24a note
AUTHZ-UI-01 The WI SHALL produce AUTHORIZED or NOT_AUTHORIZED. Both --
AUTHZ-UI-02 User-relevant limitations SHALL be represented as advisories. Both --
AUTHZ-UI-03 Advisories SHALL be displayed to the Wallet User. Both --
AUTHZ-UI-04 User approval SHALL be a separate step from the authorization decision. Both RPA_07
AUTHZ-UI-05 The process SHALL support transparent decision-making and SHALL NOT be purely hidden. Both [CIR 2025/848]
AUTHZ-UI-06 Non-overridable cases: provider role/type failure in issuance, metadata signature failure, coherence failure, intermediary binding failure, registration status failure, missing minimum info, inability to obtain required authoritative info for issuance. Both ISSU_24a, ISSU_34a, RPRC_23
AUTHZ-UI-07 For presentation, the WI SHALL present all results and advisories and request User approval. Presentation RPA_07
AUTHZ-UI-08 For presentation, the WI SHALL show at minimum: RP identity, intermediary identity, requested attributes, intended-use, privacy-policy, advisories. Presentation RPRC_19a, RPI_07
AUTHZ-UI-09 For issuance, the WI SHALL show at minimum: provider name/type, attestation type, service description, advisories. Issuance RPRC_22a
AUTHZ-UI-10 If AUTHORIZED, proceed to normal User approval. Both RPA_07
AUTHZ-UI-11 If NOT_AUTHORIZED and override allowed, present negative outcome and MAY allow continuation. Both EDP_07, RPRC_21
AUTHZ-UI-12 If NOT_AUTHORIZED and override not allowed, SHALL NOT allow continuation. Both ISSU_24a, ISSU_34a
AUTHZ-ISS-01 If provider entitlement is not confirmed, produce NOT_AUTHORIZED (non-overridable), SHALL NOT request issuance. Issuance ISSU_24a, ISSU_34a, RPRC_23
AUTHZ-ISS-02 The WI SHALL verify that the PID/attestation type is registered for the provider. Issuance ISSU_34b, RPRC_23
AUTHZ-ISS-03 If attestation type is not registered, produce NOT_AUTHORIZED (non-overridable), SHALL NOT request issuance. Issuance ISSU_34b, RPRC_23
AUTHZ-ISS-04 The WI SHALL fetch Credential Issuer Metadata via OpenID4VCI. Issuance ISSU_01
AUTHZ-ISS-05 The WI SHALL verify metadata signature and WRPAC certificate chain. Issuance ISSU_22a, ISSU_32a
AUTHZ-ISS-06 If metadata signature verification fails, produce NOT_AUTHORIZED (non-overridable). Issuance --
AUTHZ-ISS-07 The WI SHALL extract authorization data from issuer_info per [ETSI TS 119 472-3] section 4.2.3. Issuance RPRC_22
AUTHZ-ISS-08 Self-declared fallback from Credential Issuer Metadata SHALL be treated as advisory only. Issuance ISSU_24a note
AUTHZ-ISS-09 The WI SHALL NOT present self-declared entitlement information as verified. Issuance ISSU_24a note
AUTHZ-ISS-10 On successful verification and User confirmation, proceed with issuance and store EDP. Issuance EDP_09
AUTHZ-PRES-01 If User opted-in and registered scope available, the WI SHALL compare requested attributes against registered scope. Presentation RPRC_16, RPRC_21
AUTHZ-PRES-02 If unregistered attributes detected, identify them and notify User. Override permitted. Presentation RPRC_21
AUTHZ-PRES-03 Authorization logic SHALL be the same for remote and proximity flows. Presentation OIA_01
AUTHZ-PRES-04 The WI SHALL offer a User setting for RP verification, enabled by default. Presentation RPRC_16
AUTHZ-PRES-05 The WI SHALL extract WRPRC per applicable flow (verifier_info or euWrprc). Presentation RPRC_19, RPRC_20
AUTHZ-PRES-06 If authorization data cannot be obtained, notify User and proceed with advisory. Presentation RPRC_18
AUTHZ-PRES-07 The WI SHALL verify entitlements and binding after data extraction. Presentation RPRC_16
AUTHZ-PRES-08 The WI SHALL verify Service_Provider entitlement. Presentation --
AUTHZ-PRES-09 The WI SHALL inform User of scope comparison results. Presentation RPRC_21
AUTHZ-PRES-10 Remote: RP Instance SHALL include RPRC_19a extension fields and WRPRC by value if available. Presentation RPRC_19, RPRC_19a
AUTHZ-PRES-11 Proximity: WRPRC SHALL be CWT, attributes from device request namespaces. Presentation RPRC_20, OIA_01
AUTHZ-INT-01 Intermediary scenario detected when WRPAC subject identifier differs from RPRC_19a claimed RP identifier. Detection is performed before WRPRC examination. Presentation RPI_07
AUTHZ-INT-02 In intermediary scenarios, authorization inputs SHALL apply to intermediated RP; WI SHALL verify intermediary association. Presentation RPI_01 - RPI_10
AUTHZ-INT-03 If intermediary binding fails, produce NOT_AUTHORIZED (non-overridable). Presentation RPI_07a
AUTHZ-INT-04 Intermediary handling applies to both remote and proximity flows. Presentation RPI_01 - RPI_10
AUTHZ-INT-05 For intermediated presentation, the WI SHALL process minimum fields about the final RP. Presentation RPRC_19a, RPI_07
AUTHZ-INT-06 Negative cases for intermediated presentation: missing final RP info, binding failure, missing authoritative data, negative EDP, negative scope. Presentation --
AUTHZ-INT-07 Override permitted only for negative scope and negative EDP in intermediated presentation. Presentation EDP_07, RPRC_21
AUTHZ-REG-01 The WI SHALL verify authenticity and integrity of Register response before relying on it. Both RPRC_18
AUTHZ-REG-02 The WI SHALL verify Register response pertains to the relevant subject and intended use. Both --
AUTHZ-REG-03 The WI SHALL normalize Register-derived data into the same model used for WRPRC data. Both --
AUTHZ-REG-04 If required authoritative information cannot be obtained from Register, for issuance apply fallback; for presentation notify User. Both RPRC_18
AUTHZ-EDP-01 The WI SHALL support EDP for QEAAs, PuB-EAAs, non-qualified EAAs. SHALL NOT assume PIDs have EDP. Presentation EDP_01
AUTHZ-EDP-02 During issuance, the WI SHALL store EDP locally if present. Issuance EDP_09, EDP_10
AUTHZ-EDP-03 At presentation, the WI SHALL check locally stored EDP for each matching Attestation. Presentation EDP_06, EDP_10
AUTHZ-EDP-04 The WI SHALL support authorized relying parties only policy evaluation. Presentation [CIR 2024/2979] Annex III, Discussion Topic D Req 1
AUTHZ-EDP-05 The WI SHALL support specific root of trust policy evaluation. Presentation [CIR 2024/2979] Annex III, Discussion Topic D Req 2
AUTHZ-EDP-06 The WI SHALL evaluate EDP together with RP information to determine access permission. Presentation EDP_06
AUTHZ-EDP-07 If EDP satisfied and explanatory link present, display it. Presentation EDP_05
AUTHZ-EDP-08 If EDP not satisfied, produce NOT_AUTHORIZED, present outcome, allow User override. Presentation EDP_07, RPA_11
AUTHZ-EDP-09 EDP evaluation is always executed regardless of registration verification result. Presentation EDP_06

7. Trust Management and Lifecycle

Revocation Mechanisms

This section describes the artifacts that are employed in Trust Management and Lifecycle to manage the status of certificates and entities by detailing respective formats and parameters. The main distinction is the following:

Token Status List

This section defines a Status List data structure, which is used to convey information regarding the individual statuses of multiple WRPRCs. A Status List describes the status of the WRPRCs by encoding their validity in a bit array. Each WRPRC is allocated an index during issuance; this index represents its position within the bit array. The value of the bit(s) at this index corresponds to the WRPRC's status. A Status List is provided within a cryptographically signed Status List Token in JWT format. This subsection follows [draft-ietf-oauth-status-list-19].

In this specification, the roles of the Provider of WRPRC and Status Issuer (i.e., the entity that issues the Status List Token about the status information of the WRPRC) SHALL coincide. Moreover, the Status Provider (i.e., the entity that provides the Status List Token on a public endpoint) SHALL be the Provider of WRPRC itself.

The Provider of WRPRC SHALL:

  • Define a number of bits, $k$, (either 1, 2, 4, or 8) that represents the amount of bits used to describe the status of each WRPRC within this Status List. The Provider of WRPRC SHALL configure this number. Each WRPRC will therefore have $2^k$ possible states.
  • Create a byte array of size $\geq$ (expected number of WRPRCs) * $k$ / 8. Depending on $k$, each byte in the array corresponds to 8/$k$ statuses (8 if $k=1$, 4 if $k=2$, 2 if $k=4$, or 1 if $k=8$). Each time a WRPRC is issued, the Provider of WRPRC assigns it to a position in the array.
  • Set the status values for all issued WRPRCs within the byte array. The status of each WRPRC is identified using an index that maps to one or more specific bits within the byte array. The index starts counting at 0 and ends with (number of WRPRC) - 1. All bits of the byte array at a particular index are set to a status value.
  • Compress the byte array using DEFLATE RFC 1951 with the ZLIB RFC 1950 data format. Implementations are RECOMMENDED to use the highest compression level available.
  • Make an endpoint available to Wallet Units to request Status Lists Tokens.

The Provider of WRPRC SHALL use the following values for the possible statuses of the issued WRPRCs:

  • 0x00 - VALID - The WRPRC is valid.
  • 0x01 - INVALID - The WRPRC is revoked.

For example, if two states for a certain WRPRC are possible, then $k=1$. If the Attestation Provider creates an array to store the statuses of 6 WRPRCs, whose validity statuses are 0, 0, 0, 1, 1, 0, respectively; then:

  • The bit array can be of the form a=[0, 0, 0, 0, 0, 0, 0, 0; 0, 0, 1, 1, 0, 0, 0, 0; 0, 0, 1, 0, 0, 0, 0, 1] which, in hexadecimal notation, corresponds to the byte array [0x00, 0x30, 0x21].
  • The status values are encoded in specific bit positions based on their assigned index.
  • The array is then compressed using DEFLATE.

Note

When the Provider of WRPRC chooses the number of bits for conveying statuses of the WRPRCs it issues, it MAY add other states besides those described above. The addition of many different states for the lifecycle of a WRPRC SHALL, however, be carefully pondered, as it discloses information to Relying Parties.

Once the Wallet Unit receives a WRPRC, it can request the Status List to validate its status through the provided URI parameter and look up the corresponding index in the list.

Status List Token

The Status List Token (SLT) is available at the Status List Endpoint. It is formatted as a JSON Web Token (JWT) signed by the Provider of WRPRC and contains the following parameters:

Status List Token Header
Parameter Defined in Presence Format Description
alg [RFC 7515] REQUIRED String A digital signature algorithm identifier per the IANA "JSON Web Signature and Encryption Algorithms" registry. It SHALL NOT be set to none or to a symmetric algorithm (MAC) identifier.
typ [RFC 7515] REQUIRED String Specifies the type of the Web Token. It SHALL be set to statuslist+jwt.
x5c [RFC 7515] REQUIRED Array of Strings Contains the Base64-encoded certificate chain required to verify the SLT's signature.
Status List Token Payload
Parameter Defined in Presence Format Description
sub RFC 7519 REQUIRED String The subject claim SHALL specify the URI of the SLT. The value SHALL be equal to that of the uri claim contained in the status*list.uri claim of the WRPRC.
iat RFC 7519 REQUIRED NumericDate A timestamp indicating when the SLT was issued.
exp RFC 7519 REQUIRED NumericDate A timestamp indicating when the SLT expires.
status*list OAuth Status List Draft REQUIRED JSON Object A JSON Object that contains the Status List configurations and payload.
status*list.bits OAuth Status List Draft REQUIRED Integer Specifies the number of bits per WRPRC in the compressed byte array. The allowed values are 1, 2, 4, and 8.
status*list.lst OAuth Status List Draft REQUIRED Base64url-encoded String Contains the status values for all the WRPRCs. The value SHALL be the base64url-encoded compressed byte array.
ttl OAuth Status List Draft RECOMMENDED Integer Time to live claim expressed in seconds. It specifies the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved.

The following is an example of the Status List Token payload and header prior to signing and base64url encoding:

Header:

{
  "alg": "ES256",
  "typ": "statuslist+jwt",
  "x5c": [
    "MIIDqjCCApKgAwIBAgIESLNEvDA...",
    "MIICwzCCAasCCQCKVy9eKjvi+jA...",
    "MIIDTDCCAjSgAwIBAgIJAPlnQYH..."
  ]
}

Payload:

{
  "exp": 2291720170,
  "iat": 1686920170,
  "sub": "https://example-issuer.com/statuslists/1",
  "status*list": {
    "bits": 1,
    "lst": "eNrbuRgAAhcBXQ"
  }
}
Status List Request

The Wallet Unit SHALL request a Status List Token at the URI referenced within the status.status_list.uri claim of the WRPRC. The request SHALL use HTTP GET with media type application/statuslist+jwt.

Below it is represented an example of such a request.

  GET /statuslists/1 HTTP/1.1
  Host: example.com
  Accept: application/statuslist+jwt
Status List Response

The successful response SHALL contain a Status List Token and have HTTP status code 200. The content type of the successful response SHALL be application/statuslist+jwt.

  HTTP/1.1 200 OK
  Content-Type: application/statuslist+jwt

  eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e
  yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
  GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
  WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
  nR0bCI6NDMyMDB9.2lKUUNG503R9htu4aHAYi7vjmr3sgApbfoDvPrl65N3URUO1EYqq
  Ql45Jfzd-Av4QzlKa3oVALpLwOEUOq-U*g

If caching-related HTTP headers are present in the HTTP response, Wallet Units SHALL prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior.

Certificate Revocation Lists

Certificate Revocation Lists (CRLs) MAY be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements.

CRL issuers issue CRLs. The CRL issuer is either the Certificate Authority (CA) or an entity that has been authorized by the CA to issue CRLs.

Note

Within APTITUDE the CRL Issuer SHALL be the Trust Anchor.

CAs publish CRLs to provide status information about the certificates they issued. Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be "all certificates issued by CA X". A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope.

The CRL issuer MAY also generate delta CRLs. A delta CRL only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL. The referenced complete CRL is referred to as a base CRL. The scope of a delta CRL SHALL be the same as the base CRL that it references.

If supported by the CA, the CRL SHALL be available at the URI specified in the cRLDistributionPoints.distributionPoint [0] CHOICE structure within the WRPAC.

An X.509 v2 CRL is represented as the ASN.1 DER encoding of the CertificateList SEQUENCE. The ASN.1 DER encoding is a strictly defined tag, length, and value encoding system for each element. The final bytes transmitted represent the DER encoding of the top-level SEQUENCE containing the fields in the following table:

Parameter Defined in Presence Format Description
tbsCertList [RFC 5280] clause 5.1.1.1 REQUIRED SEQUENCE Contains the core CRL information including the name of the issuer, issue date, next update date, the optional list of revoked certificates, and optional CRL extensions.
signatureAlgorithm [RFC 5280] clause 5.1.1.2 REQUIRED SEQUENCE Contains the algorithm identifier for the algorithm used by the CRL issuer to sign the CertificateList. Selection SHOULD align with relevant standards (e.g., ETSI TS 119 312).
signatureAlgorithm.algorithm [RFC 5280] clause 4.1.1.2 REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm.
signatureAlgorithm.parameters [RFC 5280] clause 4.1.1.2 OPTIONAL ANY Algorithm-specific parameters, dependent on the signature algorithm used.
signatureValue [RFC 5280] clause 5.1.1.3 REQUIRED BIT STRING Contains the digital signature computed upon the ASN.1 DER encoded tbsCertList.
Certificate List Content

The TBSCertList (To Be Signed Certificate List) is an ASN.1 SEQUENCE containing several fields and extensions. The following table lists all such fields and extensions that are required in a CRL or conditionally required.

Parameter Defined in Presence Format Description
version [RFC 5280] clause 5.1.2.1 OPTIONAL INTEGER Describes the version of the encoded CRL. When extensions are used (as is standard practice), this field SHALL be present and SHALL specify version 2 (the integer value is 1).
signature [RFC 5280] clause 5.1.2.2 REQUIRED SEQUENCE The algorithm identifier for the algorithm used to sign the CRL.
signature.algorithm [RFC 5280] clause 4.1.1.2 REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm. SHALL match the signatureAlgorithm field in the parent CertificateList sequence.
signature.parameters [RFC 5280] clause 4.1.1.2 OPTIONAL ANY Algorithm-specific parameters, dependent on the algorithm used.
issuer [RFC 5280] clause 5.1.2.3 REQUIRED Name Identifies the entity that has signed and issued the CRL. It SHALL contain a non-empty X.500 distinguished name (DN) composed of AttributeType (OID) and AttributeValue sequences.
thisUpdate [RFC 5280] clause 5.1.2.4 REQUIRED UTCTime or GeneralizedTime Indicates the issue date of this CRL. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
nextUpdate [RFC 5280] clause 5.1.2.5 REQUIRED UTCTime or GeneralizedTime Indicates the date by which the next CRL will be issued. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
revokedCertificates [RFC 5280] clause 5.1.2.6 OPTIONAL SEQUENCE OF A sequence of revoked certificates. When there are no revoked certificates, this field SHALL be absent.
revokedCertificates.userCertificate [RFC 5280] clause 5.1.2.6 REQUIRED INTEGER The CertificateSerialNumber of the revoked certificate.
revokedCertificates.revocationDate [RFC 5280] clause 5.1.2.6 REQUIRED UTCTime or GeneralizedTime The date on which the revocation occurred.
revokedCertificates.crlEntryExtensions [RFC 5280] clause 5.1.2.6 OPTIONAL SEQUENCE OF Extensions specific to this revoked certificate entry. If present, the CRL version SHALL be v2.
crlExtensions [RFC 5280] clause 5.1.2.7 OPTIONAL [0] EXPLICIT SEQUENCE OF A sequence of one or more CRL extensions. If present, the CRL version SHALL be v2.

The crlExtensions field MAY contain various extensions. Notable standard extensions include:

Parameter Defined in Presence Format Description
authorityKeyIdentifier [RFC 5280] clause 5.2.1 REQUIRED SEQUENCE Provides a means of identifying the public key corresponding to the private key used to sign the CRL. Contains keyIdentifier (OCTET STRING), authorityCertIssuer, or authorityCertSerialNumber.
cRLNumber [RFC 5280] clause 5.2.3 REQUIRED INTEGER A non-critical extension conveying a monotonically increasing sequence number for a given CRL scope and issuer.

Note

Within the APTITUDE pilot, Delta CRLs are not used.

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) enable applications to determine the exact revocation state of identified certificates. It provides more timely revocation information than is typically possible with CRLs and MAY also be used to obtain additional status information.

An OCSP client issues a status request to an OCSP responder and SHALL suspend the acceptance of the certificates in question until the responder provides a valid response.

If supported by the CA, the URI to which the OCSP Responder can be invoked SHALL be present in the authorityInfoAccess.accessLocation extension of the WRPAC.

This protocol specifies the data that SHALL be exchanged between the OCSP client (which checks the status of one or more certificates) and the OCSP server (which provides the corresponding status). In this specific ecosystem, the OCSP client can be a WU checking the WRPAC of a WRP, and the OCSP server is the Provider of the WRPAC.

Online Certificate Status Protocol Request Format

The OCSP request is the ASN.1 DER encoding of the OCSPRequest SEQUENCE, which contains the tbsRequest (To-Be-Signed Request) and an optional signature. The following table lists the parameters found within the tbsRequest structure.

Parameter Defined in Presence Format Description
version [RFC 6960] clause 4.1.1 OPTIONAL [0] EXPLICIT INTEGER Indicates the version of the protocol. If omitted, the default value is v1 (0).
requestList [RFC 6960] clause 4.1.1 REQUIRED SEQUENCE OF Contains one or more single certificate status requests.
requestList.reqCert [RFC 6960] clause 4.1.1 REQUIRED SEQUENCE The CertID structure carrying the identifier of a target certificate.
requestList.singleRequestExtensions [RFC 6960] clause 4.1.1 OPTIONAL [0] EXPLICIT SEQUENCE Includes extensions applicable to this single certificate status request.
requestExtensions [RFC 6960] clause 4.1.1 OPTIONAL [2] EXPLICIT SEQUENCE Includes extensions applicable to the overall requests found within the requestList.

The reqCert parameter utilizes the CertID structure, which is an ASN.1 SEQUENCE containing the following parameters:

Parameter Defined in Presence Format Description
hashAlgorithm [RFC 6960] clause 4.1.1 REQUIRED SEQUENCE Identifies the hash algorithm used to generate the issuer name and key hashes.
hashAlgorithm.algorithm [RFC 6960] clause 4.1.1 REQUIRED OBJECT IDENTIFIER The OID of the hash function (e.g.,SHA-256, depending on the profile).
hashAlgorithm.parameters [RFC 6960] clause 4.1.1 OPTIONAL ANY Algorithm-specific parameters, dependent on the hash algorithm used.
issuerNameHash [RFC 6960] clause 4.1.1 REQUIRED OCTET STRING The hash of the issuer's distinguished name (DN), calculated over the DER encoding of the issuer's name field.
issuerKeyHash [RFC 6960] clause 4.1.1 REQUIRED OCTET STRING The hash of the issuer's public key, calculated over the value (excluding tag and length) of the subject public key field.
serialNumber [RFC 6960] clause 4.1.1 REQUIRED INTEGER The serial number of the target certificate for which the status is being requested.

The requestExtensions and singleRequestExtensions structures MAY contain various extensions. A common extension is the nonce:

Parameter Defined in Presence Format Description
nonce [RFC 6960] clause 4.4.1 REQUIRED OCTET STRING Cryptographically fresh value used to bind a request and a response to prevent replay attacks. Identifier OID is id-pkix-ocsp-nonce.

Note

Within APTITUDE, OCSP requests SHALL use the nonce extension.

When sent over HTTP using POST, the body of this request is the raw DER encoding of this OCSPRequest, with the MIME type application/ocsp-request.

Below is a concrete example of an OCSP request:

OCSPRequest:
  tbsRequest:
    version = v1
    requestList = SEQUENCE OF
      Request:
        reqCert:
          hashAlgorithm:
            algorithm  = sha256
            parameters = null
          issuerNameHash = SHA256( DER-encode(Issuer Name) )
          issuerKeyHash  = SHA256( Issuer SubjectPublicKey BIT STRING )
          serialNumber   = 0x01A2B3C4D5
    requestExtensions:
      nonce = OCTET STRING (nonce)
Online Certificate Status Protocol Response Format

An OCSP response is the ASN.1 DER encoding of the OCSPResponse SEQUENCE. When transported over HTTP, the body of the HTTP response is the raw DER encoding of this OCSPResponse, with the MIME type application/ocsp-response. The OCSPResponse SEQUENCE contains the following parameters:

Parameter Defined in Presence Format Description
responseStatus [RFC 6960] clause 4.2.1 REQUIRED ENUMERATED Indicates the processing status of the prior request. Supported values are: successful (0), malformedRequest (1), internalError (2), tryLater (3), sigRequired (5), and unauthorized (6).
responseBytes [RFC 6960] clause 4.2.1 OPTIONAL [0] EXPLICIT SEQUENCE Present only when the responseStatus is successful (0). Contains the response type and the encoded response data.
responseBytes.responseType [RFC 6960] clause 4.2.1 REQUIRED OBJECT IDENTIFIER Identifier for the response type. For a basic OCSP responder, this value SHALL be id-pkix-ocsp-basic.
responseBytes.response [RFC 6960] clause 4.2.1 REQUIRED OCTET STRING Contains the DER encoding of the response syntax identified by responseType (e.g., the BasicOCSPResponse structure).

Note

Within APTITUDE, OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.

BasicOCSPResponse is an ASN.1 SEQUENCE containing the following parameters:

Parameter Defined in Presence Format Description
tbsResponseData [RFC 6960] clause 4.2.1 REQUIRED SEQUENCE Contains the core response data to be signed by the responder.
tbsResponseData.version [RFC 6960] clause 4.2.1 OPTIONAL [0] EXPLICIT INTEGER The version of the response syntax. If omitted, the default value is v1 (0).
tbsResponseData.responderID [RFC 6960] clause 4.2.1 REQUIRED CHOICE Identifies the OCSP responder. It SHALL contain either byName or byKey.
tbsResponseData.responderID.byName [RFC 6960] clause 4.2.1 OPTIONAL [1] EXPLICIT Name The Name from the responder’s certificate subject.
tbsResponseData.responderID.byKey [RFC 6960] clause 4.2.1 OPTIONAL [2] EXPLICIT OCTET STRING The SHA-1 hash of the responder’s subjectPublicKey (excluding the tag and length fields).
tbsResponseData.producedAt [RFC 6960] clause 4.2.1 REQUIRED GeneralizedTime The time at which the OCSP response was generated.
tbsResponseData.responses [RFC 6960] clause 4.2.1 REQUIRED SEQUENCE OF A sequence of SingleResponse structures, providing the status of each requested certificate.
tbsResponseData.responseExtensions [RFC 6960] clause 4.2.1 OPTIONAL [1] EXPLICIT SEQUENCE OF Contains extensions applicable to the overall OCSP response.
signatureAlgorithm [RFC 5280] clause 4.1.1.2 REQUIRED SEQUENCE Identifies the cryptographic algorithm used to sign the response.
signatureAlgorithm.algorithm [RFC 5280] clause 4.1.1.2 REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm. Selection SHOULD align with relevant standards (e.g., ETSI TS 119 312).
signatureAlgorithm.parameters [RFC 5280] clause 4.1.1.2 OPTIONAL ANY Algorithm-specific parameters, dependent on the OID defined in algorithm.
signature [RFC 6960] clause 4.2.1 REQUIRED BIT STRING The digital signature computed over the hash of the DER-encoded tbsResponseData.
certs [RFC 6960] clause 4.2.1 OPTIONAL [0] EXPLICIT SEQUENCE OF Certificate chain to help the client verify the responder's signature. If no certificates are included, this field SHOULD be absent.

The responseExtensions structure MAY contain various extensions. A notable parameter often required by specific profiles (such as to prevent replay attacks) is the nonce:

Parameter Defined in Presence Format Description
nonce [RFC 6960] clause 4.4.1 REQUIRED OCTET STRING Cryptographically fresh value used to bind a request and a response to prevent replay attacks. If included in the request, responders SHOULD include it in the response. Identifer OID is id-pkix-ocsp-nonce.

Note

Within APTITUDE, OCSP Responses SHALL use the nonce extension.

In the OCSP Response there SHALL be at least a SingleResponse for each CertID in the request. Each SingleResponse is an ASN.1 SEQUENCE that carries the following parameters:

Parameter Defined in Presence Format Description
certID [RFC 6960] clause 4.2.1 REQUIRED SEQUENCE Identifier of the certificate whose status is determined in certStatus.
certStatus [RFC 6960] clause 4.2.1 REQUIRED CHOICE The value of the certificate's status. It SHALL be exactly one of: good, revoked, or unknown.
certStatus.good [RFC 6960] clause 4.2.1 OPTIONAL [0] IMPLICIT NULL Indicates the certificate is valid.
certStatus.revoked [RFC 6960] clause 4.2.1 OPTIONAL [1] IMPLICIT SEQUENCE Indicates the certificate has been revoked. Contains the RevokedInfo structure.
certStatus.revoked.revocationTime [RFC 6960] clause 4.2.1 REQUIRED GeneralizedTime The time at which the certificate was revoked.
certStatus.revoked.revocationReason [RFC 6960] clause 4.2.1 OPTIONAL [0] EXPLICIT ENUMERATED Contains the CRLReason indicating why the certificate was revoked.
certStatus.unknown [RFC 6960] clause 4.2.1 OPTIONAL [2] IMPLICIT NULL Indicates the responder does not know the status of the certificate.
thisUpdate [RFC 6960] clause 4.2.1 REQUIRED GeneralizedTime Indicates the issue date and time of this OCSP Response.
nextUpdate [RFC 6960] clause 4.2.1 OPTIONAL [0] EXPLICIT GeneralizedTime Indicates the date and time by which the next update to the OCSP Responder database will be in place.
singleExtensions [RFC 6960] clause 4.2.1 OPTIONAL [1] EXPLICIT SEQUENCE Includes extensions applicable to this single certificate status response.

Below is a concrete example of an OCSP response with a single good status.

OCSPResponse:
  responseStatus = successful (0)
  responseBytes:
    responseType = id-pkix-ocsp-basic
    response = DER(BasicOCSPResponse)
      BasicOCSPResponse: 
        tbsResponseData:
          version = v1
          responderID"
            byName: 
             CN = Example OCSP Responder
             O  = Example CA
             C  = CZ
          producedAt = 20250101000000Z
          responses = SEQUENCE OF
            SingleResponse:
              certID:
                hashAlgorithm  = sha1
                issuerNameHash = SHA1( DER-encode(issuer Name) )
                issuerKeyHash  = SHA1( issuer SubjectPublicKey BIT STRING )
                serialNumber   = 0x01A2B3C4D5
              certStatus  = good
              thisUpdate  = 20250101000000Z
              nextUpdate  = 20250102000000Z
              singleExtensions = absent
          responseExtensions:
            nonce = OCTET STRING (nonce)
        signatureAlgorithm = sha256WithRSAEncryption
        signature          = BIT STRING (signature over hash(DER(tbsResponseData)))
        certs              = SEQUENCE OF
            Certificate (responder’s cert, possibly with its issuing CA cert)

References

Commission Implementing Regulation (CIR)

Item Reference Date Standard Name/Details
CIR 2024/2979 2024-11-28 Integrity and core functionalities of European Digital Identity Wallets
CIR 2024/2980 2024-11-28 Notifications to the Commission concerning the European Digital Identity Wallet ecosystem
CIR 2025/848 2025-05-06 Registration of wallet-relying parties
CIR 2025/1569 2025-07-29 Qualified electronic attestations of attributes and electronic attestations of attributes provided by or on behalf of a public sector body responsible for an authentic source
CIR 2025/848-Amendment Applicable standards and specifications (draft)

ARF and Technical Specifications (TS)

Item Reference Version Date Standard Name/Details
ARF V2.8.0 2026-02-02 Architecture and Reference Framework
TS02 V1.0.1 2026-01-30 Specification of systems enabling the notification and subsequent publication of Provider information
TS05 V1.3 2026-02-13 Specification of common formats and API for Relying Party Registration information
TS06 V1.0.1 2026-01-30 Common Set of Relying Party Information to be Registered
TS11 V1.0.1 2026-01-30 Specification of interfaces and formats for the catalogue of attributes and the catalogue of attestations

ETSI Specifications

ETSI specifications for EU Digital Identity Wallets of main interest for the trust framework:

Item Reference Version Date Standard Name/Details
ETSI TS 119 475 V1.2.1 2026-03 Electronic Signatures and Trust Infrastructures (ESI); Relying party attributes supporting EUDI Wallet user's authorisation decisions
ETSI TS 119 602 V1.1.1 2025-11 Electronic Signatures and Trust Infrastructures (ESI); Lists of trusted entities; Data model
ETSI TS 119 612 V2.4.1 2025-08 Electronic Signatures and Trust Infrastructures (ESI); Trusted Lists
ETSI TS 119 615 V1.3.1 2026-01 Electronic Signatures and Trust Infrastructures (ESI); Trusted lists; Procedures for using and interpreting European Union Member States national trusted lists
ETSI TS 119 411-8 V1.1.1 2025-10 Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 8: Access Certificate Policy for EUDI Wallet Relying Parties
ETSI TS 119 412-6 V1.1.1 2025-09 Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA providers
ETSI TS 119 472-1 V1.2.1 2026-02 Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 1: General requirements
ETSI TS 119 472-2 V1.1.1 2025-12 Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 2: Profiles for EAA/PID Presentations to Relying Party
ETSI TS 119 472-3 V1.1.1 2026-03 Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 3: Profiles for issuance of EAA or PID

Other ETSI specifications that the previous specifications build upon:

Item Reference Version Date Standard Name/Details
ETSI TS 119 182-1 V1.2.1 2024-07 Electronic Signatures and Trust Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures
ETSI EN 319 132-1 V1.3.1 2024-07 Electronic Signatures and Trust Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures
ETSI TS 119 495 V1.7.1 2024-07 Electronic Signatures and Trust Infrastructures (ESI); Sector Specific Requirements; Certificate Profiles and TSP Policy Requirements for Open Banking
ETSI EN 319 411-1 V1.5.1 2025-04 Electronic Signatures and Trust Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements
ETSI EN 319 412-1 V1.7.0 2026-02 Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures
ETSI EN 319 412-2 V2.4.1 2025-06 Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons
ETSI EN 319 412-3 V1.3.1 2023-09 Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons

ISO/IEC Standards

Item Reference Version Date Standard Name/Details
ISO/IEC 18013-5 Personal identification --- ISO-compliant driving licence - Part 5: Mobile driving licence (mDL) application

OIDF Standards

Item Reference Version Date Standard Name/Details
OpenID4VCI V1.0 2025-09 OpenID for Verifiable Credential Issuance
OpenID4VP V1.0 2025-07 OpenID Connect for Verifiable Presentations

IETF Standards

Item Reference Date Standard Name/Details
RFC 3647 2003-11 Internet X.509 Public Key Infrastructure - Certificate Policy and Certification Practices Framework (CRL) Profile
RFC 3739 2004-03 Internet X.509 Public Key Infrastructure - Qualified Certificates Profile
RFC 5280 2008-05 Internet X.509 Public Key Infrastructure - Qualified Certificates Profile
RFC 6960 2013-05 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
RFC 7515 2015-05 JSON Web Signature (JWS)
RFC 7519 2015-05 JSON Web Token (JWT)
RFC 9052 2022-08 CBOR Object Signing and Encryption (COSE): Structures and Process
RFC 9360 2023-02 CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificate
RFC 9608 2024-06 No Revocation Available for X.509 Public Key Certificates

IETF Drafts

Item Reference Date Standard Name/Details
draft-ietf-oauth-status-list-19 2026-03 Token Status List (TSL)