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 Unit Attestations (WUAs): Key Attestation (KA) or Wallet Instance Attestation (WIA).
• PID Signatures: Person Identification Data (PID).
• Registrar-signed artifacts: Register informations.

2. Trusted Lists (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:

• LoTE Validation: Validate the digital signature of the LoTE by verifying it against the LoTE Provider certificate. This certificate is authenticated via the Official Journal of the European Union (OJEU).
• TL Validation: Validate the digital signature of the TL by verifying it against the corresponding Member State public keys published in the List Of Trusted Lists (LOTL). The LOTL itself is authenticated by validating its digital signature against the Official Journal of the European Union (OJEU).

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:

flowchart 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

Trusted List Validation

This section defines the validation of Trusted Lists (TLs). The TL is an XML artifact signed by a Member State Scheme Operator. In order to validate the 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 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 TL (URL from LOTL)
    MS_Repo-->>Client: Returns Trusted List (XML)
    Client->>Client: Validate TL Signature using LOTL certificate

In the diagram above, a Wallet Unit or WRP downloads and validates a TL 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 TL at the location indicated by the TSLLocation field in the LOTL;
6. the TL distribution point returns the 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 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 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 TL containing the sought Trust Anchor, the Wallet Unit or Relying Party SHALL validate both the LOTL and the TL. The validation of the LOTL is a prerequisite for the validation of the TL, as the Trust Anchor for validating the 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 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 List of Trusted Lists 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 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 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 TL.
• EUTL: The XML file of the 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 TL. This variable is initialized as null.
• EUTL-Signer-Cert: The certificate extracted from the XML signature of the 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] (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] (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] (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 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] (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 TL:

flowchart TD
    Start([Start 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 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 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 WRP Access Certificate path. The Certificate Path Validation section is general and is applied to WRPRC certification path validation and Sign/Seal Certificate path validation as well.

• The Trust Anchor is the trusted certificate obtained from the ServiceDigitalIdentity component in Provider of WRPAC's 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 Provider of WRPAC.
  • \(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}\).

Certificate Path Validation

The entity that performs the certificate path validation initializes the following variables:

• path: The sequence \(C_1 \dots C_n\).
• trust_anchor: trusted certificate obtained from the ServiceDigitalIdentity component after validation of the relevant LoTE.
• current_time: The current date and time.

Note

The profiles for Trust Anchor certificates referenced within a LoTE are described in Trust Anchor Certificate.

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.

flowchart 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 entity performing certificate path validation (e.g., 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 ext-etsi-valassured-ST-certs 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.

flowchart 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.

flowchart 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:

• Issuance authorization: whether a PID Provider or Attestation Provider (AP) is registered for the relevant role and for the specific Attestation type(s) to be issued. This applies to PID Providers, QEAA Providers, PuB-EAA Providers, and EAA Providers.
• Presentation authorization: whether a Relying Party (RP) request is within its registered scope, whether any Embedded Disclosure Policy permits disclosure, and whether the User approves. This applies to both direct RP and intermediated RP interactions, and both Remote Flows and Proximity Flows.

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.

flowchart 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, 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 Token	[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, Requirement 1]
AUTHZ-EDP-05	The WI SHALL support specific root of trust policy evaluation.	Presentation	[CIR 2024/2979, Annex III, Discussion Topic D, Requirement 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