6. Trust Evaluation Process¶

Every trust evaluation process involves the following roles:

The Trust Evaluator is the party that performs the evaluation.
The Trust Evaluated Party is the entity, or the attestation, that is the object of the evaluation.

The same entity can act in both roles at different moments of the flows. The framework specific sections define which entity acts in which role, when, and for which purpose.

Each process requires a validated root of trust as a precondition. Each trust framework defines how its own root of trust is established, distributed and maintained. In the National Trust Framework this is the Federation Trust Anchor (see Federation Trust Anchor Distribution and Validation). In the EUDIW Trust Framework these are the Trust Anchors obtained from the applicable Trusted Lists and Lists of Trusted Entities (see List of Trusted Entities Validation).

The trust evaluation processes are the following:

Authentication. It asserts the cryptographic identity of a transacting entity. The Trust Evaluator binds the identifier of the Trust Evaluated Party to the proof of possession of a private key whose public part is trusted under the applicable root of trust.

Authorization. It evaluates a registration artifact to assert the entitlements of the Trust Evaluated Party, that is the specific capabilities the entity is authorized to perform, such as issuing a given Credential type or requesting a given set of attributes.

Metadata Retrieval and Validation. It obtains and validates the technical configuration of the Trust Evaluated Party, such as endpoints, public keys and supported algorithms.

Signing Trust Anchor Validation. It ingests an attestation and outputs the validated root of trust, identifier and public key, to be used for the verification of the issuer data authentication of that attestation.

The first three processes have an entity as their object. The fourth one has an attestation as its object and this includes Digital Credentials and the Wallet Instance Attestation.

6.1. Trust Framework Selection¶

This section defines which Trust Framework applies to an interaction. The two Trust Frameworks are described in Infrastructure of Trust. The procedures of each framework are defined in the following sections. The onboarding paths and the artifacts of each entity type are defined in Onboarding Processes.

The interaction is the authentication and authorization of the parties for one issuance or one presentation. The Wallet Unit MUST select exactly one Trust Framework for each interaction, before Authentication, Authorization or Metadata Retrieval and Validation. The selected Trust Framework applies to the whole interaction. A failed evaluation is handled as specified in Failure Handling.

The signing trust anchor of an Attestation follows the Rulebook of its Credential type, in every phase and whichever party performs the verification. A PID, a QEAA and a PuB-EAA MUST be validated against the Trust Anchors of the applicable List of Trusted Entities or Trusted List (see OIA_12, OIA_13, OIA_14 and OIA_15 of the ARF Annex 2, EIDAS-ARF). The procedure for a Credential anchored to the National Trust Framework is defined in Signing Trust Anchor Validation Procedure.

The onboarding declaration of a Non-Qualified EAA Provider or of a Relying Party is specified in Registration Profiles. At runtime the requested Credential selects the Trust Framework of the interaction. The same Credential Issuer MAY be evaluated under different frameworks in different interactions.

Where the configuration published through the EUDIW mechanisms and the configuration published through the federation diverge, the EUDIW configuration MUST prevail.

Table 6.1 Applicable Trust Framework by Interaction¶
Interaction	Condition	Trust Framework
Issuance, Credential Issuer	The requested Credential is a PID, a QEAA or a PuB-EAA, or a non-qualified Electronic Attestation of Attributes anchored to the EUDIW Trust Framework by its Rulebook, or the Credential Issuer is of another Member State.	The Wallet Unit MUST use the EUDIW Trust Framework.
Issuance, Credential Issuer	The Credential Issuer is a national entity and the requested Credential is a non-qualified Electronic Attestation of Attributes with national scope. The IT-Wallet ID is such a Credential (see IT-Wallet ID).	The Wallet Unit MUST use the National Trust Framework.
Issuance, Wallet Instance Attestation	The Wallet Unit is of another Member State.	The Credential Issuer MUST validate it through the Wallet Providers List of Trusted Entities.
Issuance, Wallet Instance Attestation	The Wallet Unit is national and the requested Credential is a PID, a QEAA or a PuB-EAA, or a non-qualified Electronic Attestation of Attributes anchored to the EUDIW Trust Framework by its Rulebook.	The Credential Issuer MUST validate the Wallet Instance Attestation through the Wallet Providers List of Trusted Entities.
Issuance, Wallet Instance Attestation	The Wallet Unit is national and the requested Credential is a non-qualified Electronic Attestation of Attributes with national scope. The IT-Wallet ID is such a Credential (see IT-Wallet ID).	The Credential Issuer MAY validate it through the National Trust Framework (see Wallet Unit Authentication).
Presentation	The request includes a PID, a QEAA or a PuB-EAA, or a non-qualified Electronic Attestation of Attributes anchored to the EUDIW Trust Framework by its Rulebook, or a Credential of another Member State, or the Relying Party offers the service outside the national audience.	The Relying Party MUST use the EUDIW Trust Framework for the whole request.
Presentation	The Relying Party is national and the request contains only a non-qualified Electronic Attestation of Attributes with national scope.	The Relying Party MUST use the National Trust Framework.

6.1.1. Selection at Issuance¶

At issuance the Wallet Unit initiates the interaction and knows the requested Credential (see Digital Credentials Catalog). The applicable row of Applicable Trust Framework by Interaction selects the Trust Framework.

On the EUDIW path, Authentication, Authorization and Metadata Retrieval and Validation of the Credential Issuer follow EUDIW Authentication, EUDIW Authorization and EUDIW Metadata Retrieval and Validation. On the National path they follow Federation Entity Authentication, Authorization and Metadata Retrieval and Validation.

The headers of the signed artifacts of the Credential Issuer MUST be consistent with the selected framework. An x5c header carries the access certificate on the EUDIW path. A kid header, with the optional trust_chain header, carries the federation key on the National path.

6.1.2. Selection at Presentation¶

The Relying Party does not authenticate the Wallet Unit. It cannot select the Trust Framework according to the Member State of that Wallet Unit or Wallet Solution. The applicable row of Applicable Trust Framework by Interaction selects the Trust Framework.

In the remote flow the Relying Party declares that framework through the client_id prefix of the request (see OpenID4VP, Section 5.9). The prefix x509_hash selects the EUDIW Trust Framework, as required by [ETSI TS 119 472-2] clause 6 (OIDFVP-HAIP_COMMON_GEN_REQ-02). The prefix openid_federation selects the National Trust Framework. The Wallet Unit MUST process x509_hash under EUDIW Authentication. The Wallet Unit MUST process openid_federation under Trust Evaluation Processes by Context when the Trust Chain of the Relying Party is valid under the National Trust Anchor. If that Trust Chain cannot be validated, the Wallet Unit MUST treat the Relying Party as not trustworthy. The Wallet Unit MUST stop the interaction.

In the proximity flow both frameworks use the mdoc reader authentication defined in [ISO18013-5 #12.5]. The Relying Party Instance provides an X.509 certificate in the x5chain header of the ReaderAuth. On the EUDIW path the Wallet Unit MUST authenticate and validate the Wallet-Relying Party Access Certificate as specified in EUDIW Authentication. On the National path the Wallet Unit MUST validate the reader certificate as specified in Relying Party Proximity Authentication. The Wallet Unit MUST run Authorization under the selected framework only. The Relying Party uses the certificate that corresponds to the selected row.

The following requirement applies in the remote flow and in the proximity flow. When the presentation follows the National Trust Framework, the Wallet Unit MUST stop the interaction before Authorization if the request includes any of the following.

a PID.
a QEAA.
a PuB-EAA.
a non-qualified Electronic Attestation of Attributes anchored to the EUDIW Trust Framework by its Rulebook.
a Credential of another Member State.

6.1.3. Failure Handling¶

The failure of the trust evaluation under the selected framework MUST NOT be evaluated again under the other framework.

When the presentation follows the National Trust Framework and Selection at Presentation requires the Wallet Unit to stop the interaction before Authorization, that stop is a failure of Trust Framework selection. The Wallet Unit MUST NOT treat it as overasking. It is not overridable.

If Relying Party authentication fails for any reason, the Wallet Unit SHALL notify the User. In addition, the Wallet Unit SHALL either not present the requested attributes to the Relying Party, or give the User the choice to present the requested attributes or not. ([EIDAS-ARF] RPA_06a). The same applies under the National Trust Framework: a NON_AUTHENTICATED outcome MUST stop the interaction.

If Authentication succeeds and Authorization fails, the Wallet Unit MUST apply Authorization Decision and Override Rules. During presentation, a User choice to proceed is allowed only for the overridable Authorization outcomes defined there. Authentication failure is not overridable.

During Issuance, when Authentication or Authorization does not succeed, the Wallet Unit MUST display a warning to the User. The Wallet Unit MUST NOT request the issuance ([EIDAS-ARF] RPRC_22a). No User choice is offered at issuance.

6.2. Trust Evaluation in the EUDIW Trust Framework¶

The procedures defined in this section profile combine the following external specifications.

ETSI TS 119 615 and ETSI TS 119 612, which define the procedure and the data structures for authenticating and interpreting the List of Trusted Lists and the Member State Trusted Lists, applied here to the Lists of Trusted Entities.
ETSI EN 319 102-1 and ETSI TS 119 182-1, which define, respectively, the validation of AdES signatures and the JAdES format of the signature of a List of Trusted Entities.
ETSI TS 119 411-8, ETSI TS 119 475 and ETSI EN 319 412-1, which define, respectively, the Wallet-Relying Party Access Certificate, the Wallet-Relying Party Registration Certificate together with its entitlements, and the certificate subject attributes.
ETSI TS 119 472-2 and ETSI TS 119 472-3, which profile the Presentation and the Issuance protocols respectively, through which a Wallet-Relying Party is authenticated and its registration information is made available to the Wallet Unit. The latter also defines the Embedded Disclosure Policy.
IETF RFC 5280 (RFC 5280) and IETF RFC 6960 (RFC 6960), which define the X.509 certificate chain validation and the Online Certificate Status Protocol.

Note

The data model of the Trust Artifacts referenced by these procedures, together with the specifications that define them, is defined in EUDIW Trust Artifacts.

The procedures defined in this section are executed within the operational Issuance and Presentation flows (see Digital Credential Flows). The parameters they operate on, such as the signed Request Object, the mdoc Request, the Metadata of all Entities involved and the data model of the received Digital Credentials, are defined in the respective sections (see Entities, Request Object for the Remote Flow, mdoc Request for the Proximity Flow, and SD-JWT-VC Credential Format and mdoc-CBOR Credential Format for the Digital Credential formats).

6.2.1. EUDIW Trust Evaluation Processes by Context¶

The procedures are defined in a general form, with a Trust Evaluator and a Trust Evaluated Party, and the following table defines which entity acts in which role, when and for which purpose.

Table 6.2 Trust Evaluation Processes by Entity and Context in the EUDIW Trust Framework¶
Entity	Context	As Trust Evaluator, implements	As Trust Evaluated Party, provides
Wallet Unit	Issuance of a Credential in the EU catalogue	On the Credential Issuer: EUDIW Authentication EUDIW Authorization EUDIW Metadata Retrieval and Validation On the received Credential: EUDIW Attestation Signature Validation	The Wallet Instance Attestation, validated against the Wallet Providers List of Trusted Entities.
Wallet Unit	Remote presentation, `x509_hash` prefix	On the Relying Party: EUDIW Authentication EUDIW Authorization EUDIW Metadata Retrieval and Validation	No entity level artifact is required from the Wallet Unit.
Wallet Unit	Proximity presentation	On the Relying Party: EUDIW Authentication, based on the mdoc reader authentication EUDIW Authorization	No entity level artifact is required from the Wallet Unit.
Credential Issuer	Issuing Credentials in the EU catalogue	On the Wallet Unit: EUDIW Attestation Signature Validation, applied to the Wallet Instance Attestation	The Wallet-Relying Party Access Certificate used to authenticate the signed Issuer Metadata, and the applicable registration information conveyed in `issuer_info` ([EIDAS-ARF] RPRC_22).
Relying Party	Remote or proximity presentation	On the received Credentials: EUDIW Attestation Signature Validation	The Wallet-Relying Party Access Certificate and the Wallet-Relying Party Registration Certificate included by value in the presentation request ([EIDAS-ARF] RPRC_19).
Relying Party Intermediary	Presentation, on behalf of an intermediated Relying Party	It does not act as Trust Evaluator in the operational flows.	Its own Wallet-Relying Party Access Certificate and the Wallet-Relying Party Registration Certificate of the intermediated Relying Party, included by value in the presentation request ([EIDAS-ARF] RPRC_19).

6.2.2. EUDIW Trust Anchor Validation¶

This section specifies the Trust Anchor Validation Process that a Wallet Unit or Wallet-Relying Party uses to establish the cryptographic integrity and authenticity of a List of Trusted Entities, or a Trusted List, in order to:

validate the trustworthiness of a Trust Anchor (see Trust Anchor Certificate Profile) to authenticate, authorize or validate an entity or artifact during runtime.
validate the information contained in the List for historical purposes.

Depending on the Trust Artifact or Attestation being verified, the Trust Evaluator MUST fetch, download, and validate the List which references the appropriate Trust Anchor:

List of Trusted Entities MUST be used to retrieve Trust Anchors for validating:
- WRPAC in the Providers of WRPAC LoTE.
- WRPRC in the Providers of WRPRC LoTE.
- Wallet Unit Attestation Sign/Seal Certificates in the Wallet Providers LoTE.
- PID Sign/Seal Certificates in the PID Providers LoTE.
- PuB-EAA Sign/Seal Certificates in the PuB-EAA Providers LoTE.
- Registrar Sign/Seal Certificates in the Registrar LoTE.
Trusted Lists are used to retrieve Trust Anchors for validating:
- QEAA Sign/Seal Certificates in the corresponding Member State Trusted List.
For PuB-EAA Sign/Seal Certificates, the corresponding Member State Trusted List MUST be used to establish the qualified status of the issuing CA and certificate. It MUST NOT replace the Trust Anchor's listing in the PuB-EAA Providers LoTE.

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

List of Trusted Entities Validation: Validate the digital signature of the List of Trusted Entities by verifying it against the List of Trusted Entities Provider certificate. This certificate is published in the Official Journal of the European Union.
Trusted List 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 List Of Trusted Lists (LOTL) itself is authenticated by validating its digital signature against the Official Journal of the European Union.

6.2.2.1. EUDIW Trust Anchor Validation: Input¶

The validating Entity MUST base Trust Anchor validation decisions only on information derived from:

The Official Journal of the EU (OJEU) anchoring trust in the root certificates that signed the Lists of Trusted Entities and List of Trusted Lists. The current version of the OJEU is OJEU.
A validated Lists of Trusted Entities or List of Trusted Lists and Member State level Trusted Lists.

6.2.2.2. EUDIW Trust Anchor Validation: Outcome¶

Each validation procedure (defined in List of Trusted Entities Validation and Trusted List Validation) gives a granular verification result code when it detects a negative condition. These codes feed into the final decision:

If the validation algorithms terminate with:
- LoTE-Status == LoTE_VERIFICATION_PASSED, or
- LOTL-Status == LOTL_VERIFICATION_PASSED, or
- EU-TL-Status == EU-TL_VERIFICATION_PASSED.
Then the List of Trusted Entities or Trusted List is valid and the Trust Anchor certificates (see Trust Anchor Certificate Profile) therein MUST be considered trustworthy.
If the validation algorithms terminate with:
- LoTE-Status == LoTE_VERIFICATION_FAILED, or
- LOTL-Status == LOTL_VERIFICATION_FAILED, or
- EU-TL-Status == EU-TL_VERIFICATION_FAILED.
Then the List of Trusted Entities or Trusted List is not valid and the Trust Anchor certificates (see Trust Anchor Certificate Profile) therein MUST NOT be considered trustworthy.

Note

Within IT-Wallet, a Wallet Unit is expected to cache validated Lists of Trusted Lists, Lists of Trusted Entities and Member States' Trusted Lists, so that it does not retrieve them at every interaction. The frequency of updates and the types of lists to cache represent a trade-off between interoperability and resource utilization.

6.2.2.3. List Key Rotation and Historical Verification¶

To support continuous key rotation and regular updates, the LoTE and LOTL implement a pivoting mechanism. This mechanism consists of publishing the most recent version of the List at the primary URI referenced in the Official Journal of the European Union, while archiving earlier versions at other distinct URIs called pivots. Each List version is signed with a public key referenced within the immediately preceding pivot. The last pivot is signed with the key referenced in the OJEU. The newest List version explicitly contains the URIs where all historical versions are hosted.

An Entity validates this chain of pivots from the newest version back to the oldest by verifying that each subsequent artifact is correctly signed by the public key authorized in the prior version. Final validation is achieved by verifying the trustworthiness of the oldest public key, either via a lookup in the OJEU or directly against a cached, previously validated version of the List. This ensures that an entity possessing the last known valid version can reliably discover the next version and validate it via an unbroken chain of trust rooted in the OJEU.

While the pivoting mechanism enables continuous updates to LoTE parameters, certain updates may require adding a ServiceHistory object to the LoTE to preserve the historical keys and configurations needed to validate legacy signatures. The specific scenarios in which an Entity update triggers a migration of its configuration into ServiceHistory are detailed in Trust Management and Lifecycle.

Regardless of an Entity's objective when validating the LoTE (whether retrieving a current or historical configuration), the validation mechanism MUST strictly follow Section List of Trusted Entities Validation.

6.2.2.4. List of Trusted Entities Validation¶

This section defines the validation of a List of Trusted Entities. The List of Trusted Entities, its data model and the List of Trusted Entities types used within the EUDIW ecosystem, one for each category of notified provider, are defined in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

A List of Trusted Entities is a signed list. Its authenticity is rooted in the Official Journal of the European Union, and it supports continuous key rotation through the pivoting mechanism described in List Key Rotation and Historical Verification. The Trust Anchors it publishes are provided in the ServiceDigitalIdentity of its trusted entity service entries, as defined in clause 6.6.3 of [ETSI TS 119 602].

The authentication procedure below follows clause 4.1 of [ETSI TS 119 615], which specifies the authentication of the EC compiled List of Trusted Lists (LOTL) with its pivot mechanism. Here that procedure is applied to the List of Trusted Entities data model of [ETSI TS 119 602] and to its JAdES signature ([ETSI TS 119 182-1]), in place of the XML LOTL. The variables used below are the List of Trusted Entities analogs of the LOTL variables preconfigured in clause 4.0 (GPR-4.0-02) of [ETSI TS 119 615]. They correspond as follows:

OJEU-LoTE-Loc corresponds to OJEU-LOTL-Loc.
OJEU-LoTE-Certs-Set corresponds to OJEU-LOTL-Certs-Set.
LoTESO-Cert corresponds to LOTLSO-Cert.
the PointersToOtherLoTE and SchemeInformationURI claims correspond to the Pointers to other TSLs (clause 6.3.13 of [ETSI TS 119 602]) and Scheme information URI (clause 6.3.7) components.

6.2.2.4.1. List of Trusted Entities Validation Algorithm¶

The validating Entity initializes the following variables, corresponding to the parameters preconfigured in GPR-4.0-02 of [ETSI TS 119 615] for the LOTL.

The input variables of the List of Trusted Entities Validation Algorithm are the following.

OJEU-Loc: URI of the latest known Official Journal of the European Union publication.
OJEU-LoTE-Loc: URI of the last processed List of Trusted Entities. Defaults to the value in OJEU-Loc.
OJEU-LoTE-Certs-Set: the set of trusted certificates from the OJEU-Loc publication.
LoTE: the List of Trusted Entities JWT currently being processed. Initialized as NULL.
LoTE-Signer-Cert: the certificate extracted from the x5c header parameter of the List of Trusted Entities.
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, clause 6.3.10 of [ETSI TS 119 602]) of a List of Trusted Entities.

The output variables of the List of Trusted Entities Validation Algorithm are the following.

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

The process of the List of Trusted Entities Validation Algorithm is the following.

The validation MUST perform the following steps. Each step indicates the corresponding requirement of clause 4.1 of [ETSI TS 119 615].

(Initialization) Download the JWT file from OJEU-LoTE-Loc and assign it to LoTE. (PRO-4.1.4-01)
(Parsing) Extract the first certificate from the x5c header of LoTE and assign it to LoTE-Signer-Cert. (PRO-4.1.4-02)
(Pivot Discovery) Iterate through the uriValue claims in the SchemeInformationURI component (clause 6.3.7 of [ETSI TS 119 602]). Count the number of valid URIs preceding the URI matching OJEU-Loc and assign it to n. (PRO-4.1.4-03 for the search of OJEU-Loc, PRO-4.1.4-04 for the count of n)
- If no URI matches OJEU-Loc: validation MUST fail with LoTE-Status set to LoTE_VERIFICATION_FAILED and LoTE-Sub-Status set to OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE.
(LoTE Location Conflict) Check the condition OJEU-LoTE-Loc != LoTE Location AND LoTE != Content at LoTE Location, where LoTE Location is the LoTELocation URI in the PointersToOtherLoTE component of LoTE with SchemeTerritory EU (clause 6.3.13 of [ETSI TS 119 602]). (PRO-4.1.4-05).
- If TRUE: validation MUST 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.
(LoTE Freshness) Check the condition OJEU-LoTE-Loc == LoTE Location AND LoTE != Content at LoTE Location. (PRO-4.1.4-06).
- If TRUE: set OJEU-LoTE-Loc to LoTE Location and restart from Step 1.
- If FALSE, proceed to the next step.
(Digital Signature Validation) Validate the signature of the current LoTE using the public key from LoTE-Signer-Cert as a directly trusted certificate, following the basic signature validation of [ETSI EN 319 102-1] as required by PRO-4.1.4-07. The Country code and Organization fields in the Subject Distinguished Name of the certificate supporting the AdES digital signature MUST match the scheme territory and one of the scheme operator name values within the LoTE. (PRO-4.1.4-07, PRO-4.1.4-08, clause 6.8.0 of [ETSI TS 119 602])
- 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 (scheme territory EU) of the current LoTE payload. (PRO-4.1.4-09).
(Intermediate Pivot Validation) (PRO-4.1.4-10 for the case n = 0, PRO-4.1.4-11 for the pivot loop)
- 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 MUST 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 as described in step 6. (Digital Signature Validation). If it fails, validation MUST 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.
(Trust Root Validation) Verify the end of the chain. If LoTESO-Cert (from the last Pivot, or from the current LoTE when no Pivot exists) is not in OJEU-LoTE-Certs-Set (the set of trusted certificates), validation MUST fail with LoTE-Sub-Status set to PIVOT_n_SIGNER_CERT_NOT_AUTHENTICATED_BY_OJEU. (PRO-4.1.4-12)
(Expiration) If the current time is greater than the NextUpdate value of LoTE, or it is set to NULL (clause 6.3.15 of [ETSI TS 119 602]), validation MUST fail. (PRO-4.1.4-13)
(Success) Set Authenticated-LoTE to LoTE and LoTE-Status to LoTE_VERIFICATION_PASSED. (PRO-4.1.4-14, PRO-4.1.4-15)
(Update Bookmark) If OJEU-LoTE-Loc does not match the LoTE Location in Authenticated-LoTE (scheme territory EU), update OJEU-LoTE-Loc to that value. (PRO-4.1.4-16)
(Update Trust Root) [Caution: this step modifies the Root of Trust configuration] (PRO-4.1.4-17)
- If OJEU-Loc does not match the first URI in SchemeInformationURI, update OJEU-LoTE-Loc.
- Update OJEU-LoTE-Certs-Set according to the new set of trusted certificates, either in Authenticated-LoTE or from a new Official Journal of the European Union publication.

Note

Steps 4, 5 and 11 allow modifying the location of the List of Trusted Entities file without changing the initial trusted signer public key, as long as both the old and the new location have the same content, otherwise the validation fails with LoTE_FILE_CONFLICT. This allows the List of Trusted Entities to be retrieved from different locations 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 Official Journal of the European Union publication has been updated with a new location for the List of Trusted Entities. The validating Entity SHOULD repeat the validation process after downloading the most recent version of the Official Journal of the European Union.
In step 8, the validating Entity establishes the binding of the signer certificate of the LoTE with the certificate referenced in the Official Journal of the European Union, effectively using the latter as a source of trusted certificates.

Below is a flowchart summarizing the above steps for the validation of the List of Trusted Entities:

The figure illustrates the Flowchart of the List of Trusted Entities Validation Algorithm. — Fig. 6.1 Flowchart of the List of Trusted Entities Validation Algorithm.¶

Below are listed the Sub-Status error codes of the List of Trusted Entities in tabular format.

Table 6.3 List of Trusted Entities Sub-Status Error Codes¶
Code	Phase	Meaning
`OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE`	both	No URI matches the expected `OJEU-Loc` within the `SchemeInformationURI` of the List of Trusted Entities. This typically implies that a newer version of the Official Journal of the European Union publication is available.
`LoTE_FILE_CONFLICT`	both	A location conflict is detected where the tracked List of Trusted Entities location differs from the active one, and the content across these files does not match.
`LoTE_SIGNATURE_VERIFICATION_FAILED`	both	The signature validation of the current List of Trusted Entities file failed using the extracted signer certificate, indicating potential tampering or corruption.
`PIVOT_i-1_SIGNER_CERT_NOT_AUTHENTICATED_BY_PIVOT_i`	both	The historical chain of trust is broken because the signing certificate of the previous pivot or file (i-1) is not found in the trusted certificate set of the succeeding pivot (i).
`PIVOT_i_SIGNATURE_VERIFICATION_FAILED`	both	The signature validation failed for an intermediate pivot file (i) within the historical chain.
`PIVOT_n_SIGNER_CERT_NOT_AUTHENTICATED_BY_OJEU`	both	The final certificate at the root of the pivot chain, or the current List of Trusted Entities signer when no pivot exists, is not found in the `OJEU-LoTE-Certs-Set` set of trusted certificates.

6.2.2.5. Trusted List Validation¶

This section defines the validation of Trusted List. In order to validate the Trusted List, the validating Ent MUST:

Validate the EU List of Trusted Lists using the algorithm described in section 4.1 of [ETSI TS 119 615]. If this fails, the validation stops and the Wallet Unit MUST consider the Entity it is interacting with as not trusted. The validation process is analogue to the List of Trusted Entities Validation except for the LOTL format which is always XML.
Parse the validated EU List of Trusted Lists to discover the necessary certificate to validate the relevant Member State Trusted List.
Obtain and validate the relevant Trusted List as described in section 4.2 of [ETSI TS 119 615].

6.2.3. X509 Certificate Chain Validation Algorithm¶

This procedure validates the certificate chain. It is invoked by the EUDIW Authentication and by the Authorization Artifacts Validation to validate the Wallet-Relying Party Access Certificate, the Wallet-Relying Party Registration Certificate and the Registrar Sign/Seal Certificate chains. The Trust Anchor consumed as trust_anchor is profiled in Trust Anchor Certificate Profile.

The certificate chain validation is the standard X.509 path validation defined in RFC 5280#section-6, with the revocation status checking defined in RFC 5280 and RFC 6960. The certificate lifecycle and the revocation mechanisms, including the CRL and the OCSP formats and parameters, are defined in Revocation Mechanisms. The algorithm details are not redefined here. This is the same certificate chain validation used in the National Trust Framework (see X.509 Certificate Chain Validation), where the difference is the origin of the trust anchor and the additional extraction of the Federation Entity Identifier.

Within the EUDIW Trust Framework the following applies.

The trust_anchor is the trusted certificate obtained from the ServiceDigitalIdentity component of the applicable, validated List of Trusted Entities (see List of Trusted Entities Validation) or Trusted List (see Trusted List Validation), that is the Provider of WRPAC LoTE for the Wallet-Relying Party Access Certificate, the Provider of WRPRC LoTE for the Wallet-Relying Party Registration Certificate, and the Registrar LoTE for the Registrar Sign/Seal Certificate.

The revocation status checking MAY be skipped for a certificate that carries both the noRevAvail and the ETSIValAssuredCertMod extensions (see Wallet-Relying Party Access Certificate (WRPAC) Profile), whose status is then determined solely by its validity period.

Note

As defined in Revocation Trust Anchors, the Trust Anchor retrieved from the applicable LoTE or Trusted List is the notified Trust Anchor for the corresponding certificate chain. The same Trust Anchor MUST be used to validate the signatures of CRLs or OCSP responses used for revocation checking, as specified in RFC 5280#section-6 and RFC 6960.

6.2.3.1. X509 Certificate Chain Validation Algorithm: Input¶

path: the sequence of n certificates C_1, ..., C_n provided by the Entity. C_1 MUST be the end-entity certificate corresponding to the private key used to sign the artifact or Attestation. C_n MUST be the certificate signed by the trust_anchor. The Trust Anchor certificate MUST NOT be included in path. For any i in 1, ..., n-1, C_i+1 MUST be the issuer of C_i.
trust_anchor: the trusted certificate obtained from the ServiceDigitalIdentity of the validated List of Trusted Entities or Trusted List. It MUST contain the public key used to sign C_n. Implementations MUST support both self-signed and non-self-signed Trust Anchor certificates.
current_time: the current date and time.

6.2.3.2. X509 Certificate Chain Validation Algorithm: Outcome¶

The validated end-entity certificate C_1, or a failure.

6.2.3.3. X509 Certificate Chain Validation Algorithm: Process¶

Build the certificate chain from the end-entity certificate C_1 towards the trust_anchor, ending with C_n.
Execute the path validation defined in RFC 5280#section-6, using the trust_anchor as the trust anchor input of the algorithm and current_time as the validation time. The RFC 5280 validation processes the certificates from C_n to C_1. This does not change the order of the presented path.
Verify the revocation status of the certificates in the path according to RFC 5280 and RFC 6960, unless the check is skipped as described above.

If any step fails, the certificate chain MUST be considered invalid. The artifact signature MUST NOT be verified with the presented certificate chain.

6.2.4. EUDIW Attestation Signature Validation¶

This process validates the signature on an Attestation (Digital Credential or Wallet Instance Attestation) using the appropriate Sign/Seal Certificate as profiled in Entity Sign/Seal Certificate Profile. It is invoked during the issuance and presentation flows to validate the signature on the Attestation.

The process MUST be structured as follows.

The following signature validation procedure applies when the Attestation is a PID, a PuB-EAA, a QEAA, or a Wallet Instance Attestation. The signature validation procedure MUST use the Sign/Seal Certificate and the associated X.509 trust chain contained in the Attestation. The Trust Anchor is the one present in the relevant LoTE for a PID, a WIA, or a PuB-EAA. The Trust Anchor is the one present in the Trusted List for a QEAA.
If the Attestation whose signature is being checked is a non-qualified EAA, then information regarding trust evaluation is governed by the corresponding Rulebook.

The signature validation procedure is structured as follows:

6.2.4.1. EUDIW Attestation Signature Validation: Input¶

The received Attestation and the signer certificate chain carried within it.
The type of artifact (i.e., the Digital Credential type or Wallet Instance Attestation) used to select the applicable List of Trusted Entities or Trusted List.

6.2.4.2. EUDIW Attestation Signature Validation: Outcome¶

The validated Attestation, or a validation failure.

6.2.4.3. EUDIW Attestation Signature Validation: Process¶

This process depends on the Attestation type:

PID or WIA.
1. Verify the Attestation signature with the Sign/Seal certificate provided in the Attestation.
2. Select the applicable List of Trusted Entities according to the type of the received Attestation, validate it as defined in List of Trusted Entities Validation, and extract the appropriate Trust Anchor from the relevant Entity's ServiceDigitalIdentity field.
3. Extract the Sign/Seal certificate chain from the Attestation and validate it against the obtained Trust Anchor, as defined in X509 Certificate Chain Validation Algorithm.
QEAA.
1. Verify the Attestation signature using the Sign/Seal certificate provided in the Attestation. For a QEAA, the qualified electronic signature or seal MUST be validated in accordance with Article 32 of [EIDAS].
2. Fetch the appropriate Trusted List according to the nationality of the Credential Issuer, validate it as defined in Trusted List Validation, and extract the appropriate Trust Anchor from the relevant Entity's ServiceDigitalIdentity field.
3. Extract the signer certificate chain from the Attestation and validate it against the obtained Trust Anchor, as defined in X509 Certificate Chain Validation Algorithm.
PuB-EAA.
1. Verify the Attestation signature with the Sign/Seal Certificate provided in the Attestation. A qualified electronic signature MUST be validated in accordance with Article 32 of [EIDAS]. Where the Provider is a legal person using an electronic seal, Articles 37 and 40 apply.
2. Fetch and validate the PuB-EAA Providers LoTE as defined in List of Trusted Entities Validation, match the Provider and its Sign/Seal Certificate with the relevant TrustedEntityList object, and extract its Trust Anchor.
3. Extract the signer certificate chain from the Attestation and validate it against the Trust Anchor obtained from the LoTE, as defined in X509 Certificate Chain Validation Algorithm.
4. Fetch the Member State Trusted List corresponding to the issuing CA, validate it as defined in Trusted List Validation, and establish the qualified status of the issuing CA and Sign/Seal Certificate.

Note

In each of the above cases, for an Attestation in mdoc format, the Mobile Security Object carries the Document Signer certificate in the x5chain header, as defined in [ISO18013-5]. For an Attestation in SD-JWT VC format, the issuer certificate chain is carried in the x5c header of the JOSE signature.

Note

When verifying signatures or seals made by historical keys, the same process applies albeit with the following difference: the Trust Anchor is retrieved from the ServiceHistory.ServiceDigitalIdentity element instead of the ServiceInformation.ServiceDigitalIdentity element.

If signature validation fails, the Attestation MUST NOT be considered as issued by a trusted Entity.

6.2.5. EUDIW Authentication¶

The Authentication Process enables the Wallet Unit to authenticate a Wallet-Relying Party during an interaction. It establishes trust by validating the Wallet-Relying Party X.509 certificate chain, from a trusted Provider of Wallet-Relying Party Access Certificate down to the presented Wallet-Relying Party Access Certificate, and by verifying that the Wallet-Relying Party possesses the corresponding private key. The Wallet-Relying Party Access Certificate is profiled in Wallet-Relying Party Access Certificate (WRPAC) Profile.

For the verification of the access certificate, the Wallet Unit MUST accept only the Trust Anchors published in the Lists of Trusted Entities of the Providers of Wallet-Relying Party Access Certificate notified by the Member States (see List of Trusted Entities Validation). The Wallet Unit MUST perform this authentication and validation itself. The Wallet Unit MUST NOT delegate it to an operating system browser or to another intermediary application ([CIR2024/2982] Article 3(1), as replaced by [CIR2026/1731]).

6.2.5.1. EUDIW Authentication: Input¶

The Authentication outcome MUST be based only on information derived from:

the appropriate Trust Anchor obtained from a valid instance of the Provider of Wallet-Relying Party Access Certificate List of Trusted Entities.
the X.509 certificate chain starting with the Wallet-Relying Party Access Certificate end-entity certificate.
a Wallet-Relying Party signature over the artifact of the interaction, carrying the proof of possession of the private key referenced in the Wallet-Relying Party Access Certificate.

6.2.5.2. EUDIW Authentication: Outcome¶

The Wallet Unit MUST output a decision: the Wallet-Relying Party is either AUTHENTICATED or NON_AUTHENTICATED. If AUTHENTICATED, the Wallet Unit proceeds in the interaction flow. If NON_AUTHENTICATED, the Wallet Unit MUST inform the User that the identity of the Wallet-Relying Party could not be verified. The Wallet Unit MUST stop the interaction, as the entity is not trustworthy.

6.2.5.3. EUDIW Authentication: Process¶

The Wallet Unit MUST verify the authenticity and integrity of the presented Wallet-Relying Party Access Certificate as follows:

Retrieve the Trust Anchor: obtain the entry of the Provider of Wallet-Relying Party Access Certificate from the validated List of Trusted Entities (see List of Trusted Entities Validation). When present, the issuer.organizationIdentifier of the last certificate of the chain MAY be used to locate candidate entries by matching it against the registration identifier in TrustedEntitiesList[].TrustedEntityInformation.TETradeName, as defined in clause 5.1.4 of [ETSI EN 319 412-1] and Annex F, Table F.2 of [ETSI TS 119 602]. The Wallet Unit MUST retrieve candidate Trust Anchor certificates from the ServiceDigitalIdentity of the entry's service whose ServiceTypeIdentifier is http://uri.etsi.org/19602/SvcType/WRPAC/Issuance, as defined in Annex F, Table F.3 of [ETSI TS 119 602]. The selected Trust Anchor MUST validate the presented certificate chain at step 3.
Construct the Certificate Chain: build a certificate chain starting from the Wallet-Relying Party Access Certificate presented by the Wallet-Relying Party (C_1) and ending with the certificate issued by the Provider of Wallet-Relying Party Access Certificate (C_n). The simplest path consists of a single certificate, where n = 1.
Execute Path Validation: validate the certificate chain as defined in X509 Certificate Chain Validation Algorithm, using the Trust Anchor retrieved at step 1, as described in Wallet-Relying Party Access Certificate Validation.
Verify the Signature: use the public key of the validated Wallet-Relying Party Access Certificate to verify the Wallet-Relying Party signature over the artifact it signs in the specific interaction. The certificate chain and the signed artifact depend on the flow:
- Remote Flow: the chain is carried in the x5c header of the Wallet-Relying Party signed Request Object, and the Relying Party is authenticated through the x509_hash Client Identifier Prefix, as defined in [OpenID4VP] and [OPENID4VC-HAIP].
- Proximity Flow: the chain is carried in the mdoc reader authentication (ReaderAuth) signed by the Wallet-Relying Party, in the COSE x5chain header (label 33), as defined in [ISO18013-5].
- Issuance Flow: the chain is carried in the x5c header of the Wallet-Relying Party signed Credential Issuer Metadata, as defined in [OpenID4VCI].

Warning

A Wallet-Relying Party MUST distinguish between transient authentication (e.g., access control) and content commitment (non-repudiation). To prevent an attacker from disguising a legal commitment as a protocol nonce, the Wallet-Relying Party MUST NOT use the Wallet-Relying Party Access Certificate private key to sign arbitrary data that could be controlled by an external party.

6.2.5.4. Wallet-Relying Party Access Certificate Validation¶

The Entity performing Wallet-Relying Party Access Certificate validation initializes the algorithm in X509 Certificate Chain Validation Algorithm with the path and trust_anchor defined there. The inputs are the following:

C_1 is the first certificate of the chain provided by the Wallet-Relying Party and is the Wallet-Relying Party Access Certificate used to sign the artifact.
C_n is the last certificate of the chain and is signed by the trust_anchor.
trust_anchor is a certificate of the Provider of Wallet-Relying Party Access Certificate obtained from the List of Trusted Entities.

Warning

As described in Section 6.1.1 of OPENID4VC-HAIP, the Trust Anchor Certificate needed for the validation of the WRPAC MUST NOT be included in the certificate chain. The Trust Anchor Certificate MUST always be retrieved from the appropriate LoTE.

6.2.6. EUDIW Authorization¶

This section specifies the EUDIW Authorization Process that a Wallet Unit MUST execute to determine whether an interaction with a Wallet-Relying Party is allowed within the EUDI Wallet ecosystem. The EUDIW Authorization Process MUST start only after the Wallet-Relying Party has been successfully authenticated according to EUDIW Authentication. If the Wallet-Relying Party has not been authenticated, the EUDIW Authorization Process MUST NOT start.

The authorization data of a Wallet-Relying Party is carried by the Wallet-Relying Party Registration Certificate. During Credential Presentation the Wallet-Relying Party Registration Certificate MUST be included by value in the request ([EIDAS-ARF] RPRC_19) and is the sole authoritative source for presentation authorization ([EIDAS-ARF] RPRC_17, RPRC_21). During Credential Issuance a PID Provider or Attestation Provider MUST convey the applicable registration information in the signed Credential Issuer Metadata through issuer_info ([EIDAS-ARF] RPRC_22). The registration_cert and registrar_dataset are mandatory.

The EUDIW Authorization Process is split into:

Authorization Artifacts Validation, which validates integrity and authenticity of the Trust Artifact carrying the authorization data. And.
Authorization Validation, which validates the information content of the validated artifact. In particular this validation covers:
- Issuance authorization: determines whether a Credential Issuer is registered for the relevant role and authorized to issue the specific Digital Credential. This applies to PID, QEAA, PuB-EAA and EAA Providers operating within the EUDIW ecosystem.
- Presentation authorization: determines whether a Relying Party request falls within its registered scope, whether an Embedded Disclosure Policy permits the disclosure, and whether the User approves. This applies to interactions involving both Relying Parties and Relying Party Intermediaries, across both Remote and Proximity Flows.
Authorization Decision and Override Rules, which outputs an Authorization Decision expressed as AUTHORIZED or NOT_AUTHORIZED on the base of the Authorization Artifacts Validation and Authorization Validation results. Depending on the Flow type the User MAY override the Authorization Decision.

Within the Authorization Validation, the Wallet Unit MUST distinguish between the authenticated Wallet-Relying Party and the Authorization Subject, that is the entity whose authorization is being evaluated:

During Issuance, the Authorization Subject is the Credential Issuer.
During direct presentation, the Authorization Subject is the Relying Party.
During intermediated presentation, the authenticated Wallet-Relying Party is the Relying Party Intermediary, while the Authorization Subject for the data request is the intermediated Relying Party, whose registered scope governs the request. The Relying Party Intermediary is itself a registered entity, and its authorization to act as an intermediary is established through the intermediary binding declared in the intermediated Relying Party authorization data (see the Binding verification below).

The Wallet Unit MUST support authorization-context resolution from the Wallet-Relying Party Registration Certificate included in the interaction. The Wallet Unit MUST NOT query the Register as a substitute for a missing or invalid Wallet-Relying Party Registration Certificate during Credential Presentation ([EIDAS-ARF] RPRC_16, RPRC_18 and RPRC_19a are empty) or during Credential Issuance ([EIDAS-ARF] RPRC_22 and RPRC_22a).

6.2.6.1. Authorization Artifacts Validation¶

The Wallet-Relying Party Registration Certificate carries the authorization data of an entity, in the JWT and CWT profiles defined in Section 5.2.1 of [ETSI TS 119 475].

Each validation procedure specifies its inputs, its processing logic and its output, a verification result code. The result MAY be overridden by the User under the conditions detailed in Authorization Decision and Override Rules.

The validation flow depends on the interaction.

During the Presentation flow the Relying Party MUST convey the Wallet-Relying Party Registration Certificate by value ([EIDAS-ARF] RPRC_19):
in the data member of the verifier_info element whose format is registration_cert in the Request Object, in the Remote Flow, as defined in [ETSI TS 119 472-2] and Section 5.1 of [OpenID4VP].

in the euWrprc member of requestInfo in the ISO DeviceRequest, in the Proximity Flow, as defined in Section 5.3 of [ETSI TS 119 472-2] and in [ISO18013-5].
In the Remote Flow, verifier_info MUST also contain an element whose format is registrar_dataset for ETSI transport and transparency. That element's data object MUST contain the registered identifier, srvDescription, registryURI, intendedUseIdentifier, purpose and policyURI fields as specified in the Remote Flow. It MUST NOT replace or override the Wallet-Relying Party Registration Certificate as the presentation authorization source ([EIDAS-ARF] RPRC_19a is empty).

In the Proximity Flow, every ItemsRequest MUST contain a non-empty requestInfo.euWrpRegistrarInfo with its non-empty identifier array, non-empty srvDescription and purpose arrays, registryURI, intendedUseIdentifier and policyURI. Optional credential data is non-empty when present. This Registrar data is for transparency and identity binding. It MUST NOT replace the mandatory WRPRC-by-value. It MUST NOT trigger a Register lookup.
During the Issuance flow a PID Provider or Attestation Provider MUST convey the applicable registration information in the signed Credential Issuer Metadata ([EIDAS-ARF] RPRC_22), through the top-level issuer_info array defined in Section 4.2.3 of [ETSI TS 119 472-3]. Each element contains format and data. The array MUST contain a registration_cert element with the Wallet-Relying Party Registration Certificate by value. The array MUST contain a registrar_dataset element with the registration information. The registrar_dataset MUST NOT replace certificate validation when registration_cert is present. The Embedded Disclosure Policy is distributed as the embedded_disclosure_policy member of credential_metadata within credential_configurations_supported, as defined in [OpenID4VCI] and Embedded Disclosure Policy (EDP).

During Credential Presentation, if the Wallet-Relying Party Registration Certificate is not available or its validation fails, the Wallet Unit MUST set authz_art_state to CERTIFICATE_INVALID. The Wallet Unit MUST warn the User ([EIDAS-ARF] RPRC_17). The Wallet Unit MUST NOT query the Register as a fallback ([EIDAS-ARF] RPRC_16 and RPRC_18 are empty).

During Credential Issuance, if the Wallet-Relying Party Registration Certificate is not available or its validation fails, the Wallet Unit MUST set authz_art_state to CERTIFICATE_INVALID. The Wallet Unit MUST warn the User that the Wallet Unit could not obtain or validate the registered information. The Wallet Unit MUST NOT request the issuance of a PID or attestation ([EIDAS-ARF] RPRC_22a). The Wallet Unit MUST NOT query the Register as a fallback ([EIDAS-ARF] RPRC_22).

6.2.6.1.1. Wallet-Relying Party Registration Certificate Validation¶

When a Wallet-Relying Party Registration Certificate is available, the Wallet Unit MUST validate it before relying on it:

Format verification: confirm that typ is rc-wrp+jwt in the Remote Flow and during Credential Issuance, or rc-wrp+cwt in the Proximity Flow, as defined in Section 5.2.1 of [ETSI TS 119 475].
Algorithm verification: verify that the signature algorithm is conformant, that is alg is neither none nor a deprecated algorithm.
Signature validation: verify that the Wallet-Relying Party Registration Certificate signature is valid.
Trust Anchor validation: validate the Providers of WRPRC LoTE (see List of Trusted Entities Validation) and retrieve the Trust Anchor from its TrustedEntitiesList.ServiceDigitalIdentity field.
Path validation: validate the Wallet-Relying Party Registration Certificate chain as defined in X509 Certificate Chain Validation Algorithm, using the trust_anchor obtained in the previous step. For the WRPRC, the Trust Anchor used for signature validation, certificate chain validation, and revocation checking MUST be retrieved from the applicable service entry in the Providers of WRPRC LoTE (i.e., under the ServiceDigitalIdentity corresponding to the ServiceTypeIdentifier with value http://uri.etsi.org/19602/SvcType/WRPRC/Issuance).
Temporal validity: check iat and exp if present.
Status verification: check the revocation status through the status field of the Wallet-Relying Party Registration Certificate, as defined in [ETSI TS 119 475]:
- fetch the SLT (see Token Status List (WRPRC Profile)) at the URI specified by the WRPRC's status.status_list.uri member.
- validate the SLT signing certificate chain as defined in X509 Certificate Chain Validation Algorithm, using the Trust Anchor retrieved from the applicable service entry in the Providers of WRPRC LoTE (i.e., under the ServiceDigitalIdentity corresponding to the ServiceTypeIdentifier with value http://uri.etsi.org/19602/SvcType/WRPRC/Revocation for the service provided by the Provider of WRPRC).
- validate the SLT signature using the validated signing certificate chain, following EUDIW Attestation Signature Validation.
- validate the SLT data model according to Token Status List (WRPRC Profile).
- decompress the status_list.lst value, retrieve the one-bit entry corresponding to the WRPRC's status.status_list.idx member, and interpret 0x00 as VALID and 0x01 as INVALID.
Consistency check: verify that the subject and the fields of the Wallet-Relying Party Registration Certificate are consistent with the interaction.

Note

In Step 5 (Path validation), the Trust Anchor Certificate needed to validate the WRPRC MUST NOT be included in the certificate chain and MUST always be retrieved from the appropriate LoTE.

6.2.6.1.2. Authorization Artifacts Validation: Outcome¶

If all the steps succeed and the Wallet-Relying Party Registration Certificate is in the VALID state, the Wallet Unit MUST set authz_art_state to CERTIFICATE_VALID.
If any step fails, or if no Wallet-Relying Party Registration Certificate is included, the Wallet Unit MUST set authz_art_state to CERTIFICATE_INVALID. During Credential Presentation the Wallet Unit MUST warn the User ([EIDAS-ARF] RPRC_17). The Wallet Unit MUST NOT query the Register. During Credential Issuance the Wallet Unit MUST warn the User. The Wallet Unit MUST NOT request issuance ([EIDAS-ARF] RPRC_22a). The Wallet Unit MUST NOT query the Register as a fallback ([EIDAS-ARF] RPRC_22).

Note

During Credential Presentation the request MUST carry the Wallet-Relying Party Registration Certificate of the Authorization Subject by value, including when the authenticated Wallet-Relying Party is a Relying Party Intermediary ([EIDAS-ARF] RPRC_19). That certificate identifies the intermediated Relying Party.

6.2.6.2. Authorization Validation¶

The Authorization Validation MUST follow the Authorization Artifacts Validation when authz_art_state == CERTIFICATE_VALID. If authz_art_state == CERTIFICATE_INVALID, the Wallet Unit SHOULD NOT execute any Authorization Validation, as it cannot change the final Authorization Decision.

6.2.6.2.1. Authorization Validation: Input¶

The Wallet Unit MUST base the Authorization Validation only on:

the authenticated Wallet-Relying Party and the interaction context, authoritative only for the identity of the Wallet-Relying Party.
a validated Authorization Artifact, that is a Wallet-Relying Party Registration Certificate, authoritative for the subject identity, entitlements, intended use, registered scope, intermediary relationships, issuance-specific data and privacy policy references, as defined in [ETSI TS 119 475].
a verified Embedded Disclosure Policy, REQUIRED when provided by the Attestation Provider during Credential Issuance, authoritative when present.

Where the authenticated Wallet-Relying Party context conflicts with the identity or the intermediary binding in the verified authorization context, the Wallet Unit MUST produce NOT_AUTHORIZED, non-overridable.

6.2.6.2.2. Authorization Validation: Outcome¶

The Wallet Unit MUST output the authz_val_state and edp_state variables, both initialized to none.

6.2.6.2.3. Authorization Validation: Process¶

Binding verification. The Wallet Unit MUST ensure that the authenticated entity is the same as the entity described in the authorization data. The Wallet-Relying Party identity is the organizationIdentifier of the Wallet-Relying Party Access Certificate subject (clause 5.1.4 of [ETSI EN 319 412-1]. The Wallet-Relying Party Access Certificate profile is defined in [ETSI TS 119 411-8]).
- Credential Issuance. The Wallet Unit MUST match the Credential Issuer identifier with the subject of a supplied Wallet-Relying Party Registration Certificate and with the applicable identifier in issuer_info[].data.identifier[] of the Credential Issuer Metadata ([EIDAS-ARF] RPRC_22b).
- Credential Presentation. The Wallet Unit MUST first assume the direct scenario and match the Relying Party identifier in the Wallet-Relying Party Access Certificate (organizationIdentifier or serialNumber) with the sub of the Wallet-Relying Party Registration Certificate, and with the data.identifier of the verifier_info element whose format is registrar_dataset in the Request Object in the Remote Flow or an applicable registered identifier in the docRequests[].itemsRequest[].requestInfo.euWrpRegistrarInfo.identifier array in the Proximity Flow. If the match fails, the Wallet Unit MUST attempt the intermediated scenario ([EIDAS-ARF] RPRC_17a): the WRPAC subject is the Intermediary, the WRPRC identifies a different Relying Party, and the WRPRC intermediary object identifies this Intermediary ([EIDAS-ARF] RPRC_04). Association of a distinct WRPAC to that Relying Party and Service is deferred as specified in Register of WRPs.
If the Binding verification fails, the Wallet Unit MUST stop the Authorization Validation and set authz_val_state to BINDING_FAILED. If the direct scenario succeeds, the Wallet Unit MUST make available to the User the identity and Service of the Relying Party, and the intended use of the request. If the intermediated scenario succeeds, the Wallet Unit MUST make available to the User the identity and Service of the intermediated Relying Party and the intended use of the request. It MUST NOT display the trade names of the Intermediary or of the Intermediary Service ([EIDAS-ARF] RPI_07). How this information is presented is defined in the relevant User interaction sections of the IT-Wallet specification. There is no User opt-in Registrar lookup of the intermediary relationship ([EIDAS-ARF] RPI_07a is empty).
Entitlement verification. The Wallet Unit MUST verify that the entitlements of the Authorization Subject match the expected role. The Wallet Unit MUST parse the entitlements field of the Wallet-Relying Party Registration Certificate and check that it contains the entitlement URI expected for the interaction, among those defined in Annex A.2 of [ETSI TS 119 475]:
- https://uri.etsi.org/19475/Entitlement/PID_Provider for PID Providers, during PID Issuance.
- https://uri.etsi.org/19475/Entitlement/QEAA_Provider for QEAA Providers, during QEAA Issuance.
- https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider for PuB-EAA Providers, during PuB-EAA Issuance.
- https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider for EAA Providers, during EAA Issuance.
- https://uri.etsi.org/19475/Entitlement/Service_Provider for Relying Parties, during Credential Presentation.
If the expected entitlement is not present, the Wallet Unit MUST set authz_val_state to WRONG_ENTITLEMENT.
Attestation Type verification. During Credential Issuance, the Wallet Unit MUST verify that the PID or the Attestation Type being issued is registered for the Credential Issuer. A PID Provider issuing PIDs MAY skip this step. Otherwise the Wallet Unit MUST match the provides_attestations array of the Wallet-Relying Party Registration Certificate (defined in Table 8 of [ETSI TS 119 475] and in [EIDAS-ARF] RPRC_23) against the credential_configurations_supported keys of the Credential Issuer Metadata ([OpenID4VCI]). The match MUST be exact and case sensitive, on vct for SD-JWT VC and on docType for mdoc. If not found, the Wallet Unit MUST set authz_val_state to ATTESTATION_TYPE_NOT_REGISTERED.
Scope Comparison. During Credential Presentation, the Wallet Unit MUST verify that the requested Digital Credentials and attributes fall within the registered scope, carried in the credentials array of the Wallet-Relying Party Registration Certificate included in the request (defined in Table 9 of [ETSI TS 119 475] and in [EIDAS-ARF] RPRC_21).
- Remote Flow: extract the requested Digital Credentials and attributes from the dcql_query of the Request Object ([OpenID4VP]) and match them against the credentials entries, comparing format and meta (vct_values for SD-JWT VC) and the requested attributes against the claim paths.
- Proximity Flow: extract the docType and the nameSpaces from the docRequests of the mdoc Request ([ISO18013-5]) and match them against credentials[].meta.doctype_value and credentials[].claim respectively.
The match MUST be exact and case sensitive. If any requested Digital Credential or attribute is not registered, the Wallet Unit MUST set authz_val_state to OVERASKING_DETECTED and identify the unregistered attributes or Digital Credentials.

If all the checks above that apply to the interaction are satisfied, the Wallet Unit MUST set authz_val_state to VERIFICATION_PASSED.
Embedded Disclosure Policy evaluation. During Credential Issuance, the Wallet Unit MUST resolve the EDP identified by the selected Credential metadata. The Wallet Unit MUST associate the resolved policy with each issued EAA. During Credential Presentation, for each Digital Credential and each requested attribute, the Wallet Unit MUST evaluate the associated EDP before User consent. If an EDP URI cannot be resolved to the exact included or preloaded policy, the EDP evaluation MUST fail. That failure is not EDP_NOT_SATISFIED and is non-overridable, as specified in Authorization Decision and Override Rules. An EDP MUST NOT be evaluated for a PID. According to the policy_type defined in Section 4.2.5 of [ETSI TS 119 472-3]:
- no_policy: no restriction applies.
- authorized_rp_only: only the Relying Parties in the authorized_parties list are authorized. The Wallet Unit MUST retrieve the EU-wide unique identifier from the WRPRC in the request (sub) and compare it with authorized_parties[].identifier ([EIDAS-ARF] EDP_02, Reg_32). The Service identifier of that duplet is deferred as specified in Register of WRPs. Where an authorized_parties element identifies the party by entitlement_uri, the Wallet Unit MUST match that URI against the entitlements or sub-entitlements of the same WRPRC. A match on the identifier or on entitlement_uri is sufficient. If neither matches, the Wallet Unit MUST consider the EDP evaluation to have failed. The Wallet Unit MUST NOT use identifiers from the WRPAC, including the Relying Party subject DN of a Wallet-Relying Party Access Certificate. If authorized_parties[].subject_dn is present, it is the ETSI encoding defined in Embedded Disclosure Policy (EDP) and MUST NOT be used as a substitute for sub. In an intermediated presentation the WRPRC in the request is that of the intermediated Relying Party.
- specific_root_of_trust: only authenticated Relying Parties whose Wallet-Relying Party Access Certificate is signed under one of the trusted_roots are authorized ([EIDAS-ARF] EDP_03). The Wallet Unit MUST match each trusted_roots entry by issuer_dn using LDAP DN comparison and serial_number using integer comparison. It MUST compare all certificates in the WRPAC signing path with those authorised root or intermediate certificates. The path comprises the WRPAC presented in x5c and the Trust Anchor retrieved from the Providers of WRPAC LoTE. If none of these certificates is included in the list, the Wallet Unit MUST consider the EDP evaluation to have failed. In an intermediated presentation the authenticated Relying Party is the Intermediary. The Wallet Unit MUST compare that Intermediary's WRPAC signing path.
The Wallet Unit MUST apply the base policy to the Credential and any recognized attribute-specific rule to the selected Credential-format claim path. The Wallet Unit MUST inform the User of the Credential-level and attribute-level results, including the policy information link when present, before consent. The Wallet Unit MUST NOT disclose an attribute when the Credential-level result or its applicable attribute-level result of a resolved policy is unsatisfied, unless the User overrides that result as specified in Authorization Decision and Override Rules. Unknown extensions MAY be ignored only when doing so does not break processing of recognized rules.

If the applicable checks of a resolved policy are satisfied, or no EDP is present for an EAA, the Wallet Unit MUST set the Credential or attribute result to EDP_SATISFIED. If a resolved policy does not permit the Credential or attribute, the Wallet Unit MUST set that result to EDP_NOT_SATISFIED.

6.2.6.2.4. Authorization Validation: Final Outcome¶

At the end of the Authorization Validation the Wallet Unit MUST output the authz_val_state and edp_state values. The table below summarizes the codes.

Table 6.4 Authorization Validation State Codes¶
Variable	Code	Phase	Meaning
`authz_art_state`	`CERTIFICATE_VALID`	both	The Wallet-Relying Party Registration Certificate format, signature, trust anchor and status are successfully verified.
`authz_art_state`	`CERTIFICATE_INVALID`	both	A format, signature, trust anchor or status check fails on the presented registration certificate, or no Wallet-Relying Party Registration Certificate is included. During presentation the Wallet Unit MUST warn the User ([EIDAS-ARF] RPRC_17). The Wallet Unit MUST NOT query the Register. During issuance the Wallet Unit MUST warn the User. The Wallet Unit MUST NOT request issuance ([EIDAS-ARF] RPRC_22a). The Wallet Unit MUST NOT query the Register as a fallback ([EIDAS-ARF] RPRC_22).
`authz_val_state`	`WRONG_ENTITLEMENT`	both	The entitlements of the Authorization Subject do not match the expected role for the active context.
`authz_val_state`	`BINDING_FAILED`	both	The identity binding between the authenticated Wallet-Relying Party and the authorization data fails.
`authz_val_state`	`ATTESTATION_TYPE_NOT_REGISTERED`	issuance	The Attestation Type being issued is not found in the Credential Issuer registered profiles.
`authz_val_state`	`OVERASKING_DETECTED`	presentation	The Relying Party requests Digital Credentials, formats or namespaces that exceed its registered scope.
`authz_val_state`	`VERIFICATION_PASSED`	both	Identity binding, entitlement verification, attestation matching and scope checking all passed.
`edp_state`	`EDP_SATISFIED`	presentation	No Embedded Disclosure Policy restriction applies, or the Credential/attribute and Relying Party satisfy the resolved policy.
`edp_state`	`EDP_NOT_SATISFIED`	presentation	A resolved Embedded Disclosure Policy does not permit this Credential or attribute for this Relying Party. The Wallet Unit informs the User, who allows or denies the disclosure, as specified in Authorization Decision and Override Rules ([EIDAS-ARF] EDP_07). This code does not apply to issuance.

The final Authorization Decision, AUTHORIZED or NOT_AUTHORIZED, is elaborated from the authz_art_state, authz_val_state and edp_state values, as defined in Authorization Decision and Override Rules.

Fig. 6.2 Flowchart of the EUDIW Authorization Algorithm.¶

6.2.7. EUDIW Metadata Retrieval and Validation¶

Within the EUDIW Trust Framework the metadata of a Wallet-Relying Party are obtained through the protocol flow and their authenticity is established through the Wallet-Relying Party Access Certificate. This applies to Credential Issuance and to Credential Presentation in the Remote Flow. In the Proximity Flow no separate metadata retrieval is performed: the Relying Party identity is established through the mdoc reader authentication (see EUDIW Authentication).

6.2.7.1. Metadata Retrieval¶

The Wallet Unit obtains the metadata of the Wallet-Relying Party according to the interaction:

During Credential Issuance, the Credential Issuer Metadata is obtained from the Credential Issuer well-known metadata endpoint, as defined in [OpenID4VCI] (see Metadata Endpoints).
During Credential Presentation in the Remote Flow, the Relying Party metadata is carried in the Request Object of the authorization request, as defined in [OpenID4VP] (see Request Object).

6.2.7.2. Metadata Validation¶

The authenticity of the retrieved metadata is established through the Wallet-Relying Party Access Certificate. During Credential Issuance, the Credential Issuer Metadata is signed by the Attestation Provider as defined in Section 12.2.3 of [OpenID4VCI], providing the Wallet-Relying Party Access Certificate chain in the protected x5c header of the JOSE signature. The first certificate MUST be the signing access certificate. The trust anchor MUST be excluded.

The Wallet Unit MUST validate the certificate chain and signature before using the payload. The Wallet Unit MUST use that authenticated payload as the sole metadata source for the interaction, including its issuer_info, grants, reuse policy, and EDP.

During Credential Presentation in the Remote Flow, the Request Object is signed by the Relying Party and provides the same x5c header. In both cases the Wallet Unit validates the signature and the certificate chain as defined in EUDIW Authentication. The Wallet Unit MUST use only the metadata whose signature is verified against the authenticated Wallet-Relying Party Access Certificate.

6.3. Trust Evaluation in the National Trust Framework¶

This section defines the trust evaluation procedures of the National Trust Framework. The Entity Type Identifiers and the metadata of each role, used during these procedures, are defined in Entity Type Identifiers and Metadata, according to that profile. The selection rules that define when these procedures apply are detailed in Trust Framework Selection. These procedures apply when the Trust Evaluated Party is authenticated under the National Trust Framework.

The Trust Artifacts used during these procedures, that is the Entity Configuration, the Subordinate Statements, the Trust Marks, are defined in National Trust Artifacts.

The procedures defined in this section are executed within the operational Issuance and Presentation flows (see Digital Credential Flows). The parameters they operate on, such as the signed Request Object, the mdoc Request, the Metadata of all Entities involved and the data model of the received Digital Credentials, are defined in the respective sections (see Entities, Request Object for the Remote Flow, and SD-JWT-VC Credential Format and mdoc-CBOR Credential Format for the Digital Credential formats).

6.3.1. Trust Evaluation Processes by Context¶

The procedures are defined in a general form, with a Trust Evaluator and a Trust Evaluated Party and the following table defines which entity acts in which role, when and for which purpose.

Table 6.5 Trust Evaluation Processes by Entity and Context in the National Trust Framework¶
Entity	Context	As Trust Evaluator, implements	As Trust Evaluated Party, provides
Wallet Unit	Issuance of a national only Credential	On the Credential Issuer: Federation Entity Authentication Authorization Metadata Retrieval and Validation On the received Credential: Signing Trust Anchor Validation Procedure	The Wallet Instance Attestation with the proof of possession of the attested key, validated as defined in Wallet Unit Authentication.
Wallet Unit	Remote presentation, `openid_federation` prefix	On the Relying Party: Federation Entity Authentication Authorization, including the Overasking Check Metadata Retrieval and Validation	No entity level artifact is required from the Wallet Unit.
Wallet Unit	Proximity presentation	On the Relying Party: Relying Party Proximity Authentication Authorization, including the Overasking Check, on the registration Trust Mark provided by value in `requestInfo.euWrprc` of every ISO `ItemsRequest`	No entity level artifact is required from the Wallet Unit.
Credential Issuer	Issuing national only Credentials	On the Wallet Unit: Wallet Unit Authentication	The Entity Configuration (Entity Configuration) with the registration Trust Marks (Trust Mark registration-entity), and the issuance artifacts signed with keys resolvable through the federation, validated as defined in Federation Entity Authentication. For the mdoc format, the Document Signer certificate in the `x5chain` header, validated as defined in X.509 Certificate Chain Validation.
Relying Party	Remote presentation, `openid_federation` prefix	On the received Credentials: Signing Trust Anchor Validation Procedure On the Wallet Provider, to invoke the Wallet through the national discovery mechanism (see the note below): Metadata Retrieval and Validation	The Entity Configuration (Entity Configuration) with the registration Trust Marks (Trust Mark registration-entity), and the signed Request Object with keys resolvable through the federation, including the `trust_chain` header when offline validation is expected, validated as defined in Federation Entity Authentication and Authorization.
Relying Party Intermediary	Remote presentation, as the Federation Intermediate of an affiliated Relying Party	It does not act as Trust Evaluator in the operational flows.	The Entity Configuration (Entity Configuration) with the `intermediate` registration Trust Mark (see Trust Mark Types and Schema), and the Subordinate Statements of its affiliated Relying Parties. The Intermediary is validated as part of the affiliated Relying Party's Trust Chain, whose `authority_hints` point to it. The Wallet Unit MUST verify that the affiliated Relying Party's Trust Chain is validated through a recognized Intermediary or directly through the Federation Trust Anchor, and it informs the User as defined in User Transparency.

Note

In the remote flow the Relying Party invokes the Wallet through app links (universal links) instead of custom URL schemes. This IT-Wallet choice requires the Relying Party to obtain and validate the Wallet Provider metadata beforehand, building the Trust Chain about the Wallet Provider (Metadata Retrieval and Validation), as part of the Wallet Metadata Retrieval Flow (see Wallet Metadata Retrieval Flow and the Selection Page in User Experience Design). This mechanism is specific to the remote flow and does not apply to the proximity flow.

6.3.2. Federation Trust Anchor Distribution and Validation¶

6.3.2.1. Federation Trust Anchor Distribution¶

The configuration of the federation is published by the Federation Trust Anchor within its Entity Configuration, available at the well-known web path .well-known/openid-federation. All the Entities MUST obtain the federation configuration before entering the operational phase. All the Entities MUST keep the federation configuration up to date. The federation configuration contains the Federation Trust Anchor public keys for signature operations and the federation endpoints (see Entity Configuration).

The Federation Trust Anchor MUST distribute its Federation Public Keys through secure out-of-band mechanisms. When a Federation Trust Anchor validation is required, all the Entities MUST compare the Federation Trust Anchor public keys with those obtained from the Federation Trust Anchor Entity Configuration. All the Entities MUST discard any key that does not match.

Note

Within IT-Wallet the out-of-band channel is the contact channel established with the Entity during the registration process (see Entity Registration).

Entities MAY additionally pin the Federation Trust Anchor public keys, in their local configuration. A pinned configuration MAY be used only while it is valid. A pinned configuration MUST be updated when a key rotation occurs.

The Federation Trust Anchor Entity Configuration also provides the Signing Trust Anchors of the X.509 signing PKI, used to verify the Credentials anchored to this framework, and the National Wallet Trust Anchors used to verify Wallet Unit Attestations and Key Attestations. Their distribution and validation are defined in Signing Trust Anchor Distribution and Wallet Trust Anchor Distribution, respectively, as they concern the verification of an attestation and not the validation of the Federation Trust Anchor.

6.3.2.2. Federation Trust Anchor Validation¶

6.3.2.2.1. Federation Trust Anchor Validation: Input¶

The Federation Entity Identifier of the Federation Trust Anchor.
The Federation Trust Anchor public keys obtained out-of-band, or a pinned configuration.

6.3.2.2.2. Federation Trust Anchor Validation: Outcome¶

The validated set of Federation Trust Anchor Federation Public Keys.
The federation configuration, including the federation endpoints.

6.3.2.2.3. Federation Trust Anchor Validation: Process¶

The verification of the Entity Configuration is the Entity Statement validation defined in OID-FED Section 3.2, applied to the self-issued Entity Configuration of the Federation Trust Anchor and completed, within IT-Wallet, with the out-of-band comparison of the keys.

Fetch the Entity Configuration from the well-known endpoint of the Federation Trust Anchor, served with the media type application/entity-statement+jwt.
Verify that the Entity Configuration is a signed JWT with iss and sub equal to the Federation Trust Anchor identifier, and verify its signature with one of the keys contained in its jwks. The supported signature algorithms are defined in Cryptographic Algorithms.
Compare the keys in jwks with the keys obtained out-of-band or pinned, discarding the keys that do not match.
Check the temporal validity of the Entity Configuration through the iat and exp claims.
Extract the federation endpoints from the federation_entity metadata, and the trust_mark_issuers claim (see Entity Configuration).

If any step fails, the federation configuration MUST NOT be used.

6.3.2.3. Federation Trust Anchor Key Rotation and Historical Verification¶

When it is required to validate a Trust Chain over time, even if the Federation Trust Anchor has changed its cryptographic keys for digital signature, the Federation Historical Keys endpoint always makes the keys no longer used available for historical signature verifications. This property supports the non-repudiability of the long lived attestations.

When the Federation Trust Anchor rotates its keys, the new keys are distributed with the same out-of-band mechanism used for the initial distribution. Entities that pin the Federation Trust Anchor keys MUST refresh the pinned material accordingly.

6.3.3. Trust Chain Validation¶

Trust Chain Validation is a technical procedure used by the trust evaluation processes defined in this section for different purposes. Depending on whether an entity is evaluating a federation statement or an artifact carries the X.509 certificate chain used for its signature, two different Trust Chain Validation procedures apply.

6.3.3.1. Federation Trust Chain¶

The Trust Chain is a sequence of verified statements that validates an Entity compliance with the federation. It has an expiration date, beyond which it MUST be renewed to obtain fresh and updated metadata. The expiration date of the Trust Chain is determined by the earliest expiration timestamp among all the statements. No Entity can force the expiration date of the Trust Chain to be higher than the one configured by the Federation Trust Anchor.

This procedure verifies the Trust Chain. The derivation of the final metadata of the subject, obtained applying the metadata policies carried by the statements of the Trust Chain, is defined in Metadata Retrieval and Validation. According to OID-FED, the verification of the chain and the derivation of the final metadata, is referred to as the resolution of a Trust Chain.

The Trust Chain is built through the Federation Entity Discovery process defined in OID-FED:

The Trust Evaluator fetches the Entity Configuration of the subject.
Follows the authority_hints to collect the Subordinate Statements issued by the superior entities.
It continues until the Federation Trust Anchor is reached.

The Trust Chain MAY also be kept valid with the fast renewal method defined in OID-FED Section 3.1.3, that avoids a full discovery process by fetching the Subordinate Statements directly through their source_endpoint claim.

The Trust Chain MAY also be provided statically by the subject within a signed artifact, using the trust_chain JOSE header parameter defined in OID-FED Section 4.3. Within IT-Wallet the trust_chain header is carried in the Request Object of the presentation flow (see Request Object) and in the signed artifacts of the issuance flow (OPENID4VCI Appendix F.1 and Section 12.2.3). A statically provided Trust Chain only requires to be refreshed when an internet connection is available, while it MUST be refreshed when it results as expired.

The revocation of an Entity is made with the unavailability of the Subordinate Statement related to it. If the Federation Trust Anchor or its Intermediate does not publish a valid Subordinate Statement, or if it publishes an expired or invalid one, the subject of the Subordinate Statement MUST be intended as not valid or revoked. For the Trust Evaluator, this real-time check of the revocation status is possible only online, by fetching the Subordinate Statement at the moment of the verification.

The Trust Chains can also be verified offline, using one of the Federation Trust Anchor public keys. In this case the real-time revocation check is not available, and the freshness of the Trust Chain is relied upon.

The maximum validity of a Trust Chain can be enforced by the Federation Trust Anchor, which sets it through the expiration of its own statements, as described above. Independently of that validity, for the purpose of the revocation status of the Entities a Trust Chain built more than 24 hours before the moment of the verification SHOULD NOT be considered valid. When the revocation status of an Entity requires to be relied upon and a real-time online check is not available, a Trust Chain older than 24 hours SHOULD be renewed before the interaction can proceed. This 24 hours limit applies to the age of the Trust Chain, computed from its construction, and is independent of its expiration date.

6.3.3.1.1. Federation Trust Chain: Input¶

The Federation Entity Identifier of the subject, or a statically provided Trust Chain.
The validated Federation Trust Anchor Federation Public Keys (see Federation Trust Anchor Distribution).

6.3.3.1.2. Federation Trust Chain: Outcome¶

A validated Trust Chain, that is the ordered set of verified statements, with its expiration date.

6.3.3.1.3. Federation Trust Chain: Process¶

The steps below verify a Trust Chain according to OID-FED, with the pointer to the relevant part of the specification for each step:

Obtain the Entity Configuration of the subject, or take the first element of the statically provided Trust Chain.
Collect the Subordinate Statements following the authority_hints up to the Federation Trust Anchor, or take them from the static Trust Chain. The Subordinate Statements are obtained from the fetch endpoint (OID-FED Section 8.1).
Validate each statement as an Entity Statement according to OID-FED Section 3.2, that is verify its signature, the consistency of the iss and sub claims, and its temporal validity. Each Subordinate Statement is verified with the Federation Entity Keys of its issuer, attested by the superior statement.
- The statement issued by the Federation Trust Anchor is verified with the validated Federation Trust Anchor keys.
- The Entity Configuration of the subject is verified with the keys attested in the Subordinate Statement about it.
Enforce the constraints carried in the Subordinate Statements along the chain, as defined in OID-FED Section 6.2. In particular, verify that the metadata Entity Types published by the subject are within the allowed_entity_types, considering that the federation_entity Entity Type is always allowed, and that the number of Intermediates does not exceed the max_path_length set by the superiors.
Compute the Trust Chain expiration as the earliest exp value among the statements.

If any verification fails, the Trust Chain MUST be considered invalid. The subject MUST NOT be trusted on the basis of that Trust Chain.

6.3.3.2. X.509 Certificate Chain Validation¶

This variant applies when an artifact is provided along with the X.509 certificate chain used for the signature. For artifacts in JOSE format the chain is carried in the x5c header parameter, as defined in RFC 7515 and used in IT-Wallet in the Request Object of the presentation flow (see Request Object). For Credentials in mdoc format the chain is carried in the x5chain unprotected header (element 33) of the Mobile Security Object, as defined in RFC 9360 and in Mobile Security Object. The chain MUST start with the end-entity certificate corresponding to the private key used to sign the artifact or Attestation, followed by any intermediate certificates in issuer order. Each subsequent certificate MUST certify the preceding certificate. It MUST NOT contain the Signing Trust Anchor certificate, which is distributed as defined in Signing Trust Anchor Distribution.

The certificate chain validation is the standard X.509 path validation defined in RFC 5280#section-6, with the revocation status checking defined in RFC 5280 and RFC 6960. The certificate lifecycle and the revocation mechanisms, including the CRL, are defined in Revocation Mechanisms. This is the same certificate chain validation used in the EUDIW Trust Framework (see X509 Certificate Chain Validation Algorithm). The only difference is the origin of the trust anchor and the additional extraction of the Federation Entity Identifier. In this section, for the National Trust Framework, the algorithm details are not redefined.

Within the National Trust Framework the following applies.

The trust anchor of the path validation is the applicable Signing Trust Anchor, obtained as defined in Signing Trust Anchor Distribution.

The end-entity certificate carries the OpenID Federation Entity Identifier of the subject in the subjectAltName URI. This is the element that links the X.509 signature to the federation identity of the signer. Therefore, the validation extracts this identifier so that the calling process can verify that the certificate that signed the artifact belongs to the OpenID Federation entity expected for that artifact. The comparison against the expected identifier, for example the iss of the Credential, is performed by the calling process (see Signing Trust Anchor Validation Procedure). This variant only produces the identifier and it does not by itself establish which identifier is expected.

Note

The issuance of these X.509 Certificates and the operation of the signing PKI are defined in the onboarding procedure and are out of the scope of this section (see Onboarding Processes).

6.3.3.2.1. X.509 Certificate Chain Validation: Input¶

The certificate chain extracted from the artifact header, that is the Document Signer certificate and any intermediate certificate.
The applicable Signing Trust Anchor certificate, obtained as defined in Signing Trust Anchor Distribution.

6.3.3.2.2. X.509 Certificate Chain Validation: Outcome¶

The validated end-entity certificate.
The OpenID Federation Entity Identifier of the signer, extracted from the subjectAltName URI, to be matched against the expected issuer by the calling process.

6.3.3.2.3. X.509 Certificate Chain Validation: Process¶

Build the certificate chain from the end-entity certificate to the Signing Trust Anchor certificate.
Execute the path validation defined in RFC 5280#section-6, using the Signing Trust Anchor as the trust anchor input of the algorithm.
Verify the revocation status of the certificates in the path, according to RFC 5280 and RFC 6960.
Extract the OpenID Federation Entity Identifier from the subjectAltName URI of the end-entity certificate, and return it to the calling process for the match against the expected issuer.

If any step fails, the artifact signature MUST NOT be verified with the presented certificate chain.

6.3.4. Signing Trust Anchor Distribution and Validation¶

This process provides and validates the root of trust for the verification of the issuer data authentication of an attestation.

The Signing Trust Anchor is the root of trust of the X.509 PKI used to sign the Digital Credentials whose Rulebook anchors them to the National Trust Framework.

It is distinct from the Federation Trust Anchor of Federation Trust Anchor Distribution as the Federation Trust Anchor is the root of the federation statements, while a Signing Trust Anchor is the root of a certificate chain that validates the signature of an attestation. The Federation Trust Anchor and a Signing Trust Anchor MAY be operated by the same organization, but they are different trust relationships, with different lifecycles and different revocation channels.

There MAY be more than one Signing Trust Anchor. Each Credential Issuer that signs Credentials in this framework uses a Signing Trust Anchor as the root of its Document Signer certificates. Different Credential Issuers MAY rely on different Signing Trust Anchors.

6.3.4.1. Signing Trust Anchor Distribution¶

The Signing Trust Anchors are distributed through the Federation Trust Anchor Entity Configuration. Each Signing Trust Anchor certificate is provided in the x5c parameter of a dedicated JWK, distinct from the Federation Entity Keys used to sign the federation statements. This distribution mechanism is an IT-Wallet specific implementation and is not defined by OID-FED.

Entities MAY pin a Signing Trust Anchor in their local configuration. A pinned Signing Trust Anchor MAY be used only while it is valid. A pinned Signing Trust Anchor MUST be updated when the Signing Trust Anchor is rotated.

The result of this distribution is, for each Trust Evaluator, the set of validated Signing Trust Anchor certificates, each associated with the Federation Entity Identifier of the Credential Issuers that rely on it. This set is the trust anchor material consumed by the validation procedure below.

Note

The issuance of the Document Signer certificates and the operation of the signing PKI are defined in the onboarding procedure and are not in the scope of this section (see Onboarding Processes).

6.3.4.2. Signing Trust Anchor Validation Procedure¶

The procedure depends on the format of the attestation.

For attestations in JOSE format, such as Digital Credentials in SD-JWT VC format and the Wallet Instance Attestation, the issuer is identified by the iss claim and the signature verification key is referenced by the kid header parameter. The key MUST be resolved within the final metadata of the issuer, obtained through the Federation Trust Chain. The artifact MAY carry the trust_chain JOSE header to allow the validation without a new discovery process.

For Credentials in mdoc format the Mobile Security Object carries the Document Signer certificate in the x5chain header. The signature is verified with that certificate. The Signing Trust Anchor of the issuer is validated by extracting the OpenID Federation Entity Identifier from the subjectAltName URI and by validating the certificate chain against the applicable Signing Trust Anchor obtained as defined in Signing Trust Anchor Distribution.

6.3.4.2.1. Signing Trust Anchor Validation Procedure: Input¶

The signed attestation.
The validated Federation Trust Anchor configuration and the applicable Signing Trust Anchor.

6.3.4.2.2. Signing Trust Anchor Validation Procedure: Outcome¶

The validated trust anchor and the signing key or certificate for the attestation.
The confirmation that the signing key belongs to the attestation issuer.

6.3.4.2.3. Signing Trust Anchor Validation Procedure: Process¶

For JOSE artifacts, derive the issuer final metadata from the Federation Trust Chain (see Federation Trust Chain and Metadata Retrieval and Validation) and select the key referenced by the kid header.
For mdoc artifacts, validate the x5chain as defined in X.509 Certificate Chain Validation and verify that the OpenID Federation Entity Identifier in the subjectAltName URI corresponds to the expected issuer.
Verify the attestation signature with the selected key or certificate.

Note

When required, the Federation Historical Keys endpoint and the published CRLs MUST be used to ensure that the attestation was valid at the time of issuance or presentation (see Federation Trust Anchor Key Rotation and Historical Verification for more details).

The lifecycle of the signing certificates MUST be kept aligned with the federation configuration set of the issuer keys. When a signing key is rotated or is no longer valid, the corresponding JWK MUST be removed from the Entity Configuration or rotated. The related certificate MUST be revoked accordingly. Within IT-Wallet, when the federation configuration and the certificate status diverge, the most restrictive state MUST prevail. A key revoked in either of the two views MUST be considered revoked.

6.3.5. Wallet Trust Anchor Distribution and Validation¶

This process establishes and validates the National Wallet Trust Anchor used to validate Wallet Instance Attestations and Key Attestations issued by a Wallet Provider in the National Trust Framework.

The National Wallet Trust Anchor is the root of the X.509 PKI used by the Wallet Provider to sign Wallet Unit Attestations. It is distinct from the Federation Trust Anchor, which is the root of the federation statements, and from the Signing Trust Anchor used by a Credential Issuer for Digital Credentials.

6.3.5.1. Wallet Trust Anchor Validation¶

For a Wallet Instance Attestation or Key Attestation that carries an X.509 signing certificate chain, the Trust Evaluator MUST validate the chain against the applicable National Wallet Trust Anchor before accepting the attestation signature.

6.3.5.1.1. Wallet Trust Anchor Validation: Input¶

The signed Wallet Instance Attestation or Key Attestation and its signing certificate chain.
The validated Trust Chain of the Wallet Provider.
The applicable National Wallet Trust Anchor obtained as defined in Wallet Trust Anchor Distribution.

6.3.5.1.2. Wallet Trust Anchor Validation: Outcome¶

The validated Wallet Provider signing certificate and attestation.
Confirmation that the signing certificate belongs to the Wallet Provider identified by the validated Trust Chain.

6.3.5.1.3. Wallet Trust Anchor Validation: Process¶

Validate the Trust Chain of the Wallet Provider and derive its final metadata as defined in Federation Trust Chain and Metadata Retrieval and Validation.
Extract the signing certificate chain from the x5c JOSE header of the Wallet Instance Attestation or Key Attestation. The National Wallet Trust Anchor MUST NOT be included in this chain.
Validate the certificate chain against the applicable National Wallet Trust Anchor as defined in X.509 Certificate Chain Validation.
Verify the attestation signature with the validated end-entity certificate.
Verify that the Federation Entity Identifier extracted from the end-entity certificate corresponds to the Wallet Provider identified by the Trust Chain.
Check the temporal validity and revocation status of the attestation as required by the applicable attestation profile.

If any step fails, the Wallet Instance Attestation or Key Attestation MUST NOT be considered issued by a trusted Wallet Provider.

6.3.5.2. Wallet Trust Anchor Distribution¶

The National Wallet Trust Anchor MUST be distributed through the Federation Trust Anchor Entity Configuration. It MUST be represented by a dedicated JWK whose x5c parameter contains the National Wallet Trust Anchor certificate. The dedicated JWK MUST be distinct from the Federation Entity Keys used to sign federation statements.

The Trust Evaluator MUST validate the Federation Trust Anchor Entity Configuration and the Wallet Provider's Trust Chain before accepting the National Wallet Trust Anchor. The resulting configuration MUST associate the National Wallet Trust Anchor with the Wallet Provider's Federation Entity Identifier.

Entities MAY pin the National Wallet Trust Anchor in their local configuration. A pinned National Wallet Trust Anchor MAY be used only while it is valid. A pinned National Wallet Trust Anchor MUST be updated when the National Wallet Trust Anchor is rotated.

When a Wallet Provider operates in both Trust Frameworks, the National Wallet Trust Anchor is the same certificate as the Trust Anchor notified to the European Commission, as specified in Revocation Trust Anchors.

6.3.6. Authentication Trust Anchor Distribution¶

The Authentication Trust Anchors are distributed through the Federation Trust Anchor Entity Configuration with the same mechanism used for the Signing Trust Anchors. Each Authentication Trust Anchor certificate is provided in the x5c parameter of a dedicated JWK, distinct from the Federation Entity Keys.

An Authentication Trust Anchor is the root of the X.509 authentication PKI that issues the Relying Party authentication certificates used in the Proximity Flow. These certificates follow the same profile as the Wallet-Relying Party Access Certificate (see Wallet-Relying Party Access Certificate (WRPAC) Profile).

Note

The issuance of the Relying Party authentication certificates and the operation of the authentication PKI are defined in the onboarding procedure and are not in the scope of this section (see Onboarding Processes).

6.3.7. Authentication¶

The Authentication process has the aim of asserting the identity of the Trust Evaluated Party. Three procedures are defined:

Federation Entity Authentication applies to the entities that publish an Entity Configuration, in the Remote Flow.
Wallet Unit Authentication applies to the Wallet Unit, which is not a Federation Entity.
Relying Party Proximity Authentication applies to the Relying Party in the Proximity Flow.

6.3.7.1. Federation Entity Authentication¶

The identity of Trust Evaluated Party and its keys are established through the Trust Chain. The Trust Evaluated Party authenticates itself in a given interaction by signing the protocol artifact of that interaction with a private key whose public part is published in its final metadata, obtained by resolving the Trust Chain. The kid header parameter, as defined in RFC 7515, references a key contained in the final metadata of the Trust Evaluated Party. The full set of header parameters of each signed artifact is defined in the corresponding protocol section.

6.3.7.1.1. Federation Entity Authentication: Input¶

The signed protocol artifact.
The Federation Entity Identifier claimed by the Trust Evaluated Party.
A Trust Chain about the Trust Evaluated Party, provided statically or built through discovery.

6.3.7.1.2. Federation Entity Authentication: Outcome¶

The Trust Evaluator MUST output AUTHENTICATED or NON_AUTHENTICATED. In the second case the Trust Evaluated Party MUST NOT be considered authenticated. The interaction MUST NOT continue. The User notification and the prohibition of the cross scheme retry are defined in Failure Handling.

6.3.7.1.3. Federation Entity Authentication: Process¶

Validate the Trust Chain about the Trust Evaluated Party and derive its final metadata (see Federation Trust Chain and Metadata Retrieval and Validation).
Verify that the entity identifier carried by the artifact, for example the client_id or the iss claim, matches the subject of the Trust Chain.
Select within the final metadata the public key referenced by the kid header.
Verify the artifact signature with the selected key.

The successful verification provides both the authentication of the Trust Evaluated Party and the proof of possession of its private key.

6.3.7.2. Wallet Unit Authentication¶

The Wallet Instance Attestation conveys the Wallet Unit public key which is used to validate the signature over the Wallet Instance Attestation. The format and the issuance flow are defined in Wallet Instance Attestation Issuance.

The evaluation MUST follow the model defined in OpenID Federation for Wallet Architectures. The Wallet Unit authenticates with a Client authentication mechanism that provides the Wallet Instance Attestation issued by its Wallet Provider, together with the proof of possession of the attested key. In the issuance flow this is realized with the OAuth 2.0 Attestation-Based Client Authentication, that is the OAuth-Client-Attestation and OAuth-Client-Attestation-PoP parameters (OAUTH-ATTESTATION-CLIENT-AUTH), as described in OPENID4VCI. To establish trust in the Wallet Unit, the Trust Evaluator MUST:

Establish trust in the Wallet Provider that issued the Wallet Instance Attestation.
Validate the Wallet Instance Attestation as defined in Wallet Trust Anchor Validation using the National Wallet Trust Anchor.

6.3.7.2.1. Wallet Unit Authentication: Input¶

The Wallet Instance Attestation presented by the Wallet Unit.
The proof of possession of the key attested in the Wallet Instance Attestation.
A Trust Chain about the Wallet Provider.

6.3.7.2.2. Wallet Unit Authentication: Outcome¶

The Trust Evaluator MUST output AUTHENTICATED or NON_AUTHENTICATED for the Wallet Unit.

6.3.7.2.3. Wallet Unit Authentication: Process¶

Validate the Trust Chain about the Wallet Provider that issued the Wallet Instance Attestation and derive its final metadata (see Federation Trust Chain and Metadata Retrieval and Validation).
Validate the Wallet Instance Attestation as defined in Wallet Trust Anchor Validation using the National Wallet Trust Anchor.
Check the temporal validity and the revocation status of the Wallet Instance Attestation.
Verify the proof of possession of the attested key, according to the protocol in use.

6.3.7.3. Relying Party Proximity Authentication¶

In the Proximity Flow the Relying Party is authenticated through the mdoc reader authentication defined in [ISO18013-5]. The Relying Party signs each ReaderAuthentication with the private key of its National authentication certificate and provides the certificate chain in the unprotected x5chain header (label 33) of each readerAuth. The end-entity certificate is first and the path excludes the Authentication Trust Anchor. The certificate chain terminates in an Authentication Trust Anchor distributed as defined in Authentication Trust Anchor Distribution.

6.3.7.3.1. Relying Party Proximity Authentication: Input¶

Each readerAuth signed by the Relying Party, with the authentication certificate chain in the x5chain header.
The applicable Authentication Trust Anchor.

6.3.7.3.2. Relying Party Proximity Authentication: Outcome¶

The Trust Evaluator MUST output AUTHENTICATED or NON_AUTHENTICATED. In the second case the Relying Party MUST NOT be considered authenticated. The interaction MUST NOT continue.

6.3.7.3.3. Relying Party Proximity Authentication: Process¶

Extract the certificate chain from the x5chain header of every readerAuth and require the National authentication certificate as its end entity.
Validate the certificate chain against the applicable Authentication Trust Anchor as defined in X.509 Certificate Chain Validation.
Verify each readerAuth signature over its ReaderAuthentication data with the validated authentication certificate.

The successful verification provides both the authentication of the Relying Party and the proof of possession of the private key of its authentication certificate. This National authentication result selects the National Trust Framework path before authorization, as specified in Selection at Presentation. A failure of this result is handled as specified in Failure Handling.

6.3.8. Authorization¶

The authorization data of an entity are provided by the registration Trust Mark issued by the Registrar through the Federation Authority. The registration Trust Mark is functionally analogous to the Wallet-Relying Party Registration Certificate of the EUDIW Trust Framework, and it reuses the same field names for the authorization data. It attests the registration of the entity and carries its entitlements and, where applicable, the provides_attestations or the credentials it is authorized to issue or to request. Its structure is defined in Trust Mark registration-entity and the identifiers schema in Trust Mark Types and Schema.

The Authorization process is composed of the following procedures:

Trust Mark Validation, which establishes the validity of the registration Trust Mark. It applies to all the registered Entities.
Entitlement Check, which verifies that the role and, at issuance, the Credential types of the Trust Evaluated Party are authorized. It applies to all the Wallet-Relying Parties, that is Credential Issuers and Relying Parties.
Overasking Check, which verifies at presentation that a Relying Party requests only the Digital Credentials and the attributes it is authorized to request. It applies to Relying Parties.

The role authorization common to both phases is performed by the Entitlement Check. The phase specific checks are the Credential type check at issuance, inside the Entitlement Check, and the attribute level Overasking Check at presentation.

The Trust Evaluator MUST perform the Authorization process only after the Trust Evaluated Party has been successfully authenticated. In National direct proximity, the Wallet Unit MUST validate the Trust Mark and bind the National authentication-certificate identity, the Trust Mark subject and official identifiers, and an identifier in euWrpRegistrarInfo.identifier to the same direct Relying Party. The Wallet Unit MUST validate the entitlement, the exact case-sensitive overasking scope, and the Trust Mark transparency claims. National proximity MUST exclude EUDIW evidence and fallback. National proximity MUST NOT introduce National intermediated-proximity transport.

6.3.8.1. Trust Mark Validation¶

6.3.8.1.1. Trust Mark Validation: Input¶

The registration-entity Trust Mark, obtained in the Remote Flow from the trust_marks claim of the Entity Configuration or from the Federation Trust Mark endpoint (OID-FED Section 8.6), or provided by value in the requestInfo.euWrprc CBOR byte string of every ISO ItemsRequest in the Proximity Flow as the UTF-8 bytes of its compact signed JWT.
The validated Federation Trust Anchor configuration.

6.3.8.1.2. Trust Mark Validation: Outcome¶

The Trust Evaluator MUST output TRUST_MARK_VALID or TRUST_MARK_INVALID. A TRUST_MARK_INVALID outcome on the registration Trust Mark means that the entity is not authorized to operate. In this case the Trust Evaluator MUST treat the entity as not authorized. The Trust Evaluator MUST NOT proceed with the Entitlement Check.

6.3.8.1.3. Trust Mark Validation: Process¶

Verify that the issuer of the Trust Mark is authorized for that trust_mark_type, according to the trust_mark_issuers claim of the Federation Trust Anchor Entity Configuration. The registration Trust Mark, that is a Trust Mark whose trust_mark_type has the registration-entity purpose, is subject to two additional checks. The Trust Mark Validation verifies that the trust_mark_type matches the expected registration identifier for the role of the subject, and that the issuer is the Federation Trust Anchor, since the registration Trust Mark MUST be issued only by the Federation Trust Anchor (see Trust Mark Types and Schema).
Verify the Trust Mark signature with the Federation Entity Keys of its issuer, obtained through the Trust Chain when the issuer is not the Federation Trust Anchor.
Check the temporal validity of the Trust Mark through the iat and exp claims.
When online, check the Trust Mark status through the Federation Trust Mark Status endpoint (OID-FED Section 8.4).

6.3.8.2. Entitlement Check¶

The entitlements define what the entity is authorized to do, such as the Credential types it may issue or the attributes it may request. Within IT-Wallet these authorization data are carried in the registration Trust Mark, in the entitlements, provides_attestations and credentials claims defined in Trust Mark Types and Schema, and MUST NOT be derived from the metadata alone.

6.3.8.2.1. Entitlement Check: Input¶

The validated Trust Marks of the Trust Evaluated Party.
The role of the Trust Evaluated Party and the action expected in the current interaction. At issuance, the type of Credential Issuer and the Credential types it declares to issue. At presentation, the Digital Credentials and the attributes requested by the Relying Party.

6.3.8.2.2. Entitlement Check: Outcome¶

The Trust Evaluator MUST output ENTITLEMENT_VALID or WRONG_ENTITLEMENT.

6.3.8.2.3. Entitlement Check: Process¶

Extract the entitlements from the validated Trust Marks and verify that they match the role expected in the current interaction, for example that an entity acting as Credential Issuer holds an issuing entitlement of ETSI TS 119 475 Annex A.2.
During issuance, verify that the offered Credential type is present in the provides_attestations of the Trust Mark, comparing the format and the meta of the offered Credential against the authorized entries.
During presentation, the attribute level check against the credentials of the Trust Mark is performed by the Overasking Check below.

6.3.8.3. Overasking Check¶

6.3.8.3.1. Overasking Check: Input¶

The presentation request.
The credentials carried in the validated Trust Mark, that is the Credential queries the Relying Party is authorized to request.

6.3.8.3.2. Overasking Check: Outcome¶

The Wallet Unit MUST output VERIFICATION_PASSED or OVERASKING_DETECTED, identifying the unregistered attributes or Digital Credentials. On OVERASKING_DETECTED the Wallet Unit MUST NOT disclose the attributes that are not authorized. The Wallet Unit MUST inform the User of the detected overasking.

6.3.8.3.3. Overasking Check: Process¶

Extract the requested Digital Credentials and attributes from the request, from the DCQL query defined in OpenID4VP in the remote flow, or from the requested namespaces in the proximity flow.
For each requested Credential, select in the credentials of the Trust Mark the authorized entry with the same format and meta, for example the same vct_values or doctype_value.
Verify that every requested attribute is present in the claim paths of the selected authorized entry. If the request contains a Credential or an attribute with no corresponding authorized entry, the output is OVERASKING_DETECTED.
Matching MUST be exact and case sensitive.

6.3.8.4. User Transparency¶

Beyond the automated checks above, the registration Trust Mark provides claims that are not evaluated as a decision rule but are presented to the User for transparency, to support the decision to proceed with the interaction before any attribute is disclosed. Before the disclosure, the Wallet Unit MUST inform the User of the identity of the Relying Party and of the Digital Credentials and attributes requested, and it presents the additional transparency claims of the Trust Mark to support the informed decision. This is consistent with the User approval that concludes the presentation, as defined in Authorization Decision and Override Rules.

The transparency claims carried in the Trust Mark are the following:

organization_name, the legal name of the entity.
srv_description, the description of the service provided by the entity.
purpose, the data processing purposes, for a Relying Party that requests Credentials.
privacy_policy, the URL of the privacy policy, for a Relying Party that requests Credentials.
supervisory_authority, the Data Protection Authority to which the User can report anomalies.
public_body, whether the entity is a public sector body.
support_uri, the support contact used for a data deletion request, as specified in User's Attributes Deletion.

Their definitions are provided in Trust Mark Types and Schema.

When the Relying Party operates through a Relying Party Intermediary in the National Trust Framework, the Wallet Unit MUST also inform the User that the Relying Party operates through that Intermediary, displaying the identity of both. The Intermediary is the Federation Intermediate in the Trust Chain of the Relying Party, registered with the intermediate Trust Mark (see Trust Mark Types and Schema), and it is therefore identifiable from the validated Trust Chain without additional artifacts.

When the same presentation is evaluated in the EUDIW Trust Framework, the Wallet Unit MUST NOT display the trade names of the Intermediary or of the Intermediary Service ([EIDAS-ARF] RPI_07). It displays the intermediated Relying Party and its Service, as defined in EUDIW Authorization.

6.3.9. Metadata Retrieval and Validation¶

The metadata of a Federation Entity MUST be consumed only in their final form, that is the metadata resulting from the application of the metadata policies to the metadata published in the Entity Configuration, along the validated Trust Chain (see Federation Trust Chain). The metadata published in the Entity Configuration MUST NOT be used without this processing.

The metadata types and their parameters are defined in Entity Type Identifiers and Metadata and in the protocol specifications referenced there.

The Wallet Unit configuration is provided by the Wallet Provider within its metadata as defined in Wallet Solution Metadata.

6.3.9.1. Metadata Retrieval and Validation: Input¶

A validated Trust Chain about the subject (see Federation Trust Chain).

6.3.9.2. Metadata Retrieval and Validation: Outcome¶

The final metadata of the subject, for each metadata type relevant to the interaction.

6.3.9.3. Metadata Retrieval and Validation: Process¶

Apply the metadata_policy of the superior statements to the metadata published in the subject Entity Configuration, along the Trust Chain, according to OID-FED Section 6.1, obtaining the final metadata.
Select the metadata type corresponding to the role of the subject in the interaction.
Verify the presence of the parameters that are REQUIRED for that metadata type.
Use the endpoints, the keys and the algorithms only from the final metadata.

When the metadata are obtained through a statically provided Trust Chain, they MUST be refreshed when the Trust Chain expires, as defined in Federation Trust Chain.

Note

Within IT-Wallet the metadata_policy covers only the technical configuration parameters, such as endpoints, cryptographic keys and supported algorithms. Entitlements and authorization policies MUST NOT be expressed through metadata policies. Entitlements and authorization policies are carried by the Trust Marks, as defined in Authorization.

6.4. Authorization Decision and Override Rules¶

The Authorization Decision can either be AUTHORIZED or NOT_AUTHORIZED. The conditions that determine this outcome depend on the specific Authorization Validation procedure followed.

In case the Wallet Unit follows the EUDIW Authorization evaluation path, then the outcome is:
- during Credential Presentation, AUTHORIZED if the process terminates with CERTIFICATE_VALID AND EDP_SATISFIED AND VERIFICATION_PASSED.
- during Credential Issuance, AUTHORIZED if the process terminates with CERTIFICATE_VALID AND VERIFICATION_PASSED.
- NOT_AUTHORIZED otherwise.
In case the Wallet Unit follows the National Authorization evaluation path, then the outcome is:
- AUTHORIZED if the process terminates with TRUST_MARK_VALID AND ENTITLEMENT_VALID AND VERIFICATION_PASSED, or
- NOT_AUTHORIZED otherwise.

6.4.1. Override Principles¶

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

During Credential Issuance phase, all negative verification outcomes MUST be non-overridable. The Wallet Unit MUST NOT let the User interact with providers whose registration cannot be confirmed.
During the Presentation phase, all negative verification outcomes MUST be non-overridable, except for the following cases:
- Overasking [EUDIW]. When the process terminates with CERTIFICATE_VALID AND OVERASKING_DETECTED, i.e., the Authorization Artifact Validation has had a positive outcome, but the Scope Comparison finds the Relying Party requesting more than its registered scope.
- Negative Embedded Disclosure Policy evaluation [EUDIW]. When the process terminates with CERTIFICATE_VALID AND EDP_NOT_SATISFIED, i.e., the Authorization Artifact Validation has had a positive outcome but the Embedded Disclosure Policy would not allow the presentation to the Relying Party. If an EDP URI cannot be resolved to the exact included or preloaded policy, the evaluation failure is not EDP_NOT_SATISFIED. That failure MUST NOT be overridable.
- Missing or invalid WRPRC [EUDIW]. When the process terminates with CERTIFICATE_INVALID during Credential Presentation, i.e., the Wallet-Relying Party Registration Certificate is absent, malformed, inauthentic or expired. The Wallet Unit MUST warn the User. The Wallet Unit MUST NOT query the Register, as specified in EUDIW Authorization. Whether the User may still approve follows the Wallet Provider policy.
- Overasking [National]. When the process terminates with TRUST_MARK_VALID AND OVERASKING_DETECTED, i.e., the Trust Mark Validation has had a positive outcome, but the Overasking Check finds the Relying Party requesting more than its registered scope.

All other presentation failures, including binding failures or intermediary binding failures, MUST NOT be overridable as they indicate an integrity problem rather than a user-facing choice.

In case of non-overridable failures, the Wallet Unit MUST clearly inform the User about the negative outcome. User-relevant information about overridable outcomes MUST be presented as advisories. The User approval MUST be a separate step from the final Authorization Decision.