7. Registry Infrastructure

The IT-Wallet ecosystem operates through a registry infrastructure that provides standardized data definitions and Credential discovery capabilities. The registry system consists of multiple interconnected components that support the complete lifecycle of Digital Credential operations from entity onboarding to Digital Credential presentation. The registry architecture addresses semantic standardization and Credential discovery requirements through specialized registry components that ensure interoperability and compliance across the ecosystem.

At EU level the European Commission maintains two EUDIW catalogues that are the cross-border counterparts of the national semantic registries to which the national registries align, defined in ARF TS11 (EUDI-TS 11) (Interfaces and formats for the Catalogue of Attributes and the Catalogue of Schemes):

• Catalogue of Attributes is the EU-level catalogue of standardized attribute definitions and namespaces used across Attestations.

• Catalogue of Schemes is the EU-level catalogue of Attestation schemes (SchemaMeta): the machine-readable metadata that binds an Attestation type to its Rulebook and schema.

The registries and the catalogues used within the IT-Wallet ecosystem have different purposes and scopes. The registries whose content is evidence of a trust decision, such as the Register of WRPs operated by a national Registrar under CIR2025/848 and the Federation API Endpoints of the National Trust Framework, are specified in Infrastructure of Trust. The registries for the semantic definition and the discovery of data are detailed in this Section.

In particular, this section provides first an overview of the IT-Wallet registry infrastructure (Registries and Catalogues of the Ecosystem) and its discovery mechanism (Registry Discovery Endpoint). Then, it details its components: Taxonomy, Claims Registry, Authentic Source Registry, Schema Registry and Digital Credentials Catalog. Finally, it describes their relationships (Registry Integration and Cross-References) and usage journeys (Registry Infrastructure Usage Journeys).

7.1. Registries and Catalogues of the Ecosystem

The IT-Wallet ecosystem uses several registries and catalogues, at national and at EU level, and they serve two different purposes.

• Trust purpose: the content of the registry is consumed by a Trust Evaluator to accept or to reject an entity or an artifact. These registries are Trust Artifacts, they are defined in Infrastructure of Trust and the way they are consumed is defined in Trust Evaluation Process.

• Semantic and discovery purpose: the content of the registry defines the attributes, the schemas and the Credential types, or it makes them discoverable. These registries are defined in this Section.

Note

The distinction between trust and semantic/discovery registries is on the purpose and not on the content. For example, a registry of the semantic and discovery purpose may carry a parameter that points to a trust framework, as the trustedAuthorities of the Digital Credentials Catalog does, but such a parameter identifies the applicable trust framework and it is not itself the evidence of a trust decision.

Table 7.1 Registries and Catalogues of the Ecosystem

Registry or Catalogue	Purpose	Maintained by	Specified in
Taxonomy, Claims Registry, Schema Registry, Authentic Source Registry, Digital Credentials Catalog	Semantic and discovery	Federation Trust Anchor, under the Supervisory Body	This Section
Register of WRPs	Trust	Registrar	Register of WRPs
Federation API Endpoints, Entity Statements and Trust Marks	Trust	Federation Trust Anchor and Federation Intermediates	National Trust Artifacts
Catalogue of Attributes and Catalogue of Schemes	Semantic and discovery	European Commission	[EUDI-TS 11]. The alignment of the national registries is described in Registry Integration and Cross-References
Lists of Trusted Entities, Trusted Lists and List of Trusted Lists	Trust	European Commission and Member States	Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities

Note

The mechanisms that publish the status of a certificate or of an Attestation, such as the Certificate Revocation Lists, the OCSP responders and the Token Status Lists, are not registries and they are not listed in the table above. They are described in Revocation Mechanisms.

Five national semantic and discovery registries provide the standardized definitions and discovery data:

1. Taxonomy: Hierarchical classification system organizing Credentials by domain and purpose.

2. Claims Registry: Standardized semantic definitions for individual Credential attributes and data types.

3. Authentic Source Registry: Registered Authentic Source (AS) with their declared capabilities, available claims and verification endpoints.

4. Schema Registry: Authoritative list of Credential Schemas.

5. Digital Credentials Catalog: Available Credential types with their metadata and issuance information.

The national registries are maintained by the Federation Trust Anchor under the Supervisory Body to ensure consistency, security, and regulatory compliance. They are populated by the onboarding processes described in Onboarding Processes, and they are read both during the onboarding and during the operational phases.

The Entities that provide the information are the following:

• the Attestation Scheme Provider, for the definition of a Credential type and its scheme.

• the Authentic Sources, for their declared data capabilities.

• the Wallet-Relying Parties and the Wallet Providers, for their registration data.

These roles are described in System Actors and Roles.

None of these Entities writes in a registry directly. They provide the information through the onboarding processes, which verify it and write it. Each registry is then signed and published by the Federation Trust Anchor for the national registries and for the federation statements, by the Registrar for the Register of WRPs, and by the European Commission for the EU catalogues and lists.

Note

Not all the content of a registry is provided by an Entity. Some of it is set by the Onboarding System itself, such as the state of a Credential type in the Digital Credentials Catalog, which derives from the conditions of the versioned entry. The internal components of the Onboarding System and the process each of them realizes are described in System Components and Services.

Note

An Entity that provides an information is not necessarily the Entity that decides it, because the decisions on a Credential type are taken in its Attestation Rulebook, which is an input of the Onboarding System.

Figure Registries and Catalogues of the Ecosystem shows the whole set of the registries and catalogues, grouped by purpose and by level, with the Entities that provide their content and the authorities that publish them.

Fig. 7.1 Registries and Catalogues of the Ecosystem

Figure Discovery on the Registry Infrastructure shows, for the registries defined in this Section, the onboarding or operational phase in which each of them is read and by whom. More details are provided in each section. The way the registries with a trust purpose are read is described in Trust Evaluation Process.

Fig. 7.2 Discovery on the Registry Infrastructure

7.2. Registry Discovery Endpoint

The Federation Trust Anchor MUST provide a discovery mechanism for registry components through standardized well-known endpoints providing metadata and REST API discovery information.

Pagination and filtering of the Digital Credentials Catalog are specified in Digital Credentials Catalog Retrieval.

The Federation Trust Anchor MUST publish registry discovery metadata at the .well-known/it-wallet-registry endpoint with content negotiation support as specified in Content Negotiation and Signed Representation.

• Default Content-Type: application/jwt (signed JWT ensuring authenticity and integrity)

• Alternative Content-Type: application/json (plain JSON for development/debugging purposes)

Below a non-normative example is given.

GET /.well-known/it-wallet-registry HTTP/1.1
Host: trust-anchor.eid-wallet.example.it
Accept: application/jwt

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

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

GET /.well-known/it-wallet-registry HTTP/1.1
Host: trust-anchor.eid-wallet.example.it
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

7.2.1. Registry Discovery Endpoint Parameters

The JWT payload of the Registry Discovery response MUST contain the following parameters:

Table 7.2 Registry Discovery Endpoint JWT Payload Parameters

Field Name	Description
id	REQUIRED. Unique identifier of the Registry Discovery document (e.g., urn:it-wallet-registry:it-wallet).
version	REQUIRED. The version of the Registry Discovery document (e.g., 1.0.0).
last_modified	REQUIRED. The timestamp indicating when the list was last updated (e.g., 2025-03-15T12:00:00Z).
endpoints	REQUIRED. JSON object containing the URIs of all registry components. The following endpoint keys MUST be present: claims_registry: URI of the Claims Registry API. authentic_sources: URI of the Authentic Source Registry API. credential_catalog: URI of the Digital Credentials Catalog collection endpoint. See Digital Credentials Catalog Retrieval. taxonomy: URI of the Taxonomy resource. schema_registry: URI of the Catalogue of Attestations API root. See Catalogue of Attestations.
content_negotiation	REQUIRED. Array of content types supported by the discovery endpoint (e.g., ["application/json", "application/jwt"]).

JWT payload structure (when decoded):

{
  "id": "urn:it-wallet-registry:it-wallet",
  "version": "1.0.0",
  "last_modified": "2024-03-15T10:30:00Z",
  "endpoints": {
    "claims_registry": "https://trust-anchor.eid-wallet.example.it/api/v1/claims",
    "authentic_sources": "https://trust-anchor.eid-wallet.example.it/api/v1/authentic-sources",
    "credential_catalog": "https://trust-anchor.eid-wallet.example.it/api/v1/.well-known/credential-catalog",
    "taxonomy": "https://trust-anchor.eid-wallet.example.it/api/v1/taxonomy",
    "schema_registry": "https://trust-anchor.eid-wallet.example.it/api/v1/schemas"
  },
  "content_negotiation": ["application/json", "application/jwt"]
}

7.2.2. Content Negotiation and Signed Representation

Every endpoint of the Registry Infrastructure MUST support content negotiation and serve its content in two representations:

• Default Content-Type: application/jwt (signed JWT that provides authenticity and integrity)

• Alternative Content-Type: application/json (plain JSON for development and debugging)

Both representations are served at the same endpoint URL, not as separate resources or paths. The client selects the representation with the Accept request header, and the Federation Trust Anchor states the returned representation in the Content-Type response header. If the request does not ask for a supported type (Accept absent, */*, or only unsupported types), the endpoint MUST return the application/jwt representation.

This requirement applies to all the endpoints of the Registry Infrastructure listed in the following table:

Table 7.3 Registry endpoints supporting content negotiation

Registry component	How the endpoint is located
Registry Discovery	Fixed well-known path .well-known/it-wallet-registry.
Claims Registry	Absolute URL published under the claims_registry key of the discovery document.
Authentic Source Registry	Absolute URL published under the authentic_sources key of the discovery document.
Schema Registry	Absolute URL published under the schema_registry key of the discovery document. It is the Catalogue of Attestations API root.
Taxonomy	Absolute URL published under the taxonomy key of the discovery document.
Digital Credentials Catalog	Absolute URL published under the credential_catalog key of the discovery document.

The Registry Discovery Endpoint is the only one at a fixed well-known path. A client reads it first to obtain the URL of every other component from its signed endpoints object (see Registry Discovery Endpoint). A client MUST NOT assume a fixed path for the other components. Content negotiation applies to the discovery endpoint and to every component URL it publishes.

All these endpoints handle content negotiation in the same way: the same request, the same two Content-Type values, and the same signed representation.

The signed representation is a JWT in compact serialization, served as application/jwt. Its header MUST contain the parameters in the following table.

Table 7.4 JWT header parameters of the signed representation

Header parameter	Description	Reference
typ	REQUIRED. It MUST be set to JWT.	[RFC 7515 Section 4.1.9].
alg	REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST be one of the supported algorithms in Section Cryptographic Algorithms and MUST NOT be set to none or with a symmetric algorithm (MAC) identifier.	[RFC 7515 Section 4.1.1].
kid	REQUIRED. Unique identifier of the public key.	[RFC 7515 Section 4.1.4].
x5c	OPTIONAL. Contains the X.509 public key Certificate or Certificate chain [RFC 5280] corresponding to the key used to digitally sign the JWT. When the header parameter kid value is present, it MUST refer to the same leaf's cryptographic public key used with the X.509 Certificate.	[RFC 7515 Section 4.1.6.].
cty	REQUIRED. It MUST be set to application/json.	[RFC 7515 Section 4.1.6.].

The plain representation is the same content, served as a plain JSON object instead of a signed JWT.

The following non-normative example requests both representations from the Digital Credentials Catalog endpoint. The URL is the one resolved from the discovery document, shortened here for readability.

GET /.well-known/credential-catalog HTTP/1.1
Host: trust-anchor.eid-wallet.example.it
Accept: application/jwt

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

eyJhbGciOiJSUzI1NiIsImtpZCI6ImV4YW1w...

GET /.well-known/credential-catalog HTTP/1.1
Host: trust-anchor.eid-wallet.example.it
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

The example requests the first page of the collection. Query parameters, further pages and the entry resource are specified in Digital Credentials Catalog Retrieval.

7.3. Taxonomy

The Taxonomy is the authoritative vocabulary that organizes Credentials in the IT-Wallet ecosystem, and it is the semantic foundation of their interoperability. It is independent of the Credential format.

In a single resource, it defines the hierarchy of Domains, Classes and Purposes that Credential Types reference, supporting authorization policy evaluation and ecosystem-wide standardization.

The Taxonomy endpoint URL is published under the taxonomy key of the Registry Discovery document. The endpoint supports the content negotiation and signed representation common to all Registry Infrastructure endpoints (see Content Negotiation and Signed Representation).

7.3.1. Taxonomy Objectives

1. Semantic Foundation: Establish standardized vocabulary for domains and purposes across the ecosystem

2. Policy Framework: Enable structured authorization decisions based on hierarchical classification

3. Interoperability: Ensure consistent interpretation of Credential classifications

4. Extensibility: Support evolution of the ecosystem with new Domains, Classes, Credential Types and Purposes

5. Cross-Border Compliance: Align with EU regulatory requirements and international standards

7.3.2. Taxonomy Usage

• Authentic Source Registry: Authentic Sources declare capabilities using taxonomy classifications

• Digital Credentials Catalog: Credential Types specify Domains, Classes and Purposes

• Authorization Policies: Policy evaluation leverages taxonomy structure for access control decisions

7.3.3. Digital Credentials Hierarchy

Digital Credentials recognized within the IT-Wallet ecosystem are classified and standardized according to the following multi-level hierarchical model designed to improve semantic clarity, Credential discovery, and compatibility with both credential-specific and claim-based verification workflows.

The hierarchy is defined as follows:

7.3.3.1. Domain

A Domain represents a high-level thematic area grouping Credential families that relate to the same broad context (e.g., Identity, Health, Education, Mobility). Domains provide a top-level organizational layer.

7.3.3.2. Credential Class

A Credential Class represents a family of Credentials sharing similar nature, function, or structure (e.g., Identification Documents, Civil Status Certificates).

Each Class SHOULD define:

• a stable Class identifier (URI),

• the expected semantics of the Credential Family.

Classes enable Relying Parties and Wallet Solutions to request or match Credentials based on their type category.

7.3.3.3. Credential Type

A Credential Type represents a specific Credential within a Class (e.g. Digital Travel Credential, Birth Certificate, Mobile Driving License). Each Credential Type MUST include:

• a unique identifier,

• the Credential Issuer identifier,

• the set of Attributes that may be included in presentations.

Credential Types enable precise targeting for compliance-driven or regulation-mandated verification flows.

7.3.3.4. Purpose (Verification Intent)

A Purpose (Verification Intent) describes why a Credential may be requested by a Relying Party (e.g., Identity Verification, Age Verification, Eligibility for specific services). Purposes MUST describe verification outcomes. Each Credential Type MUST declare its Domain, Class, and supported Purposes.

The following tables provide non-exhaustive examples illustrating the relationships between Domains, Credential Classes, and Credential Types, followed by their mapping to verification Purposes. Additional Domains, Classes, specific Credentials, and verification Purposes MAY be added over time as the IT-Wallet ecosystem evolves.

Table 7.5 Digital Credential Taxonomy: Hierarchy and Classification

Domain	Description	Credential Class	Credential Type
IDENTITY	Credentials that establish or confirm a person's legal identity and personal, civil or legal status.	Identification Documents Civil Registry and Personal Status Certificates Economic and Legal Status	Digital Travel Credential Mobile Driving License (Italy only) Tax Code / Health Insurance Card Age Certification Birth Certificate Residence Certificate Family Status Certificate Marriage Certificate Citizenship Certificate ISEE (Equivalent Economic Situation Indicator) Residence Permit Certificate of Pending Charges Criminal Record Certificate
HOME AND FAMILY	Credentials that attest household composition, residence, and housing-related legal or fiscal relationships.	Property and Cadastral Documents Family Documents Local Tax Documents	Deed of Sale Cadastral Survey Cadastral Floor Plan Cadastral Certificate Children's Tax Code / Health Card Birth Certificate Family Status Certificate IMU (Property Tax) TARI (Waste Tax)
EDUCATION	Credentials that attest educational achievements, academic qualifications, and professional training.	Educational Qualifications Professional Certifications	Lower Secondary School Diploma Upper Secondary School Diploma Bachelor's Degree Master's Degree University Master PhD Professional Licenses (e.g. architect, lawyer) Vocational Training Certificates Language Certifications (e.g. IELTS) Academic Qualifications (e.g. Europass)
HEALTH	Credentials related to healthcare coverage, medical status, and health-related certifications.	Certifications and Eligibility Medical Records	Health Insurance Card (TEAM) European Health Card (CED) Disability Certificate Vaccination Certificate Sports Fitness Certificate Work Fitness Certificate Medical Prescriptions Digital Medical Report
FINANCIAL	Credentials related to payment instruments, financial authorizations, and proof of payments.	Payment Instruments Payment Credentials and Authorisations Public Payments and Fees Recurring Payments and Subscriptions	Digital Payment Card (debit / credit / prepaid) Virtual Card Bank Account (IBAN) Strong Customer Authentication (SCA) Credential Payment Receipt Digital Stamp Duty (Bollo digitale) Tax and Fee Payment Certificate Subscription Mandate Recurring Payment Credential
CULTURE AND LEISURE	Credentials that attest membership, affiliation, or participation in cultural or recreational programs.	Cultural Cards and Benefits Membership and Loyalty Programs	Culture Card Annual Museum Passes Cinema Card Museum Card Association Membership Cards Library Card City Pass
EMPLOYMENT	Credentials that attest employment relationships, professional status, and contribution records.	Employment Documents Employment Status Employment Affiliation	Digital Employment Contract Curriculum Vitae (CV) Residence Permit Employment Status Certificate INPS Contribution Record Physical Access Badge
MOBILITY AND TRAVEL	Credentials that attest mobility rights, vehicle-related status, and travel-related entitlements.	Licenses and Authorizations Vehicle Documents Transport Subscriptions Travel Documents Travel Insurance Bookings Discounts and Benefits	Mobile Driving License Boating License Vehicle Registration Certificate Digital RCA Insurance Vehicle Inspection Certificate Green Card / International Insurance Public Transport Pass Road Charging Subscription Digital Travel Credential Travel Tickets (air, train, etc.) Travel Insurance Policy Hotel Reservation Discount Cards Tourist Benefits
BONUSES	Credentials that attest entitlement to economic benefits, incentives, or vouchers.	Economic Benefits and Allowances Incentives and Vouchers Health and Wellbeing Bonuses	Family Allowance Credential Unemployment Benefit Credential Digital Voucher Purchase Incentive Credential Cashback Eligibility Credential Healthcare Bonus Credential Mental Health Support Voucher Sports and Physical Activity Bonus

Table 7.6 Mapping between Credential Classes and Purposes

Credential Class	Supported Purposes
Identification Documents	Identity verification Age verification Person identification
Civil Registry and Personal Status Certificates	Civil status verification Right of residence Household composition verification
Economic and Legal Status	Eligibility for services or benefits Legal status verification Criminal record check
Property and Cadastral Documents	Residence and household verification Property ownership verification Real estate compliance
Family Documents	Household composition verification Eligibility for family-based social services
Local Tax Documents	Compliance with local tax obligations Verification of property tax status
Educational Qualifications	Qualification and degree verification Eligibility for education pathways
Professional Certifications	Professional license verification Skills assessment for work
Certifications and Eligibility	Verification of vaccination status Verification of fitness status Access to health-restricted areas
Medical Records	Access to healthcare services Sharing of medical records Medical history validation
Payment Instruments	Payment authorization Payment execution Proof of payment
Payment Credentials and Authorisations	Management of financial authorizations Strong Customer Authentication (SCA)
Public Payments and Fees	Proof of tax payment Proof of fee payment Digital stamp duty validation
Recurring Payments and Subscriptions	Management of recurring payments Subscription mandate verification
Cultural Cards and Benefits	Access to cultural services Access to leisure services Application of member discounts
Membership and Loyalty Programs	Verification of affiliation Verification of participation Use of loyalty benefits
Employment Documents	Employment status verification Professional profile validation
Employment Status	Verification of contribution records Eligibility for employment-related benefits
Licenses and Authorizations	Driving rights verification Navigation rights verification Law enforcement controls
Vehicle Documents	Vehicle registration verification Vehicle inspection verification Insurance status check
Transport Subscriptions	Access to transport services Public transport pass verification
Travel Documents	Right to travel or circulate Cross-border mobility identity check
Travel Insurance and Bookings	Verification of travel insurance coverage Accommodation reservation check Transport reservation check
Discounts and Benefits	Application of member discounts Access to tourist benefits
Economic Benefits and Allowances	Eligibility verification for family benefits Eligibility verification for unemployment benefits Allocation of economic support
Incentives and Vouchers	Use of digital vouchers Use of purchase incentives Cashback eligibility verification
Health and Wellbeing Bonuses	Access to healthcare bonuses Use of mental health vouchers Use of sports vouchers
Employment Affiliation	Access permit verification

Each Credential MUST specify domains, classes and purposes to enable both Credential-Specific Scenarios and Credential-Agnostic Scenarios according to Relying Party's requirements and presentation request patterns, as defined in the mapping tables above.

1. Credential-Specific Scenarios (Primary for Government/Regulated Sectors): RPs request specific Credential types for compliance and audit requirements, including for example:

• Government Services: "credential_type":"pid" for PID-specific identity verification or "credential_type":"eid" for IT-Wallet ID-specific identity verification.

• Police Controls: "credential_type":"mDL" for driving license verification.

• Banking KYC: Specific Credential types mandated by financial regulations.

• Healthcare Services: "credential_type":"european_disability_card" for EU-compliant disability benefit access.

2. Credential-Agnostic Scenarios (Typical for Private Business): RPs request specific claims regardless of Credential source for operational efficiency, such as:

• E-commerce Delivery: Any Credential, among those to which he is authorized to access, containing given_name, family_name, address for shipping.

• Subscriptions: Any Credential, among those to which he is authorized to access, with given_name, email for personalization.

• Service Personalization: Business applications requiring basic personal data without strong source requirements.

This approach allows:

• Policy-based authorization by using Domain / Class / Credential Type / Purpose mappings.

• Flexible RP registration supporting both government compliance needs and business operational requirements.

7.3.4. Taxonomy Structure

The taxonomy maintains a four level hierarchical structure, that is the Domains, the Classes, the Credential Types and the Purposes defined in Digital Credentials Hierarchy above.

Note

Credential Type is a concept defined at the Digital Credentials Catalog level, not within the Taxonomy. The Taxonomy provides the classification vocabulary (Domains, Classes, Purposes) that Credential Types in the Catalog reference.

7.3.4.1. Localization Support

The taxonomy supports multilingual environments through the _l10n_id suffix pattern, enabling efficient localization management for user interfaces and cross-border implementations.

7.3.4.2. Taxonomy JSON Structure

Table 7.7 First-level Fields of the Taxonomy

Field Name	Description
id	REQUIRED. Unique identifier of the Taxonomy (e.g., urn:taxonomy:it-wallet).
version	REQUIRED. The version of the Taxonomy (e.g., 1.0.0).
last_modified	REQUIRED. The timestamp indicating when the list was last updated (e.g., 2025-03-15T12:00:00Z).
name_l10n_id	REQUIRED. Localization key referencing the human-readable name of the Taxonomy (e.g., taxonomy.name).
description_l10n_id	REQUIRED. Localization key referencing the human-readable description of the Taxonomy (e.g., taxonomy.description).
localization	REQUIRED. Localization configuration object containing: default_locale: Default locale code (e.g., it). available_locales: Array of supported locale codes (e.g., ["en", "it"]). base_uri: Base URI for localization bundle retrieval (e.g., https://trust-registry.eid-wallet.example.it/.well-known/l10n/taxonomy/). version: Version of the localization bundle format.
domains	REQUIRED. Array of Domain objects, each containing: id: Unique Domain identifier in SCREAMING_SNAKE_CASE (e.g., IDENTITY). name_l10n_id: Localization key for the domain name (e.g., domain.identity.name). description_l10n_id: Localization key for the domain description (e.g., domain.identity.description). classes: Array of Class objects. Each class contains id, name_l10n_id, and supported_purposes (array of purpose ID strings).
purposes	REQUIRED. Flat array of all Purpose objects defined across the taxonomy, each containing: id: Unique Purpose identifier in SCREAMING_SNAKE_CASE (e.g., IDENTITY_VERIFICATION, ACCESS_PERMIT). name_l10n_id: Localization key for the purpose name (e.g., purpose.identity_verification.name).

A non-normative example of Taxonomy structure is given below:

{
    "id": "urn:taxonomy:it-wallet",
    
    "version": "1.0.0",
    "last_modified": "2026-03-11T00:00:00Z",
    "name_l10n_id": "taxonomy.name",
    "description_l10n_id": "taxonomy.description",
    "localization": {
        "available_locales": [
            "en",
            "it"
        ],
        "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/taxonomy/",
        "default_locale": "it",
        "version": "1.0.0"
    },
    "domains": [
        {
            "classes": [
                {
                    "id": "IDENTIFICATION_DOCUMENTS",
                    "name_l10n_id": "class.identification_documents.name",
                    "supported_purposes": [
                        "IDENTITY_VERIFICATION",
                        "AGE_VERIFICATION",
                        "PERSON_IDENTIFICATION"
                    ]
                },
                {
                    "id": "CIVIL_REGISTRY_STATUS",
                    "name_l10n_id": "class.civil_registry_status.name",
                    "supported_purposes": [
                        "CIVIL_STATUS_VERIFICATION",
                        "RIGHT_OF_RESIDENCE",
                        "HOUSEHOLD_COMPOSITION_VERIFICATION"
                    ]
                },
                {
                    "id": "ECONOMIC_LEGAL_STATUS",
                    "name_l10n_id": "class.economic_legal_status.name",
                    "supported_purposes": [
                        "ELIGIBILITY_VERIFICATION",
                        "LEGAL_STATUS_VERIFICATION",
                        "CRIMINAL_RECORD_CHECK"
                    ]
                }
            ],
            "description_l10n_id": "domain.identity.description",
            "id": "IDENTITY",
            "name_l10n_id": "domain.identity.name"
        },
        {
            "classes": [
                {
                    "id": "PROPERTY_CADASTRAL_DOCS",
                    "name_l10n_id": "class.property_cadastral_docs.name",
                    "supported_purposes": [
                        "RESIDENCE_HOUSEHOLD_VERIFICATION",
                        "PROPERTY_OWNERSHIP_VERIFICATION",
                        "REAL_ESTATE_COMPLIANCE"
                    ]
                },
                {
                    "id": "FAMILY_DOCUMENTS",
                    "name_l10n_id": "class.family_documents.name",
                    "supported_purposes": [
                        "HOUSEHOLD_COMPOSITION_VERIFICATION",
                        "FAMILY_SOCIAL_SERVICES_ELIGIBILITY"
                    ]
                },
                {
                    "id": "LOCAL_TAX_DOCUMENTS",
                    "name_l10n_id": "class.local_tax_documents.name",
                    "supported_purposes": [
                        "LOCAL_TAX_COMPLIANCE",
                        "PROPERTY_TAX_VERIFICATION"
                    ]
                }
            ],
            "description_l10n_id": "domain.home_family.description",
            "id": "HOME_FAMILY",
            "name_l10n_id": "domain.home_family.name"
        },
        {
            "classes": [
                {
                    "id": "EDUCATIONAL_QUALIFICATIONS",
                    "name_l10n_id": "class.educational_qualifications.name",
                    "supported_purposes": [
                        "QUALIFICATION_DEGREE_VERIFICATION",
                        "EDUCATION_PATHWAY_ELIGIBILITY"
                    ]
                },
                {
                    "id": "PROFESSIONAL_CERTIFICATIONS",
                    "name_l10n_id": "class.professional_certifications.name",
                    "supported_purposes": [
                        "PROFESSIONAL_LICENSE_VERIFICATION",
                        "SKILLS_ASSESSMENT"
                    ]
                }
            ],
            "description_l10n_id": "domain.education.description",
            "id": "EDUCATION",
            "name_l10n_id": "domain.education.name"
        },
        {
            "classes": [
                {
                    "id": "CERTIFICATIONS_ELIGIBILITY",
                    "name_l10n_id": "class.certifications_eligibility.name",
                    "supported_purposes": [
                        "VACCINATION_STATUS_VERIFICATION",
                        "FITNESS_STATUS_VERIFICATION",
                        "HEALTH_RESTRICTED_ACCESS"
                    ]
                },
                {
                    "id": "MEDICAL_RECORDS",
                    "name_l10n_id": "class.medical_records.name",
                    "supported_purposes": [
                        "HEALTHCARE_SERVICES_ACCESS",
                        "MEDICAL_RECORDS_SHARING",
                        "MEDICAL_HISTORY_VALIDATION"
                    ]
                }
            ],
            "description_l10n_id": "domain.health.description",
            "id": "HEALTH",
            "name_l10n_id": "domain.health.name"
        },
        {
            "classes": [
                {
                    "id": "PAYMENT_INSTRUMENTS",
                    "name_l10n_id": "class.payment_instruments.name",
                    "supported_purposes": [
                        "PAYMENT_AUTHORIZATION",
                        "PAYMENT_EXECUTION",
                        "PROOF_OF_PAYMENT"
                    ]
                },
                {
                    "id": "PAYMENT_CREDENTIALS_AUTHORIZATIONS",
                    "name_l10n_id": "class.payment_credentials_authorizations.name",
                    "supported_purposes": [
                        "FINANCIAL_AUTHORIZATION_MANAGEMENT",
                        "STRONG_CUSTOMER_AUTHENTICATION"
                    ]
                },
                {
                    "id": "PUBLIC_PAYMENTS_FEES",
                    "name_l10n_id": "class.public_payments_fees.name",
                    "supported_purposes": [
                        "PROOF_OF_TAX_PAYMENT",
                        "PROOF_OF_FEE_PAYMENT",
                        "DIGITAL_STAMP_DUTY_VALIDATION"
                    ]
                },
                {
                    "id": "RECURRING_PAYMENTS_SUBSCRIPTIONS",
                    "name_l10n_id": "class.recurring_payments_subscriptions.name",
                    "supported_purposes": [
                        "RECURRING_PAYMENT_MANAGEMENT",
                        "SUBSCRIPTION_MANDATE_VERIFICATION"
                    ]
                }
            ],
            "description_l10n_id": "domain.financial.description",
            "id": "FINANCIAL",
            "name_l10n_id": "domain.financial.name"
        },
        {
            "classes": [
                {
                    "id": "CULTURAL_CARDS_BENEFITS",
                    "name_l10n_id": "class.cultural_cards_benefits.name",
                    "supported_purposes": [
                        "CULTURAL_SERVICES_ACCESS",
                        "LEISURE_SERVICES_ACCESS",
                        "MEMBER_DISCOUNT_APPLICATION"
                    ]
                },
                {
                    "id": "MEMBERSHIP_LOYALTY_PROGRAMS",
                    "name_l10n_id": "class.membership_loyalty_programs.name",
                    "supported_purposes": [
                        "AFFILIATION_VERIFICATION",
                        "PARTICIPATION_VERIFICATION",
                        "LOYALTY_BENEFITS_USE"
                    ]
                }
            ],
            "description_l10n_id": "domain.culture_leisure.description",
            "id": "CULTURE_LEISURE",
            "name_l10n_id": "domain.culture_leisure.name"
        },
        {
            "classes": [
                {
                    "id": "EMPLOYMENT_DOCUMENTS",
                    "name_l10n_id": "class.employment_documents.name",
                    "supported_purposes": [
                        "EMPLOYMENT_STATUS_VERIFICATION",
                        "PROFESSIONAL_PROFILE_VALIDATION"
                    ]
                },
                {
                    "id": "EMPLOYMENT_STATUS",
                    "name_l10n_id": "class.employment_status.name",
                    "supported_purposes": [
                        "CONTRIBUTION_RECORDS_VERIFICATION",
                        "EMPLOYMENT_BENEFITS_ELIGIBILITY"
                    ]
                },
                {
                    "id": "EMPLOYMENT_AFFILIATION",
                    "name_l10n_id": "class.employment_affiliation.name",
                    "supported_purposes": [
                        "ACCESS_PERMIT"
                    ]
                }
            ],
            "description_l10n_id": "domain.employment.description",
            "id": "EMPLOYMENT",
            "name_l10n_id": "domain.employment.name"
        },
        {
            "classes": [
                {
                    "id": "LICENSES_AUTHORIZATIONS",
                    "name_l10n_id": "class.licenses_authorizations.name",
                    "supported_purposes": [
                        "DRIVING_RIGHTS_VERIFICATION",
                        "NAVIGATION_RIGHTS_VERIFICATION",
                        "LAW_ENFORCEMENT_CONTROLS"
                    ]
                },
                {
                    "id": "VEHICLE_DOCUMENTS",
                    "name_l10n_id": "class.vehicle_documents.name",
                    "supported_purposes": [
                        "VEHICLE_REGISTRATION_VERIFICATION",
                        "VEHICLE_INSPECTION_VERIFICATION",
                        "INSURANCE_STATUS_CHECK"
                    ]
                },
                {
                    "id": "TRANSPORT_SUBSCRIPTIONS",
                    "name_l10n_id": "class.transport_subscriptions.name",
                    "supported_purposes": [
                        "TRANSPORT_SERVICES_ACCESS",
                        "PUBLIC_TRANSPORT_PASS_VERIFICATION"
                    ]
                },
                {
                    "id": "TRAVEL_DOCUMENTS",
                    "name_l10n_id": "class.travel_documents.name",
                    "supported_purposes": [
                        "RIGHT_TO_TRAVEL",
                        "CROSS_BORDER_IDENTITY_CHECK"
                    ]
                },
                {
                    "id": "TRAVEL_INSURANCE_BOOKINGS",
                    "name_l10n_id": "class.travel_insurance_bookings.name",
                    "supported_purposes": [
                        "TRAVEL_INSURANCE_VERIFICATION",
                        "ACCOMMODATION_RESERVATION_CHECK",
                        "TRANSPORT_RESERVATION_CHECK"
                    ]
                },
                {
                    "id": "DISCOUNTS_BENEFITS",
                    "name_l10n_id": "class.discounts_benefits.name",
                    "supported_purposes": [
                        "MEMBER_DISCOUNT_APPLICATION",
                        "TOURIST_BENEFITS_ACCESS"
                    ]
                }
            ],
            "description_l10n_id": "domain.mobility_travel.description",
            "id": "MOBILITY_TRAVEL",
            "name_l10n_id": "domain.mobility_travel.name"
        },
        {
            "classes": [
                {
                    "id": "ECONOMIC_BENEFITS_ALLOWANCES",
                    "name_l10n_id": "class.economic_benefits_allowances.name",
                    "supported_purposes": [
                        "FAMILY_BENEFITS_ELIGIBILITY",
                        "UNEMPLOYMENT_BENEFITS_ELIGIBILITY",
                        "ECONOMIC_SUPPORT_ALLOCATION"
                    ]
                },
                {
                    "id": "INCENTIVES_VOUCHERS",
                    "name_l10n_id": "class.incentives_vouchers.name",
                    "supported_purposes": [
                        "DIGITAL_VOUCHER_USE",
                        "PURCHASE_INCENTIVE_USE",
                        "CASHBACK_ELIGIBILITY_VERIFICATION"
                    ]
                },
                {
                    "id": "HEALTH_WELLBEING_BONUSES",
                    "name_l10n_id": "class.health_wellbeing_bonuses.name",
                    "supported_purposes": [
                        "HEALTHCARE_BONUS_ACCESS",
                        "MENTAL_HEALTH_VOUCHER_USE",
                        "SPORTS_VOUCHER_USE"
                    ]
                }
            ],
            "description_l10n_id": "domain.bonuses.description",
            "id": "BONUSES",
            "name_l10n_id": "domain.bonuses.name"
        }
    ],
    "purposes": [
        {
            "id": "IDENTITY_VERIFICATION",
            "name_l10n_id": "purpose.identity_verification.name"
        },
        {
            "id": "AGE_VERIFICATION",
            "name_l10n_id": "purpose.age_verification.name"
        },
        {
            "id": "PERSON_IDENTIFICATION",
            "name_l10n_id": "purpose.person_identification.name"
        },
        {
            "id": "CIVIL_STATUS_VERIFICATION",
            "name_l10n_id": "purpose.civil_status_verification.name"
        },
        {
            "id": "RIGHT_OF_RESIDENCE",
            "name_l10n_id": "purpose.right_of_residence.name"
        },
        {
            "id": "HOUSEHOLD_COMPOSITION_VERIFICATION",
            "name_l10n_id": "purpose.household_composition_verification.name"
        },
        {
            "id": "ELIGIBILITY_VERIFICATION",
            "name_l10n_id": "purpose.eligibility_verification.name"
        },
        {
            "id": "LEGAL_STATUS_VERIFICATION",
            "name_l10n_id": "purpose.legal_status_verification.name"
        },
        {
            "id": "CRIMINAL_RECORD_CHECK",
            "name_l10n_id": "purpose.criminal_record_check.name"
        },
        {
            "id": "RESIDENCE_HOUSEHOLD_VERIFICATION",
            "name_l10n_id": "purpose.residence_household_verification.name"
        },
        {
            "id": "PROPERTY_OWNERSHIP_VERIFICATION",
            "name_l10n_id": "purpose.property_ownership_verification.name"
        },
        {
            "id": "REAL_ESTATE_COMPLIANCE",
            "name_l10n_id": "purpose.real_estate_compliance.name"
        },
        {
            "id": "FAMILY_SOCIAL_SERVICES_ELIGIBILITY",
            "name_l10n_id": "purpose.family_social_services_eligibility.name"
        },
        {
            "id": "LOCAL_TAX_COMPLIANCE",
            "name_l10n_id": "purpose.local_tax_compliance.name"
        },
        {
            "id": "PROPERTY_TAX_VERIFICATION",
            "name_l10n_id": "purpose.property_tax_verification.name"
        },
        {
            "id": "QUALIFICATION_DEGREE_VERIFICATION",
            "name_l10n_id": "purpose.qualification_degree_verification.name"
        },
        {
            "id": "EDUCATION_PATHWAY_ELIGIBILITY",
            "name_l10n_id": "purpose.education_pathway_eligibility.name"
        },
        {
            "id": "PROFESSIONAL_LICENSE_VERIFICATION",
            "name_l10n_id": "purpose.professional_license_verification.name"
        },
        {
            "id": "SKILLS_ASSESSMENT",
            "name_l10n_id": "purpose.skills_assessment.name"
        },
        {
            "id": "VACCINATION_STATUS_VERIFICATION",
            "name_l10n_id": "purpose.vaccination_status_verification.name"
        },
        {
            "id": "FITNESS_STATUS_VERIFICATION",
            "name_l10n_id": "purpose.fitness_status_verification.name"
        },
        {
            "id": "HEALTH_RESTRICTED_ACCESS",
            "name_l10n_id": "purpose.health_restricted_access.name"
        },
        {
            "id": "HEALTHCARE_SERVICES_ACCESS",
            "name_l10n_id": "purpose.healthcare_services_access.name"
        },
        {
            "id": "MEDICAL_RECORDS_SHARING",
            "name_l10n_id": "purpose.medical_records_sharing.name"
        },
        {
            "id": "MEDICAL_HISTORY_VALIDATION",
            "name_l10n_id": "purpose.medical_history_validation.name"
        },
        {
            "id": "PAYMENT_AUTHORIZATION",
            "name_l10n_id": "purpose.payment_authorization.name"
        },
        {
            "id": "PAYMENT_EXECUTION",
            "name_l10n_id": "purpose.payment_execution.name"
        },
        {
            "id": "PROOF_OF_PAYMENT",
            "name_l10n_id": "purpose.proof_of_payment.name"
        },
        {
            "id": "FINANCIAL_AUTHORIZATION_MANAGEMENT",
            "name_l10n_id": "purpose.financial_authorization_management.name"
        },
        {
            "id": "STRONG_CUSTOMER_AUTHENTICATION",
            "name_l10n_id": "purpose.strong_customer_authentication.name"
        },
        {
            "id": "PROOF_OF_TAX_PAYMENT",
            "name_l10n_id": "purpose.proof_of_tax_payment.name"
        },
        {
            "id": "PROOF_OF_FEE_PAYMENT",
            "name_l10n_id": "purpose.proof_of_fee_payment.name"
        },
        {
            "id": "DIGITAL_STAMP_DUTY_VALIDATION",
            "name_l10n_id": "purpose.digital_stamp_duty_validation.name"
        },
        {
            "id": "RECURRING_PAYMENT_MANAGEMENT",
            "name_l10n_id": "purpose.recurring_payment_management.name"
        },
        {
            "id": "SUBSCRIPTION_MANDATE_VERIFICATION",
            "name_l10n_id": "purpose.subscription_mandate_verification.name"
        },
        {
            "id": "CULTURAL_SERVICES_ACCESS",
            "name_l10n_id": "purpose.cultural_services_access.name"
        },
        {
            "id": "LEISURE_SERVICES_ACCESS",
            "name_l10n_id": "purpose.leisure_services_access.name"
        },
        {
            "id": "MEMBER_DISCOUNT_APPLICATION",
            "name_l10n_id": "purpose.member_discount_application.name"
        },
        {
            "id": "AFFILIATION_VERIFICATION",
            "name_l10n_id": "purpose.affiliation_verification.name"
        },
        {
            "id": "PARTICIPATION_VERIFICATION",
            "name_l10n_id": "purpose.participation_verification.name"
        },
        {
            "id": "LOYALTY_BENEFITS_USE",
            "name_l10n_id": "purpose.loyalty_benefits_use.name"
        },
        {
            "id": "EMPLOYMENT_STATUS_VERIFICATION",
            "name_l10n_id": "purpose.employment_status_verification.name"
        },
        {
            "id": "PROFESSIONAL_PROFILE_VALIDATION",
            "name_l10n_id": "purpose.professional_profile_validation.name"
        },
        {
            "id": "CONTRIBUTION_RECORDS_VERIFICATION",
            "name_l10n_id": "purpose.contribution_records_verification.name"
        },
        {
            "id": "EMPLOYMENT_BENEFITS_ELIGIBILITY",
            "name_l10n_id": "purpose.employment_benefits_eligibility.name"
        },
        {
            "id": "DRIVING_RIGHTS_VERIFICATION",
            "name_l10n_id": "purpose.driving_rights_verification.name"
        },
        {
            "id": "NAVIGATION_RIGHTS_VERIFICATION",
            "name_l10n_id": "purpose.navigation_rights_verification.name"
        },
        {
            "id": "LAW_ENFORCEMENT_CONTROLS",
            "name_l10n_id": "purpose.law_enforcement_controls.name"
        },
        {
            "id": "VEHICLE_REGISTRATION_VERIFICATION",
            "name_l10n_id": "purpose.vehicle_registration_verification.name"
        },
        {
            "id": "VEHICLE_INSPECTION_VERIFICATION",
            "name_l10n_id": "purpose.vehicle_inspection_verification.name"
        },
        {
            "id": "INSURANCE_STATUS_CHECK",
            "name_l10n_id": "purpose.insurance_status_check.name"
        },
        {
            "id": "TRANSPORT_SERVICES_ACCESS",
            "name_l10n_id": "purpose.transport_services_access.name"
        },
        {
            "id": "PUBLIC_TRANSPORT_PASS_VERIFICATION",
            "name_l10n_id": "purpose.public_transport_pass_verification.name"
        },
        {
            "id": "RIGHT_TO_TRAVEL",
            "name_l10n_id": "purpose.right_to_travel.name"
        },
        {
            "id": "CROSS_BORDER_IDENTITY_CHECK",
            "name_l10n_id": "purpose.cross_border_identity_check.name"
        },
        {
            "id": "TRAVEL_INSURANCE_VERIFICATION",
            "name_l10n_id": "purpose.travel_insurance_verification.name"
        },
        {
            "id": "ACCOMMODATION_RESERVATION_CHECK",
            "name_l10n_id": "purpose.accommodation_reservation_check.name"
        },
        {
            "id": "TRANSPORT_RESERVATION_CHECK",
            "name_l10n_id": "purpose.transport_reservation_check.name"
        },
        {
            "id": "TOURIST_BENEFITS_ACCESS",
            "name_l10n_id": "purpose.tourist_benefits_access.name"
        },
        {
            "id": "FAMILY_BENEFITS_ELIGIBILITY",
            "name_l10n_id": "purpose.family_benefits_eligibility.name"
        },
        {
            "id": "UNEMPLOYMENT_BENEFITS_ELIGIBILITY",
            "name_l10n_id": "purpose.unemployment_benefits_eligibility.name"
        },
        {
            "id": "ECONOMIC_SUPPORT_ALLOCATION",
            "name_l10n_id": "purpose.economic_support_allocation.name"
        },
        {
            "id": "DIGITAL_VOUCHER_USE",
            "name_l10n_id": "purpose.digital_voucher_use.name"
        },
        {
            "id": "PURCHASE_INCENTIVE_USE",
            "name_l10n_id": "purpose.purchase_incentive_use.name"
        },
        {
            "id": "CASHBACK_ELIGIBILITY_VERIFICATION",
            "name_l10n_id": "purpose.cashback_eligibility_verification.name"
        },
        {
            "id": "HEALTHCARE_BONUS_ACCESS",
            "name_l10n_id": "purpose.healthcare_bonus_access.name"
        },
        {
            "id": "MENTAL_HEALTH_VOUCHER_USE",
            "name_l10n_id": "purpose.mental_health_voucher_use.name"
        },
        {
            "id": "SPORTS_VOUCHER_USE",
            "name_l10n_id": "purpose.sports_voucher_use.name"
        },
        {
            "id": "ACCESS_PERMIT",
            "name_l10n_id": "purpose.access_permit.name"
        }
    ]
}

Note

For a better and more efficient management of the localization of the Taxonomy, an Entity consulting it SHOULD:

• Download the basic version of the Taxonomy (compact, without localizations) using the .well-known/taxonomy endpoint.

• Determine the User's preferred language.

• Download only the necessary localization bundles.

• Dynamically merge localised content with the Taxonomy structure.

A non-normative example of a localization bundle output is given below:

{
  "taxonomy.name": "IT-Wallet Taxonomy",
  "taxonomy.description": "Hierarchical classification system for Digital Credentials in the IT-Wallet ecosystem",
  "domain.identity.name": "Identity",
  "domain.identity.description": "Credentials that establish or confirm a person's legal identity and personal, civil or legal status.",
  "class.identification_documents.name": "Identification Documents",
  "purpose.identity_verification.name": "Identity verification",
  "domain.authentication.name": "Authentication",
  "domain.authentication.description": "Credentials that attest authorisation to access restricted physical or digital spaces, services or resources.",
  "class.access.name": "Access",
  "purpose.access_permit.name": "Access permit verification",
  "...": "..."
}

Localization bundles MUST be available at the URI composed by appending the locale code and .json to the localization.base_uri value defined in the taxonomy. Each locale bundle MUST be accessible following the naming pattern {locale_code}.json, where {locale_code} is replaced with the corresponding locale code from the available_locales array.

A non-normative example of the Italian localization URI for the bundle would be https://trust-registry.eid-wallet.example.it/.well-known/l10n/taxonomy/it.json.

7.4. Claims Registry

The Claims Registry endpoint URL is published under the claims_registry key of the Registry Discovery document. The endpoint supports the content negotiation and signed representation common to all Registry Infrastructure endpoints (see Content Negotiation and Signed Representation).

The Claims Registry MUST contain:

• Standardised Claims: Semantic definitions for all Credential attributes with data types and validation rules.

• Interoperability Mappings: Alias definitions for claims that use different terminology across standards (e.g., ISO18013-5 place_of_birth mapped to canonical birth_place).

• Data Formats: Standardised data types (string, date, numeric, boolean, email, url, image, array, object) with validation patterns.

The Claims Registry MUST ensure:

• Semantic Consistency: Prevents conflicts between duplicate or overlapping claims across the ecosystem.

• Cross-border Interoperability: Ensures EU compliance and consistent claim interpretation.

• Schema Validation: Provides authoritative definitions for claim validation across all Credential scenarios.

• Regulatory Alignment: Coordinates with national and EU regulatory framework.

• Credential-Agnostic Scenarios: Supports scenarios where user convenience and business operational efficiency are prioritized over regulatory compliance and audit trails.

Note

The Claims Registry defines semantic properties of individual attributes, but MUST NOT specify selective disclosure capabilities. Selective disclosure depends on Credential format implementations (SD-JWT, mDocs), issuer technical configurations, and presentation context. These capabilities are specified at the Credential type level within the Digital Credentials Catalog and implemented during Credential presentation flows.

7.4.1. Claims Registry Usage

As shown in Figure Registries and Catalogues of the Ecosystem and Figure Discovery on the Registry Infrastructure, the Claims Registry MUST support the complete ecosystem lifecycle:

7.4.1.1. Claims Registry Usage: During Onboarding Process

• AS Registration: Authentic Sources declare available claims from standardized registry during capability registration.

• CI Registration: Credential Issuers select Authentic Source entities based on required claims. The Credential types that use those claims are registered in the catalog by the Attestation Scheme Provider, see Credential Type Registration.

• RP Registration: Relying Parties specify authorization requirements using domains/purposes for specific User's attributes.

7.4.1.2. Claims Registry Usage: During Operational Activities

• Credential Issuance: Claims definitions ensure consistent data representation across different Credential types.

• Presentation Requests: Relying Parties reference claims for schema validation and authorization verification in both credential-specific and credential-agnostic scenarios.

7.4.2. Claims Registry Structure

The Claims Registry maintains language-neutral, technical definitions for semantic consistency across the ecosystem. User-facing localizations for claim names and descriptions are provided via dedicated localization bundles referenced through the localization.base_uri field, enabling efficient multilingual support without compromising the registry's structural integrity.

Table 7.8 First-level Fields of the Claims Registry

Field Name	Description
id	REQUIRED. Unique identifier of the Claims Registry (e.g., urn:claims:it-wallet).
version	REQUIRED. The version of the Claims Registry (e.g., 1.0.0).
last_modified	REQUIRED. The timestamp indicating when the list was last updated (e.g., 2025-03-15T12:00:00Z).
localization	REQUIRED. Localization configuration object containing: default_locale: Default locale code (e.g., it). available_locales: Array of supported locale codes (e.g., ["en", "it"]). base_uri: Base URI for localization bundle retrieval (e.g., https://trust-registry.eid-wallet.example.it/.well-known/l10n/claims/). version: Version of the localization bundle format.
claims	REQUIRED. A JSON Object where each key is a claim name and each value is a JSON Object describing that claim. Each claim object contains the parameters defined in the "Claim Entry Parameters" table below.

Table 7.9 Claim Entry Parameters

Field Name	Description
description_l10n_id	REQUIRED. Localization key referencing the human-readable description of the claim in the localization bundle (e.g., claim.given_name.description).
type	REQUIRED. Data type of the claim. Supported values: string, boolean, array, object.
format	OPTIONAL. Semantic format qualifier for string types (e.g., date for ISO 8601 dates, uri, data for Base64-encoded binary).
encoding	OPTIONAL. Encoding applied to the value (e.g., base64). Present when format is data.
aliases	OPTIONAL. Array of alternative claim names used in other standards that map to this canonical claim (e.g., ["birthdate"] for birth_date, ["date_of_expiry"] for expiry_date).
nested_claims	OPTIONAL. Array of claim names that form the properties of an object type claim (e.g., ["country", "locality", "region"] for place_of_birth).
nested_item_claims	OPTIONAL. Array of claim names representing the properties of each item in an array type claim (e.g., ["vehicle_category_code", "issue_date", "expiry_date", "codes"] for driving_privileges).
items	OPTIONAL. JSON object describing the schema of each element in a simple array type claim (e.g., {"type": "string"} for nationalities).
attribute_identifier	OPTIONAL. Identifier of the corresponding attribute in the EUDIW Catalogue of Attributes when the claim is aligned to that catalogue, as described in Registry Integration and Cross-References. When present, it MUST equal that attribute identifier.

A non-normative example of Claims Registry structure is given below:

{
    "id": "urn:claims:it-wallet",
    "version": "1.0.0",
    "last_modified": "2026-03-06T00:00:00Z",
    "localization": {
        "available_locales": [
            "en",
            "it"
        ],
        "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/claims/",
        "default_locale": "it",
        "version": "1.0.0"
    },
    "claims": {
        "academic_qualification_date": {
            "description_l10n_id": "claim.academic_qualification_date.description",
            "format": "date",
            "type": "string"
        },
        "academic_year": {
            "description_l10n_id": "claim.academic_year.description",
            "type": "string"
        },
        "address": {
            "description_l10n_id": "claim.address.description",
            "nested_claims": [
                "country",
                "house_number",
                "locality",
                "locality_fraction",
                "postal_code",
                "region",
                "street_address"
            ],
            "type": "object"
        },
        "birth_date": {
            "aliases": [
                "birthdate"
            ],
            "description_l10n_id": "claim.birth_date.description",
            "format": "date",
            "type": "string"
        },
        "birth_place": {
            "description_l10n_id": "claim.birth_place.description",
            "type": "string"
        },
        "codes": {
            "description_l10n_id": "claim.codes.description",
            "items": {
                "properties": {
                    "code": {
                        "description_l10n_id": "claim.code.description",
                        "type": "string"
                    },
                    "sign": {
                        "description_l10n_id": "claim.sign.description",
                        "type": "string"
                    },
                    "value": {
                        "description_l10n_id": "claim.value.description",
                        "type": "string"
                    }
                },
                "type": "object"
            },
            "nested_item_claims": [
                "code",
                "sign",
                "value"
            ],
            "type": "array"
        },
        "constant_attendance_allowance": {
            "description_l10n_id": "claim.constant_attendance_allowance.description",
            "type": "boolean"
        },
        "consulate_code": {
            "description_l10n_id": "claim.consulate_code.description",
            "type": "string"
        },
        "consulate_name": {
            "description_l10n_id": "claim.consulate_name.description",
            "type": "string"
        },
        "content": {
            "description_l10n_id": "claim.content.description",
            "encoding": "base64",
            "format": "data",
            "type": "string"
        },
        "country": {
            "description_l10n_id": "claim.country.description",
            "type": "string"
        },
        "cpia_school_year": {
            "description_l10n_id": "claim.cpia_school_year.description",
            "type": "string"
        },
        "degree_class": {
            "description_l10n_id": "claim.degree_class.description",
            "type": "string"
        },
        "degree_class_name": {
            "description_l10n_id": "claim.degree_class_name.description",
            "type": "string"
        },
        "degree_course_name": {
            "description_l10n_id": "claim.degree_course_name.description",
            "type": "string"
        },
        "degree_course_year": {
            "description_l10n_id": "claim.degree_course_year.description",
            "type": "string"
        },
        "document_iss_authority": {
            "description_l10n_id": "claim.document_iss_authority.description",
            "type": "string"
        },
        "document_iss_country": {
            "description_l10n_id": "claim.document_iss_country.description",
            "type": "string"
        },
        "document_number": {
            "description_l10n_id": "claim.document_number.description",
            "type": "string"
        },
        "driving_privileges": {
            "description_l10n_id": "claim.driving_privileges.description",
            "nested_item_claims": [
                "vehicle_category_code",
                "issue_date",
                "expiry_date",
                "codes"
            ],
            "type": "array"
        },
        "education_degrees": {
            "description_l10n_id": "claim.education_degrees.description",
            "nested_item_claims": [
                "academic_qualification_date",
                "degree_class",
                "degree_class_name",
                "degree_course_name",
                "institute_name",
                "programme_type_name",
                "qualification_grade_value",
                "qualification_name"
            ],
            "type": "array"
        },
        "education_enrollments": {
            "description_l10n_id": "claim.education_enrollments.description",
            "nested_item_claims": [
                "academic_year",
                "degree_class",
                "degree_class_name",
                "degree_course_name",
                "degree_course_year",
                "institute_name",
                "programme_type_name"
            ],
            "type": "array"
        },
        "educational_track": {
            "description_l10n_id": "claim.educational_track.description",
            "type": "string"
        },
        "effective_date": {
            "description_l10n_id": "claim.effective_date.description",
            "format": "date",
            "type": "string"
        },
        "expiry_date": {
            "aliases": [
                "date_of_expiry"
            ],
            "description_l10n_id": "claim.expiry_date.description",
            "format": "date",
            "type": "string"
        },
        "family_name": {
            "description_l10n_id": "claim.family_name.description",
            "type": "string"
        },
        "foreign_residence": {
            "description_l10n_id": "claim.foreign_residence.description",
            "type": "boolean"
        },
        "given_name": {
            "description_l10n_id": "claim.given_name.description",
            "type": "string"
        },
        "house_number": {
            "description_l10n_id": "claim.house_number.description",
            "type": "string"
        },
        "institute_code": {
            "description_l10n_id": "claim.institute_code.description",
            "type": "string"
        },
        "institute_name": {
            "description_l10n_id": "claim.institute_name.description",
            "type": "string"
        },
        "issue_date": {
            "description_l10n_id": "claim.issue_date.description",
            "format": "date",
            "type": "string"
        },
        "link_qr_code": {
            "description_l10n_id": "claim.link_qr_code.description",
            "format": "uri",
            "type": "string"
        },
        "locality": {
            "description_l10n_id": "claim.locality.description",
            "type": "string"
        },
        "locality_fraction": {
            "description_l10n_id": "claim.locality_fraction.description",
            "type": "string"
        },
        "nationalities": {
            "description_l10n_id": "claim.nationalities.description",
            "items": {
                "type": "string"
            },
            "type": "array"
        },
        "place_of_birth": {
            "description_l10n_id": "claim.place_of_birth.description",
            "nested_claims": [
                "country",
                "locality",
                "region"
            ],
            "type": "object"
        },
        "portrait": {
            "description_l10n_id": "claim.portrait.description",
            "encoding": "base64",
            "format": "data",
            "type": "string"
        },
        "postal_code": {
            "description_l10n_id": "claim.postal_code.description",
            "type": "string"
        },
        "professional_qualification": {
            "description_l10n_id": "claim.professional_qualification.description",
            "type": "string"
        },
        "programme_type_name": {
            "description_l10n_id": "claim.programme_type_name.description",
            "type": "string"
        },
        "qualification_grade_value": {
            "description_l10n_id": "claim.qualification_grade_value.description",
            "type": "string"
        },
        "qualification_name": {
            "description_l10n_id": "claim.qualification_name.description",
            "type": "string"
        },
        "qualification_type": {
            "description_l10n_id": "claim.qualification_type.description",
            "type": "string"
        },
        "qualification_type_description": {
            "description_l10n_id": "claim.qualification_type_description.description",
            "type": "string"
        },
        "qualification_year": {
            "description_l10n_id": "claim.qualification_year.description",
            "type": "string"
        },
        "region": {
            "description_l10n_id": "claim.region.description",
            "type": "string"
        },
        "restrictions_conditions": {
            "description_l10n_id": "claim.restrictions_conditions.description",
            "type": "string"
        },
        "school_attendance_type": {
            "description_l10n_id": "claim.school_attendance_type.description",
            "type": "string"
        },
        "school_code": {
            "description_l10n_id": "claim.school_code.description",
            "type": "string"
        },
        "school_course_year": {
            "description_l10n_id": "claim.school_course_year.description",
            "type": "string"
        },
        "school_name": {
            "description_l10n_id": "claim.school_name.description",
            "type": "string"
        },
        "school_qualifications": {
            "description_l10n_id": "claim.school_qualifications.description",
            "nested_item_claims": [
                "educational_track",
                "institute_code",
                "institute_name",
                "professional_qualification",
                "qualification_grade_value",
                "qualification_type",
                "qualification_type_description",
                "qualification_year",
                "school_code",
                "school_name",
                "school_year"
            ],
            "type": "array"
        },
        "school_year": {
            "description_l10n_id": "claim.school_year.description",
            "type": "string"
        },
        "street_address": {
            "description_l10n_id": "claim.street_address.description",
            "type": "string"
        },
        "tax_id_code": {
            "description_l10n_id": "claim.tax_id_code.description",
            "type": "string"
        },
        "un_distinguishing_sign": {
            "description_l10n_id": "claim.un_distinguishing_sign.description",
            "type": "string"
        },
        "vehicle_category_code": {
            "description_l10n_id": "claim.vehicle_category_code.description",
            "type": "string"
        }
    }
}

Note

For a better and more efficient management of the localization of the information contained in the Claims Registry, an Entity consulting it SHOULD:

• Download the basic version of the Claims Registry (compact, without localizations) using the .well-known/claims endpoint.

• Determine the User's preferred language.

• Download only the necessary localization bundles.

• Dynamically merge localised content with the Claims Registry structure.

A non-normative example of a localization bundle output is given below:

{
  "claim.given_name.description": "Person's given name(s) as they appear on official documents.",
  "claim.birth_date.description": "Date of birth, in ISO 8601 format (YYYY-MM-DD). Also known as birthdate.",
  "claim.driving_privileges.description": "Array of authorized vehicle categories with details.",
  "...": "..."
}

Localization bundles MUST be available at the URI composed by appending the locale code and .json to the localization.base_uri value (e.g., https://trust-registry.eid-wallet.example.it/.well-known/l10n/claims/it.json).

7.5. Authentic Source Registry

The Authentic Source Registry endpoint URL is published under the authentic_sources key of the Registry Discovery document. The endpoint supports the content negotiation and signed representation common to all Registry Infrastructure endpoints (see Content Negotiation and Signed Representation).

The Authentic Source Registry MUST contain at least:

• Organization Information: Legal entity details, regulatory status, and authoritative role within specific domains.

• Data Capabilities: Declared claims availability referencing standardized definitions from the Claims Registry with corresponding Taxonomy classifications.

• Integration Methods: Technical access mechanisms (PDND).

• Intended Purposes: Supported Credential types and business contexts for AS-CI coordination.

• Data Quality Assurance: Authoritative status, update frequency, and audit trail capabilities.

The Authentic Source Registry MUST ensure:

• Coordinated Data Access: Enables CI discovery of appropriate data from Authentic Sources for Credential issuance.

• AS-CI Integration: Technical endpoints and access methods enable standardized AS-CI communication. It facilitates approval workflows and data access coordination between entities.

• Regulatory Compliance: Supports public administration transparency and private sector coordination requirements.

Note

The Authentic Source Registry is a public registry that provides the Credential Issuer with guidance for Credential provisioning.

7.5.1. Authentic Source Registry Usage

As shown in Figure Registries and Catalogues of the Ecosystem and Figure Discovery on the Registry Infrastructure, the Authentic Source Registry supports ecosystem coordination throughout the operational lifecycle:

7.5.1.1. Authentic Source Registry Usage: During Onboarding Process

• AS Self-Declaration: Authentic Sources register capabilities before any Credential types exist in the catalog.

• CI Discovery: Credential Issuers search for Authentic Source entities based on required claims and intended Credential types.

7.5.1.2. Authentic Source Registry Usage: During Operational Activities

• Credential Issuance: Credential Issuer systems reference Authentic Source Registry for real-time data access during Credential issuance.

7.5.2. Authentic Source Registry Structure

During registration, Authentic Sources declare their capabilities before Credential types exist in the catalog. This declaration establishes the foundation for subsequent CI registration and Credential type creation.

7.5.2.1. Authentic Source Unique Identifier Schema

Each Authentic Source MUST be assigned a unique identifier that follows the HTTPS URL schema defined below. This identifier is used for referencing AS entities across the registry system and in the Digital Credentials Catalog, ensuring consistency with OpenID Federation entity identification patterns.

AS Identifier Schema:

https://{organization_domain}[/{optional_path}]

Schema Components:

• organization_domain: DNS domain controlled by the organization

• optional_path: Additional path component for specific services or departments

The AS identifier MUST follow these normative rules:

1. HTTPS Protocol: MUST use HTTPS scheme for security and trust verification

2. Domain Ownership: Organization MUST control the DNS domain used in the identifier

3. Uniqueness: Guaranteed through DNS namespace uniqueness

4. Stability: SHOULD remain stable over time to avoid reference breakage

5. Resolvability: The URL SHOULD be resolvable (though not required to serve content)

Examples of compliant AS identifiers:

• https://motorizzazione.gov.example: Public - Ministry of Transport, Motorization Dept

• https://registry.anpr.example: Public - National Registry of Resident Population

• https://api.bank.example/auth-source: Private - Example Bank Financial Services

7.5.2.2. Authentic Source Registry Parameters

The Authentic Source Registry MUST contain the following parameters for each registered Authentic Source:

Table 7.10 First-level Fields of the Authentic Source Registry

Field Name	Description
id	REQUIRED. Unique identifier of the Authentic Source Registry (e.g., urn:authentic-sources:it-wallet).
version	REQUIRED. The version of the Authentic Source Registry (e.g., 1.0.0).
last_modified	REQUIRED. The timestamp indicating when the list was last updated (e.g., 2025-03-15T12:00:00Z).
localization	REQUIRED. Localization configuration object containing: default_locale: Default locale code (e.g., it). available_locales: Array of supported locale codes (e.g., ["en", "it"]). base_uri: Base URI for localization bundle retrieval (e.g., https://trust-registry.eid-wallet.example.it/.well-known/l10n/authentic-sources/). version: Version of the localization bundle format.
authentic_sources	REQUIRED. A JSON Array where each entry is a JSON Object representing an Authentic Source entity. Each object contains the parameters defined in the "Authentic Sources Parameters" table below, including entity identification, organizational information, data capabilities, and integration methods.

Table 7.11 Authentic Sources Parameters

Parameter	Type	Description
entity_id	string	REQUIRED. Unique identifier following the normative schema: https://{organization_domain}[/{optional_path}].
organization_info	JSON object	REQUIRED. Legal entity details and organizational metadata.
organization_info.organization_name_l10n_id	string	REQUIRED. Localization key referencing the localized organization name in the localization bundle (e.g., authentic_source1.name).
organization_info.organization_type	string	REQUIRED. Entity classification: "public" or "private".
organization_info.ipa_code	string	REQUIRED only for Public AS. IPA registration code for government entities.
organization_info.legal_identifier	string	REQUIRED. Legal registration identifier (Fiscal Code/VAT Number, or equivalent national identifier for foreign entities).
organization_info.homepage_uri	string	REQUIRED. URL pointing to the organization's homepage.
organization_info.contacts	String Array	REQUIRED. Array of contact email addresses for at least one user-support, one application, and one systems specialist.
organization_info.dpa_contact	string	REQUIRED. An e-mail address of Authentic Source DPA.
organization_info.policy_uri	string	REQUIRED. URL to privacy policy document.
organization_info.tos_uri	string	OPTIONAL. URL to terms of service document.
organization_info.organization_country	string	REQUIRED. Two-letter ISO 3166-1 alpha-2 country code of the organization.
organization_info.logo_uri	string	OPTIONAL. URL to the organization's logo image.
organization_info.logo_uri#integrity	string	Cryptographic digest of the logo image resource for integrity verification. REQUIRED if logo_uri is present. Format: {digest_method}-{digest_value} (e.g., "sha-256-abc123...").
organization_info.logo_alt_text_l10n_id	string	OPTIONAL. Alternative text for the organization's logo image.
organization_info.logo_extended_uri	string	OPTIONAL. URL to the organization's extended logo image.
organization_info.logo_extended_uri#integrity	string	Cryptographic digest of the extended logo image resource for integrity verification. REQUIRED if logo_extended_uri is present. Format: {digest_method}-{digest_value} (e.g., "sha-256-abc123...").
organization_info.logo_extended_alt_text_l10n_id	string	OPTIONAL. Alternative text for the organization's extended logo image.
data_capabilities	JSON Objects Array	REQUIRED. Array containing data capability specifications.
data_capabilities[].dataset_id	string	REQUIRED. The Dataset_id within the scope of the Authentic Source, which MAY be used as a query parameter for the GetAttributeClaims service.
data_capabilities[].data_origin_l10n_id	string	REQUIRED. Localization key referencing the human-readable name of the data origin or department providing the data (e.g., authentic_source1.dataset1.origin).
data_capabilities[].intended_purposes	String Array	REQUIRED. Business purposes served, using taxonomy purpose identifiers (e.g., ["IDENTITY_VERIFICATION", "DRIVING_RIGHTS_VERIFICATION"]).
data_capabilities[].available_claims	String Array	REQUIRED. Claims available from this data capability.
data_capabilities[].available_claims.claim_name	string	REQUIRED. It Contains the name of the claim.
data_capabilities[].available_claims.order	number	REQUIRED. Defines the order in which the information would be shown.
data_capabilities[].available_claims.mandatory	boolean	REQUIRED. Defines if a claim is always available or not.
data_capabilities[].integration_method	string	REQUIRED. Authorization framework used for data access. MUST be "pdnd".
data_capabilities[].integration_endpoint	string	OPTIONAL. Service access point (PDND endpoint).
data_capabilities[].api_specification	string	OPTIONAL. URL to OAS3 specification document for this data capability.
data_capabilities[].data_provision	JSON object	OPTIONAL. Data provision capabilities and timing specifications.
data_capabilities[].data_provision.immediate_flow	boolean	REQUIRED. Indicates if the Authentic Source supports immediate data provision.
data_capabilities[].data_provision.deferred_flow	boolean	REQUIRED. Indicates if the Authentic Source supports deferred data provision.
data_capabilities[].data_provision.max_response_time_minutes	integer	Maximum time in minutes for the Authentic Source to respond to a deferred data provision request. REQUIRED if deferred_flow is true.
data_capabilities[].data_provision.notification_methods	String Array	Array of notification methods supported by the Authentic Source for deferred data provision, such as "push", "poll". REQUIRED if deferred_flow is true.
data_capabilities[].user_information_l10n_id	string	OPTIONAL. Localization key referencing a Markdown-formatted string with human-readable information about the data capability relevant to the User (e.g., authentic_source1.dataset1.userinfo). This string MUST be provided by the Authentic Source to the Trust Anchor during onboarding. The Markdown formatting can be plain text or a combination of text and links. For example, if the Authentic Source's database only contains data registered after a specific date, this information MUST be conveyed through this key.
data_capabilities[].service_documentation_uri	string	OPTIONAL. URL pointing to the Authentic Source service documentation.
data_capabilities[].update_frequency	string	OPTIONAL. Indicates how frequently the Authentic Source updates its data. Possible values: "real_time" (near real-time updates, typically within minutes), "daily", "weekly", "monthly", "on_demand".
data_capabilities[].logo_uri	string	OPTIONAL. URL to the logo image related to the data.
data_capabilities[].logo_uri#integrity	string	Cryptographic digest of the logo image resource for integrity verification. REQUIRED if logo_uri is present. Format: {digest_method}-{digest_value} (e.g., "sha-256-abc123...").
data_capabilities[].logo_alt_text_l10n_id	string	OPTIONAL. Alternative text for the organization's logo image.
data_capabilities[].background_color	string	OPTIONAL. String value of the background color related to be displayed together with the data.
data_capabilities[].contacts	JSON Object Array	OPTIONAL. Array containing customer service contacts or user support channels related to the specific dataset. Each object contains: type: REQUIRED. Indicates the type of contact information and MUST be set to email, telephone or url. value: REQUIRED. Contains the value of the contact information corresponding to the specified type. description: OPTIONAL. A textual description associated with the contact information.
data_capabilities[].verification_endpoint	JSON object	OPTIONAL. Present only for Annex VI attributes relying on a public-sector Authentic Source that are exported to the EUDIW Catalogue of Attributes. Describes the cross-border verification interface exposed to Qualified Trust Service Providers, distinct from the domestic PDND e-Service and conformant to ETSI TS 119 478. It contains method (one of oots_edelivery for the ISO 15000/eDelivery interface of ETSI TS 119 478 Section 6.2, or rest_oauth2 for the REST + OAuth 2.0 interface of ETSI TS 119 478 Section 6.1) and endpoint (the eDelivery party identifier or REST endpoint). The interface MAY be exposed by the Authentic Source directly or by a designated national intermediary (e.g. an OOTS access point).

Note

For further details on the required features and the expected outcome in terms of user experience, see the Section Issuance from the Wallet Instance Catalog for the parameter data_capabilities.user_information and Section Focus on Electronic Attestations of Attributes for the parameters organization_info.logo_uri, organization_info.logo_extended_uri, data_capabilities.logo_uri, data_capabilities.background_color and data_capabilities.available_claims.order.

7.5.2.3. Authentic Source Registry Example

A non-normative example of AS Registry structure is given below:

{
    "id": "urn:authentic-sources:it-wallet",
    "version": "1.0.0",
    "last_modified": "2025-03-15T12:00:00Z",
    "localization": {
        "default_locale": "it",
        "available_locales": [
            "en",
            "it"
        ],
        "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/authentic-sources/",
        "version": "1.0.0"
    },
    "authentic_sources": [
        {
            "entity_id": "https://motorizzazione.gov.example",
            "organization_info": {
                "contacts": [
                    "registry@motorizzazione.gov.example",
                    "technical-support@motorizzazione.gov.example"
                ],
                "dpa_contact": "dpa@motorizzazione.gov.example",
                "homepage_uri": "https://www.gov.example/transport",
                "ipa_code": "m_inf",
                "legal_identifier": "80192770587",
                "logo_extended_uri": "https://trust-registry.eid-wallet.example.it/logos/m_inf/extended-image.svg",
                "logo_extended_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
                "logo_uri": "https://trust-registry.eid-wallet.example.it/logos/m_inf/image.svg",
                "logo_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
                "organization_country": "IT",
                "organization_name": "Ministero dei Trasporti - Direzione generale per la Motorizzazione",
                "organization_name_l10n_id": "authentic_source1.name",
                "organization_type": "public",
                "policy_uri": "https://www.gov.example/transport/privacy-policy",
                "tos_uri": "https://www.gov.example/transport/terms-of-service"
            },
            "data_capabilities": [
                {
                    "api_specification": "https://docs.gov.example/transport/api-oas3.yaml",
                    "available_claims": [
                        {
                            "claim_name": "given_name",
                            "mandatory": true,
                            "order": 1
                        },
                        {
                            "claim_name": "family_name",
                            "mandatory": true,
                            "order": 2
                        },
                        {
                            "claim_name": "birth_date",
                            "mandatory": true,
                            "order": 3
                        },
                        {
                            "claim_name": "birth_place",
                            "mandatory": true,
                            "order": 4
                        },
                        {
                            "claim_name": "issue_date",
                            "mandatory": true,
                            "order": 5
                        },
                        {
                            "claim_name": "document_iss_country",
                            "mandatory": true,
                            "order": 6
                        },
                        {
                            "claim_name": "document_iss_authority",
                            "mandatory": true,
                            "order": 7
                        },
                        {
                            "claim_name": "expiry_date",
                            "mandatory": true,
                            "order": 8
                        },
                        {
                            "claim_name": "document_number",
                            "mandatory": true,
                            "order": 9
                        },
                        {
                            "claim_name": "portrait",
                            "mandatory": true,
                            "order": 10
                        },
                        {
                            "claim_name": "un_distinguishing_sign",
                            "mandatory": true,
                            "order": 11
                        },
                        {
                            "claim_name": "restrictions_conditions",
                            "mandatory": false,
                            "order": 12
                        },
                        {
                            "claim_name": "driving_privileges",
                            "mandatory": true,
                            "order": 13
                        }
                    ],
                    "background_color": "#12107c",
                    "contacts": [
                        {
                            "type": "email",
                            "value": "citizen-support@motorizzazione.gov.example"
                        }
                    ],
                    "data_origin_l10n_id": "authentic_source1.dataset1.origin",
                    "data_provision": {
                        "deferred_flow": false,
                        "immediate_flow": true
                    },
                    "dataset_id": "38832801",
                    "integration_endpoint": "https://api.gov.example/transport/driving-license",
                    "integration_method": "pdnd",
                    "intended_purposes": [
                        "IDENTITY_VERIFICATION",
                        "PERSON_IDENTIFICATION",
                        "DRIVING_RIGHTS_VERIFICATION",
                        "LAW_ENFORCEMENT_CONTROLS"
                    ],
                    "logo_uri": "https://trust-registry.eid-wallet.example.it/logos/38832801/image.svg",
                    "logo_uri#integrity": "sha-256-b1946ac92492d2347c6235b4d2611184e2a3f8b8c8f8f8e8f8f8f8f8f8f8f8f8",
                    "service_documentation_uri": "https://docs.gov.example/transport/api-docs",
                    "update_frequency": "real_time",
                    "user_information_l10n_id": "authentic_source1.dataset1.userinfo",
                    "verification_endpoint": {
                        "method": "oots_edelivery",
                        "endpoint": "https://api.gov.example/transport/driving-license/edelivery"
                    }
                }
            ]
        },
        {
            "entity_id": "https://api.bank.example/auth-source",
            "organization_info": {
                "contacts": [
                    "digital-credentials@bank.example",
                    "api-support@bank.example"
                ],
                "dpa_contact": "dpa@bank.example",
                "homepage_uri": "https://www.bank.example",
                "legal_identifier": "12345678901",
                "logo_extended_uri": "https://trust-registry.eid-wallet.example.it/logos/12345678901/extended-image.svg",
                "logo_extended_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
                "logo_uri": "https://trust-registry.eid-wallet.example.it/logos/12345678901/image.svg",
                "logo_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
                "organization_country": "IT",
                "organization_name": "Banca Esempio SpA",
                "organization_name_l10n_id": "authentic_source2.name",
                "organization_type": "private",
                "policy_uri": "https://www.bank.example/privacy-policy",
                "tos_uri": "https://www.bank.example/terms-of-service"
            },
            "data_capabilities": [
                {
                    "api_specification": "https://api.bank.example/docs/psd2-openapi.yaml",
                    "available_claims": [
                        {
                            "claim_name": "given_name",
                            "mandatory": true,
                            "order": 1
                        },
                        {
                            "claim_name": "family_name",
                            "mandatory": true,
                            "order": 2
                        },
                        {
                            "claim_name": "birth_date",
                            "mandatory": false,
                            "order": 3
                        },
                        {
                            "claim_name": "tax_id_code",
                            "mandatory": true,
                            "order": 4
                        },
                        {
                            "claim_name": "account_holder_name",
                            "mandatory": true,
                            "order": 5
                        },
                        {
                            "claim_name": "iban",
                            "mandatory": true,
                            "order": 6
                        },
                        {
                            "claim_name": "account_status",
                            "mandatory": false,
                            "order": 7
                        },
                        {
                            "claim_name": "account_opening_date",
                            "mandatory": false,
                            "order": 8
                        },
                        {
                            "claim_name": "bank_name",
                            "mandatory": true,
                            "order": 9
                        },
                        {
                            "claim_name": "bank_code",
                            "mandatory": true,
                            "order": 10
                        }
                    ],
                    "background_color": "#003366",
                    "contacts": [
                        {
                            "type": "email",
                            "value": "digital-credentials@bank.example"
                        }
                    ],
                    "data_origin_l10n_id": "authentic_source2.dataset1.origin",
                    "data_provision": {
                        "deferred_flow": false,
                        "immediate_flow": true
                    },
                    "dataset_id": "38854801",
                    "integration_endpoint": "https://api.bank.example/psd2/v1/accounts",
                    "integration_method": "pdnd",
                    "intended_purposes": [
                        "PAYMENT_AUTHORIZATION",
                        "ELIGIBILITY_VERIFICATION"
                    ],
                    "logo_uri": "https://trust-registry.eid-wallet.example.it/logos/38854801/image.svg",
                    "logo_uri#integrity": "sha-256-d8e8fca2dc0f896fd7cb4cb0031ba249e3f8b8c8f8f8e8f8f8f8f8f8f8f8f8f9",
                    "service_documentation_uri": "https://docs.bank.example/psd2-api",
                    "update_frequency": "daily",
                    "user_information_l10n_id": "authentic_source2.dataset1.userinfo"
                },
                {
                    "api_specification": "https://api.bank.example/docs/psd2-openapi.yaml",
                    "available_claims": [
                        {
                            "claim_name": "given_name",
                            "mandatory": true,
                            "order": 1
                        },
                        {
                            "claim_name": "family_name",
                            "mandatory": true,
                            "order": 2
                        },
                        {
                            "claim_name": "tax_id_code",
                            "mandatory": true,
                            "order": 3
                        },
                        {
                            "claim_name": "transaction_history",
                            "mandatory": true,
                            "order": 4
                        },
                        {
                            "claim_name": "average_balance",
                            "mandatory": false,
                            "order": 5
                        },
                        {
                            "claim_name": "credit_score_indicator",
                            "mandatory": false,
                            "order": 6
                        }
                    ],
                    "background_color": "#003366",
                    "contacts": [
                        {
                            "type": "email",
                            "value": "digital-credentials@bank.example"
                        }
                    ],
                    "data_origin_l10n_id": "authentic_source2.dataset2.origin",
                    "data_provision": {
                        "deferred_flow": true,
                        "immediate_flow": false,
                        "max_response_time_minutes": 1440,
                        "notification_methods": [
                            "push",
                            "poll"
                        ]
                    },
                    "dataset_id": "38854802",
                    "integration_endpoint": "https://api.bank.example/psd2/v1/transactions",
                    "integration_method": "pdnd",
                    "intended_purposes": [
                        "PROOF_OF_PAYMENT",
                        "RECURRING_PAYMENT_MANAGEMENT"
                    ],
                    "logo_uri": "https://trust-registry.eid-wallet.example.it/logos/38854802/image.svg",
                    "logo_uri#integrity": "sha-256-f4a2b7e1dc0f896fd7cb4cb0031ba249e3f8b8c8f8f8e8f8f8f8f8f8f8f8f8fb",
                    "service_documentation_uri": "https://docs.bank.example/psd2-api",
                    "update_frequency": "weekly",
                    "user_information_l10n_id": "authentic_source2.dataset2.userinfo"
                }
            ]
        }
    ]
}

Note

For a better and more efficient management of the localization of the information contained in the Authentic Source Registry, an Entity consulting it SHOULD:

• Download the basic version of the Authentic Source Registry (compact, without localizations) using the .well-known/authentic-sources endpoint.

• Determine the User's preferred language.

• Download only the necessary localization bundles.

• Dynamically merge localised content with the Authentic Source Registry structure.

A non-normative example of a localization bundle output is given below:

{
  "authentic_source1.name": "Ministero delle infrastrutture e dei trasporti",
  "authentic_source1.dataset1.origin": "MIT -- Direzione Generale per la Motorizzazione",
  "authentic_source1.dataset1.userinfo": "###### Patente di Guida\nSono disponibili le patenti rilasciate dopo il 1° gennaio 2020. Per le patenti più vecchie, contattare l'ufficio motorizzazione locale.",
  "authentic_source2.name": "Banca Esempio SpA",
  "authentic_source2.dataset1.origin": "Esempio origine dei dati 1",
  "authentic_source2.dataset1.userinfo": "###### Informazioni sulla disponibilità dei dati\nL'accesso ai dati finanziari richiede il consenso del cliente ed è soggetto alla normativa PSD2. Le informazioni sui conti sono disponibili solo per i conti attivi.",
  "...": "..."
}

Localization bundles MUST be available at the URI composed by appending the locale code and .json to the localization.base_uri value defined in the registry. Each locale bundle MUST be accessible following the naming pattern {locale_code}.json, where {locale_code} is replaced with the corresponding locale code from the available_locales array.

A non-normative example of the Italian localization URI for the bundle would be https://trust-registry.eid-wallet.example.it/.well-known/l10n/authentic-sources/it.json.

7.6. Schema Registry

The Schema Registry is the authoritative inventory of all known and accepted Credential Schemas (JSON Schema for SD-JWT, CBOR Schema for mDOC) within the IT-Wallet ecosystem.

7.6.1. Schema Registry Objectives

1. Schema Centralization: Provide a centralized access point for all technical schemata used by Digital Credentials.

2. Integrity and Authenticity: Ensure the integrity and authenticity of the schema documents through cryptographic digests.

3. Interoperability: Facilitate the seamless integration of Wallet Providers and Relying Parties by providing consistent schema versions.

4. Credential Lifecycle Support: Act as a verifiable reference point for schema validation during issuance and presentation.

7.6.2. Schema Registry Usage

As shown in Figure Registries and Catalogues of the Ecosystem and Figure Discovery on the Registry Infrastructure, the main Entities interacting with the Schema Registry are:

• Attestation Scheme Providers: They provide the schema of a Credential type, or its alignment to the schema of an external Rulebook, and the Onboarding System registers it with its integrity digest during the Schema Provisioning.

• Credential Issuers: They use the Schema Registry to build their metadata and to issue the Digital Credentials according to the registered schema.

• Relying Parties: They use the Schema Registry to gather all the information needed about the Digital Credentials they intend to request during the presentation phase.

• Wallet Providers: They access the Schema Registry to retrieve all necessary information for integrating them into their Wallet Solutions.

7.6.3. Catalogue of Attestations

The schema_registry value in the Registry Discovery document is the root of the Catalogue of Attestations API. The Federation Trust Anchor MUST implement Section 5 of [EUDI-TS 11] and the OpenAPI document of Annex A.3 ([EUDI-TS 11 OpenAPI]). Each attestation schema MUST be a SchemaMeta object as defined in Section 4.3 of [EUDI-TS 11]. The schema MUST validate against the JSON Schema of Annex A.2 ([EUDI-TS 11 Attestation Schema]). The object MUST NOT contain properties outside that schema.

The API root has these paths:

• GET /schemas lists schemas with the query parameters of Annex A.3.

• GET /schemas/{schemaId} returns one schema. schemaId is the id of the SchemaMeta.

• PUT /schemas/{schemaId} replaces one schema.

• DELETE /schemas/{schemaId} deletes one schema.

id MUST be a UUID assigned by the Federation Trust Anchor when the schema is first registered. version MUST follow semantic versioning. The first published version MUST be 1.0.0. supportedFormats and each schemaURIs element MUST use the format identifiers of Section 4.3 of [EUDI-TS 11]. The format-specific schema document served at schemaURIs[].uri MUST follow Section 4.3.4 of [EUDI-TS 11]. A rulebookURI or a schemaURIs[].uri MAY carry an #integrity suffix. The suffix value MUST be integrity metadata as defined in Section 3 of [W3C-SRI]. When the suffix is present, the consumer MUST verify the document as defined in Section 3.3.5 of [W3C-SRI]. frameworkType openid_federation MUST be used only for a non-qualified EAA. isLoTE MUST follow Section 4.3.3 of [EUDI-TS 11]. The Attestation Rulebook of a QEAA or a PuB-EAA MUST be published as required by Section 4.2 of [EUDI-TS 11]. Publication of an EAA rulebook is RECOMMENDED.

7.6.3.1. List of schemas

GET /schemas MUST be available without authentication. The response MUST be HTTP 200 when the query is valid. The JWT payload MUST contain iss, iat and data. data MUST contain total, limit, offset and data. The inner data array contains the matching SchemaMeta objects. iss MUST identify the Federation Trust Anchor. iat MUST be the Unix time at which the JWT was issued, as defined in RFC 7519.

When limit is absent, the value 20 applies. When offset is absent, the value 0 applies. When no filter is present, the result set is every registered schema, returned from offset for at most limit entries. The Federation Trust Anchor MUST order that set by id ascending. A client that needs every matching schema MUST request the next page by increasing offset by limit until offset is greater than or equal to total. The Federation Trust Anchor MUST respond with HTTP 400 when the query does not conform to Annex A.3.

A successful application/jwt response MUST include the x-jku-url header. Its value MUST be the HTTPS URI of the JSON Web Key Set used to verify the signature. The same response MUST also be available as application/json under Content Negotiation and Signed Representation. The JSON body is the JWT payload.

The following non-normative example is one page of GET /schemas.

{
    "iss": "https://trust-anchor.example.org",
    "iat": 1742040000,
    "data": {
        "total": 1,
        "limit": 20,
        "offset": 0,
        "data": [
            {
                "id": "550e8400-e29b-41d4-a716-446655440000",
                "version": "1.0.0",
                "rulebookURI": "https://example.org/rulebooks/mdl",
                "trustedAuthorities": [
                    {
                        "frameworkType": "etsi_tl",
                        "value": "https://example.org/lists-of-trusted-entities/mdl-providers",
                        "isLoTE": true
                    }
                ],
                "attestationLoS": "iso_18045_high",
                "bindingType": "key",
                "supportedFormats": [
                    "mso_mdoc"
                ],
                "schemaURIs": [
                    {
                        "formatIdentifier": "mso_mdoc",
                        "uri": "https://trust-registry.example.org/schemas/mdoc/mDL#integrity=sha256-47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU="
                    }
                ]
            }
        ]
    }
}

7.6.3.2. One schema

GET /schemas/{schemaId} MUST be available without authentication. The Federation Trust Anchor MUST respond with HTTP 200 and a JWS whose payload is the matching SchemaMeta when schemaId exists. The Federation Trust Anchor MUST respond with HTTP 404 when schemaId does not exist. The JWT response MUST include x-jku-url as specified for the list.

7.6.3.3. Update and deletion

PUT /schemas/{schemaId} and DELETE /schemas/{schemaId} MUST be accepted only from an authenticated representative of the Attestation Scheme Provider that registered the schema, as required by Section 4.5.3 and Section 5.2.2 of [EUDI-TS 11]. The request body of PUT MUST be the complete SchemaMeta. A successful PUT MUST respond with HTTP 200 and the stored SchemaMeta as application/json, as specified in Annex A.3. This response is not selected by the content negotiation that applies to GET. A successful DELETE MUST respond with HTTP 204. The Federation Trust Anchor MUST respond with HTTP 401 when the caller is not authenticated. The Federation Trust Anchor MUST respond with HTTP 403 when the authenticated caller is not a representative of the Attestation Scheme Provider that registered the schema. The Federation Trust Anchor MUST respond with HTTP 404 when schemaId does not exist. Section 5.2.2 of [EUDI-TS 11] leaves the Commission authentication mechanism for a later version. Until that mechanism is defined, the Onboarding System is the representative that the Federation Trust Anchor MUST accept for these two methods.

The implementation of GET /schemas MUST take into account the vulnerabilities described in Section 5.4 of [EUDI-TS 11]. It SHOULD apply the measures in Section 5.5 and Section 5.6 of [EUDI-TS 11].

7.7. Digital Credentials Catalog

The Digital Credentials Catalog is the registry of all available Digital Credentials recognized within the IT-Wallet ecosystem. It acts as a single reference point for all actors involved in the process of issuing, verifying and using Digital Credentials. The Digital Credentials Catalog MUST contain at least:

Table 7.12 Digital Credentials Catalog - Main information

Information related to	Description
Digital Credential Metadata	Essential identifying information and characteristics of the Digital Credential, including: Credential Unique identifier: A unique identifier string of each Digital Credential. User authentication methods: User authentication mechanisms used to request the Digital Credential, if required by Issuers or Authentic Sources. Minimum Level of Assurance: The minimum Level of Assurance required for the Digital Credential's reliability. It MUST take into account the Level of Assurance of User authentication, when applicable, and Wallet Instance.
Digital Credential Issuers	Details about the organization authorized to issue the Digital Credential, such as: Issuer identifiers: Unique identifier for the Digital Credential issuer. Issuer type: Classification as PID, (Q)EAA, or Pub-EAA Provider. Additional information: Organizational details including name, code, and contact information.
Authentic Sources	Information about the authoritative data source.
Technical Specification	Technical details, including: Digital Credential schemes: Framework and structure specifications. Digital Credential formats: Data format and encoding standards. Authentication policy: Methods and requirements for verification.
Terms of Use	Conditions and limitations for Digital Credential usage, such as: Credential validity: Time period during which the Digital Credential is valid and, when applicable, mechanisms and technical details for invalidating Digital Credentials (revocation/suspension methods). Restriction policy: If applicable, rules governing the Digital Credential's use and limitations according to national regulations. It is used, for example, to specify if only specific legal type Entities, for example Pub-EAA Provider and public Wallet Solutions, are allowed to issue and obtain the Digital Credential. Pricing policy: Information related to pricing models of Digital Credential, such as free, issuance_based, verification_based. Digital Credential purposes: Information related to the allowed purposes for which the Digital Credential can be used. Each Digital Credential type can be used for multiple purposes.

The Digital Credentials Catalog MUST ensure to:

1. Facilitate Digital Credential discovery for Users.

2. Standardize the technical and functional description of Digital Credentials.

3. Enable interoperability between different Issuers and Relying Parties.

4. Simplify the integration process for Wallet Providers and Relying Parties.

5. Ensure trust in the ecosystem through verifiable and trustworthy information.

6. Provide transparency on the ecosystem of available Digital Credentials.

7.7.1. Digital Credentials Catalog Usage

As shown in Figure Registries and Catalogues of the Ecosystem and Figure Discovery on the Registry Infrastructure, the main Entities involved in the Digital Credentials Catalog are:

• Attestation Scheme Providers: The Entities that own the Attestation Rulebook of a Digital Credential and that request the registration of the corresponding versioned entry, see Attestation Scheme Provider.

• Digital Credential Issuers: They are added to the issuers field of a versioned entry as a result of the Digital Credentials they declare in their registration data.

• Relying Parties: They use the Digital Credentials Catalog to gather all the information needed about the Digital Credentials they intend to request during the presentation phase.

• Wallet Providers: They access the Digital Credentials Catalog to identify the available Digital Credentials and to retrieve all necessary information for integrating them into their Wallet Solutions.

• Users: The Users who indirectly use the Digital Credentials Catalog through their Wallet Instances to discover and request Digital Credentials.

• Authentic Sources: They are referenced by the versioned entry as its data source and they act as Attestation Scheme Provider when they own the Attestation Rulebook.

A versioned entry is not provided by a single Entity. Its fields come from different sources and they are written in different onboarding phases, as summarized in the table below. The Data Identifiers that carry this information through the onboarding, and their mapping to the fields of the entry, are defined in Registration Data Model.

Table 7.13 Provision of a Versioned Entry of the Digital Credentials Catalog

Fields	Provided by	Process
credential_type, version, credential_name_l10n_id, legal_type, domains, classes, purposes, authentication, validity_info, restriction_policy, pricing_policy, rulebookURI, bindingType, attestationLoS, trustedAuthorities	The Attestation Scheme Provider, that takes the values from the Attestation Rulebook it owns	Credential Type Registration
authentic_sources or parent_credentials	The Attestation Scheme Provider, referencing the entries of the Authentic Source Registry or an already registered Credential type	Credential Type Registration
schemaId	The Attestation Scheme Provider, through the SchemaMeta registered in the Catalogue of Attestations	Schema Provisioning
issuers	Each element derives from the Digital Credentials that a Credential Issuer declares in its registration data, with the issuance capabilities it offers for each of them	Entity Registration and Entity Update
state	Not provided. It derives from the conditions of the versioned entry	Credential Type Activation and Deactivation

The registration of the versioned entry is approved by the Supervisory Body, as described in Eligibility and Compliance Preconditions, it is written by the Onboarding System and it is published by the Federation Trust Anchor with the rest of the catalog.

Note

The scheme is the machine-readable definition of an Attestation type, that at EU level is registered in the Catalogue of Schemes and that at national level corresponds to the versioned entry of the Digital Credentials Catalog. The Credential Schema is the JSON Schema or the CBOR Schema that validates the structure of the Digital Credential, and it is registered in the Schema Registry. The Attestation Scheme Provider owns the first one and provides the second one as part of the technical specification of the Credential type.

7.7.2. Digital Credentials Catalog Retrieval

The Federation Trust Anchor MUST publish the Digital Credentials Catalog as two HTTP resources. Both resources use the content negotiation and signed representation common to all Registry Infrastructure endpoints (see Content Negotiation and Signed Representation).

The collection URL is the absolute URL published under the credential_catalog key of the Registry Discovery document. The entry URL is the collection URL with two path segments appended, the credential_type and the version of one versioned entry. A client MUST build the entry URL from that collection URL. Both path segments MUST be percent-encoded as defined in RFC 3986.

A successful response of either resource is a JWS in compact serialization. The header parameters MUST be as defined in the corresponding table. The Federation Trust Anchor MUST sign each response on its own. A write that changes one versioned entry does not require a new signature over versioned entries that the write left unchanged.

The list method and the single-entry method follow Section 5.3.1 of [EUDI-TS 11]. The response carries the national versioned entry defined in Digital Credentials Catalog Structure.

7.7.2.1. Collection

The collection endpoint MUST accept HTTP GET on the collection URL. The Federation Trust Anchor MUST respond with HTTP 200 to a valid collection request.

The request MAY include the query parameters in Query Parameters of the Digital Credentials Catalog Collection. limit and offset follow Section 5.3.1 of [EUDI-TS 11]. attestationLoS, bindingType, trustedAuthoritiesFrameworkType, trustedAuthoritiesValue and rulebookUri are the filters of that section that match a field of the national versioned entry. credential_type and state select that same entry. The collection response MUST include a versioned entry only when that entry matches every supplied filter. The Federation Trust Anchor MUST respond with HTTP 400 when the request repeats a query parameter, contains a query parameter that is not listed in Query Parameters of the Digital Credentials Catalog Collection, or contains a value that does not satisfy that parameter.

The Federation Trust Anchor MUST order matching entries by the Unicode code point order of credential_type and, for an equal credential_type, by the Unicode code point order of version. The credentials array MUST contain the matching entries in that order, starting after offset entries. The credentials array MUST contain at most limit entries. When no versioned entry matches, or when offset is greater than or equal to total, credentials MUST be an empty array. In that same case, total MUST be the number of matching entries.

A client MUST NOT treat credentials as every versioned entry of the catalog. When the client requires every matching entry, it MUST request the next page by increasing offset by limit until offset is greater than or equal to total.

Table 7.14 Query Parameters of the Digital Credentials Catalog Collection

Parameter	Description
limit	OPTIONAL. Maximum number of versioned entries returned in credentials. When absent, the value 20 applies. The value MUST be an integer from 1 to 100 inclusive.
offset	OPTIONAL. Number of matching entries to skip before this page. When absent, the value 0 applies. The value MUST be an integer greater than or equal to 0.
credential_type	OPTIONAL. Exact match on credential_type.
state	OPTIONAL. Exact match on state. The value MUST be ACTIVE or INACTIVE.
attestationLoS	OPTIONAL. Exact match on attestationLoS.
bindingType	OPTIONAL. Exact match on bindingType.
trustedAuthoritiesFrameworkType	OPTIONAL. The entry matches when at least one object of trustedAuthorities has frameworkType equal to this value.
trustedAuthoritiesValue	OPTIONAL. The entry matches when at least one object of trustedAuthorities has value equal to this value.
rulebookUri	OPTIONAL. Exact match on rulebookURI.

The following non-normative example requests the first page of active entries.

GET /.well-known/credential-catalog?state=ACTIVE&limit=20&offset=0 HTTP/1.1
Host: trust-anchor.eid-wallet.example.it
Accept: application/jwt

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

eyJhbGciOiJSUzI1NiIsImtpZCI6ImV4YW1w...

The payload of a successful collection response MUST contain the fields in First-level Fields of a Collection Response.

7.7.2.2. Entry

The entry endpoint MUST accept HTTP GET on the entry URL. The path identifies the versioned entry whose credential_type and version are the two path segments. The Federation Trust Anchor MUST respond with HTTP 200 when that pair exists. The Federation Trust Anchor MUST respond with HTTP 404 when no versioned entry has that pair.

Table 7.15 Payload of a Digital Credentials Catalog Entry Response

Field Name	Description
iss	REQUIRED. Issuer identifier. It MUST be the same value as iss in the collection response.
iat	REQUIRED. See iat in First-level Fields of a Collection Response.
localization	REQUIRED. The localization object defined for the collection response.
credential	REQUIRED. The versioned entry identified by the path. Its fields are those in First-level Fields of Each Credential Entry.

The following non-normative example requests one versioned entry. The credential member is abbreviated.

GET /.well-known/credential-catalog/mDL/1 HTTP/1.1
Host: trust-anchor.eid-wallet.example.it
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "iss": "https://trust-registry.eid-wallet.example.it",
  "iat": 1742040000,
  "localization": {
    "default_locale": "it",
    "available_locales": ["en", "it"],
    "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/credential-catalog/",
    "version": "1.0.0"
  },
  "credential": {
    "credential_type": "mDL",
    "version": "1",
    "...": "..."
  }
}

7.7.3. Digital Credentials Catalog Structure

This section defines the payload of the collection response and the fields of each versioned entry. The collection payload contains the following parameters.

Table 7.16 First-level Fields of a Collection Response

Field Name	Description
id	REQUIRED. Unique identifier of the Digital Credentials Catalog (e.g., urn:credential-catalog:it-wallet).
version	REQUIRED. The version of the Digital Credentials Catalog (e.g., 1.0.0).
last_modified	REQUIRED. The timestamp indicating when the catalog content was last updated (e.g., 2025-03-15T12:00:00Z).
iss	REQUIRED. Issuer identifier of the Digital Credentials Catalog.
iat	REQUIRED. Unix time at which this response JWT was issued, as defined in RFC 7519. last_modified records the last change of catalog content. iat records the issuance of this JWT.
localization	REQUIRED. Localization configuration object containing: default_locale: Default locale code (e.g., it). available_locales: Array of supported locale codes (e.g., ["en", "it"]). base_uri: Base URI for localization bundle retrieval (e.g., https://trust-registry.eid-wallet.example.it/.well-known/l10n/credential-catalog/). version: Version of the localization bundle format.
total	REQUIRED. Integer. Number of versioned entries that match the request, before limit and offset are applied.
limit	REQUIRED. Integer. The page size applied to this response.
offset	REQUIRED. Integer. The number of matching entries skipped before this page.
credentials	REQUIRED. Array of versioned entries in this page. The number of elements MUST be less than or equal to limit.

Each element of the credentials array contains at least the following information:

Table 7.17 First-level Fields of Each Credential Entry

Field Name	Description
version	REQUIRED. Version of the Digital Credential definition.
credential_type	REQUIRED. Unique identifier of the Digital Credential type. For PID it MUST be pid and for IT-Wallet ID MUST be eid.
schemaId	REQUIRED. UUID of the SchemaMeta in the Catalogue of Attestations for this Credential type. It MUST equal the id of that SchemaMeta.
state	REQUIRED. State of this versioned entry of the Credential type. It MUST be one of: ACTIVE: the Credential type can be issued from this versioned entry. An entry can be ACTIVE only while at least one Credential Issuer is listed in the issuers field, the referenced Authentic Source or parent Credential type is available, and the schema is registered for at least one supported format. INACTIVE: the Credential type MUST NOT be issued from this versioned entry. An entry is INACTIVE when it has just been registered, when one of the conditions for the ACTIVE state stops holding, or when it has been superseded by a more recent version. Only one versioned entry of the same credential_type MUST be ACTIVE at a given time.
credential_name_l10n_id	REQUIRED. Localization key referencing the human-readable name of the Digital Credential in the localization bundle (e.g., mDL.name).
legal_type	REQUIRED. Legal classification of the Credential (e.g., pub-eaa, qeaa, eaa). A type whose legal_type is qeaa or pub-eaa MUST follow QEAA and PuB-EAA Data Model.
restriction_policy	OPTIONAL. Legal restrictions on Wallet Solutions and/or Credential Issuers allowed to request/issue the Digital Credential. allowed_wallet_ids: List of allowed Wallet Solutions identifiers. allowed_issuer_ids: List of allowed Credential Issuers identifiers. If present, it represents a whitelist of Credential Issuers that may be added to the issuers field of the corresponding Digital Credential, as described in Credential Type Registration. presentation_flows: Type of presentation flows supported; remote and/or proximity flow.
pricing_policy	OPTIONAL. Information about Digital Credential pricing, including: models: REQUIRED. Array of pricing models applicable to the Digital Credential, each containing pricing_type: Type of pricing model, such as issuance_based, verification_based, subscription_based, other. price: Cost associated with the model. currency: Currency of the price. pricing_model_uri: URI to the detailed pricing model documentation.
validity_info	REQUIRED. Information about Digital Credential validity, including at least: max_validity_days: Maximum validity period in days. status_methods: Supported status verification methods (e.g. status_list). allowed_states: Array of objects representing allowed Digital Credential states. Each object contains a hex status code (e.g., 0x00 for VALID, 0x01 for INVALID, 0x02 for SUSPENDED, 0x03 for UPDATE, 0x0F for ATTRIBUTE_UPDATE), a title_l10n_id localization key, and a description_l10n_id localization key for UI display. administrative_expiration_user_info: OPTIONAL. Object containing title_l10n_id and description_l10n_id keys for displaying administrative expiration information to the User.
authentication	REQUIRED. Digital Credential authentication requirements. user_auth_required: REQUIRED. Flag indicating if User authentication is required during the issuance of the Digital Credential. min_loa: REQUIRED. Minimum Level of Assurance required for Digital Credential authentication. It MUST include the Level of Assurance of the User authentication and the Wallet Instance requesting the Digital Credential. supported_schemes: REQUIRED if user_auth_required is true. Supported digital identity authentication schemes (e.g., ["it_wallet"]).
domains	REQUIRED. Array of domain IDs to which Digital Credential belongs (e.g., "IDENTITY", "MOBILITY_TRAVEL").
classes	REQUIRED. Array of class IDs to which Digital Credential belongs (e.g., "IDENTIFICATION_DOCUMENTS", "LICENSES_AUTHORIZATIONS").
purposes	REQUIRED. Array of usage purpose IDs for which the Digital Credential can be used, defining specific usage contexts and required claims for each purpose (e.g., "IDENTITY_VERIFICATION", "AGE_VERIFICATION", "DRIVING_RIGHTS_VERIFICATION").
issuers	It is REQUIRED only if state is ACTIVE. Array of relevant information about authorized Credential Issuers, including administrative and technical data such as Organization name, a reference to the API specification document and supported issuance mechanisms. Each array element contains: entity_id: REQUIRED. String. Unique identifier of the Credential Issuer. It MUST match with the value contained in the iss parameter of the Credential Issuer Entity Configuration. organization_name_l10n_id: REQUIRED. String. Localization key referencing the localized organization name in the localization bundle (e.g., issuer1.name). organization_code: REQUIRED. String. Credential Issuer IPA code for government entities or VAT number for private entities. organization_country: REQUIRED. String. Two-letter ISO 3166-1 alpha-2 country code of the organization. contacts: REQUIRED. String. Array of contact email addresses for at least one user-support, one application, and one systems specialist. legal_type: REQUIRED. String. Legal classification of the Credential Issuer (e.g., pub-eaa, qeaa, eaa). homepage_uri: REQUIRED. String. URL pointing to the organization's homepage. logo_uri: OPTIONAL. String. URL to the organization's logo image. policy_uri: REQUIRED. String. URL to privacy policy document. tos_uri: OPTIONAL. String. URL to terms of service document. service_documentation_uri: OPTIONAL. String. URL pointing to the Credential Issuer service documentation. issuance_flows: REQUIRED. Object. It contains the following parameters: deferred_flow: REQUIRED. Boolean. Indicates if the deferred issuance is supported. immediate_flow: REQUIRED. Boolean. Indicates if the immediate issuance is supported. wallet_initiated: REQUIRED. Boolean. Indicates if the Wallet-Initiated flow is supported. issuer_initiated: REQUIRED. Boolean. Indicates if the Issuer-Initiated flow issuance is supported (Third Party Initiated Flow). max_deferred_issuance_time_minutes: Integer. Maximum time in minutes for the availability of the issuance of the Credential. REQUIRED if deferred_flow is true. notification_methods: String Array. Contains the notification methods supported by the Credential issuer for the deferred issuance, such as "push", "polling". REQUIRED if deferred_flow is true.
authentic_sources	It is REQUIRED only if parent_credentials is absent. Array of Authentic Source JSON objects referencing authorized Authentic Sources. Each object MUST contain the AS entity identifier and the specific data capability identifier: id: String identifier referencing the Authentic Source entity_id as registered in the Authentic Source Registry. dataset_id: String identifier of the specific data capability/dataset used by the Issuer from the AS.
parent_credentials	It is REQUIRED only if authentic_sources is absent. Array of credential_type identifier corresponding to Credentials designated as data sources. Each element identifies a Credential that acts as an Authentic Source during the Digital Credential Issuance process.
trustedAuthorities	REQUIRED. Array of JSON objects that resolve to the applicable trust anchor(s), containing: frameworkType: type of the applicable trust model. A string from the set of etsi_tl or openid_federation. value: standard URI-formatted identifier for the Trusted List (for type etsi_tl) or Entity Identifier (for type openid_federation). isLoTE: a boolean value that MUST be TRUE when the applicable trust framework type is an ETSI Trusted List (etsi_tl) but the trusted list behind the value URI is a list of trusted entities (LoTE) according to ETSI TS 119 602. Value MUST be FALSE if the applicable trusted list specification is ETSI TS 119 612. Attribute MUST NOT be used with other framework types. The applicable frameworkType is the signing trust anchor of the Credential type, as specified in Trust Framework Selection. Note Use of isLoTE will become unnecessary and must be deprecated once OpenID4VCI specifies a new enumeration for Lists of Trusted Entities according to ETSI TS 119 602, the tentative enumeration is etsi_lote.
rulebookURI	REQUIRED. URI to the human-readable Attestation Rulebook that defines all the non-machine-readable aspects of the Digital Credential type.
bindingType	REQUIRED. Indicates the type of cryptographic key binding required for issuance of the Digital Credential. Allowed value is a string from the set of: claim (binding to a cryptographic claim presented by the User), key (binding to a key possessed by the User), biometric (binding to presented biometrics of the User) or none (no cryptographic binding).
attestationLoS	REQUIRED. Level of security (LoS) the Digital Credential is to be provided at. Allowed value is a string from the set of: iso_18045_high, iso_18045_moderate, iso_18045_enhanced-basic or iso_18045_basic (see Annex D.2 of OpenID4VCI for more details).

Note

While min_loa in the claim authentication specifies the Digital Credential authentication requirements referring to the eID mean level of assurance required during user authentication in the issuance process, the claim attestationLoS complements this requirement by specifying the attack potential resistance for both user authentication and key storage.

Note

The union of credential_type and version MUST be unique in the Credential Catalog.

The following non-normative example is one page of a collection response, decoded as JSON for both the header and the payload.

{
    "typ":"JOSE",
    "alg":"ES256",
    "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d",
    "cty":"application/json"
}

{
    "id": "urn:credential-catalog:it-wallet",
    "version": "1.0.0",
    "last_modified": "2025-03-15T12:00:00Z",
    "iss": "https://trust-registry.eid-wallet.example.it",
    "iat": 1742040000,
    "total": 1,
    "limit": 20,
    "offset": 0,
    "localization": {
        "available_locales": [
            "en",
            "it"
        ],
        "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/credential-catalog",
        "default_locale": "it",
        "version": "1.0.0"
    },
    "credentials": [
        {
            "version": "1",
            "state": "ACTIVE",
            "credential_type": "mDL",
            "schemaId": "550e8400-e29b-41d4-a716-446655440000",
            "credential_name_l10n_id": "mDL.name",
            "legal_type": "pub-eaa",
            "restriction_policy": {
                "allowed_wallet_ids": [
                    "https://wallet-provider.example.org/wallet_solution",
                    "https://wallet-provider2.example.org/wallet_solution"
                ],
                "allowed_issuer_ids": [
                    "https://issuer.example.org"
                ],
                "presentation_flows": {
                    "remote": true,
                    "proximity": true
                }
            },
            "pricing_policy": {
                "models": [
                    {
                        "pricing_type": "verification_based",
                        "price": 0.01,
                        "currency": "EUR"
                    }
                ],
                "pricing_model_uri": "https://example.com/pricing"
            },
            "validity_info": {
                "max_validity_days": 365,
                "status_methods": [
                    "status_list"
                ],
                "administrative_expiration_user_info": {                  
                    "title_l10n_id": "mDL.administrative_expiration_user_info.title",
                    "description_l10n_id": "mDL.administrative_expiration_user_info.description"
                },
                "allowed_states": [
                    {
                    "0x00": "VALID",
                    "title_l10n_id": "mDL.VALID.title",
                    "description_l10n_id": "mDL.VALID.description"
                    },
                    {
                    "0x01": "INVALID",
                    "title_l10n_id": "mDL.INVALID.title",
                    "description_l10n_id": "mDL.INVALID.description"
                    },
                    {
                    "0x02": "SUSPENDED",
                    "title_l10n_id": "mDL.SUSPENDED.title",
                    "description_l10n_id": "mDL.SUSPENDED.description"
                    },
                    {
                    "0x03": "UPDATE",
                    "title_l10n_id": "mDL.UPDATE.title",
                    "description_l10n_id": "mDL.UPDATE.description"
                    },
                    {
                    "0x0F": "ATTRIBUTE_UPDATE",
                    "title_l10n_id": "mDL.ATTRIBUTE_UPDATE.title",
                    "description_l10n_id": "mDL.ATTRIBUTE_UPDATE.description"
                    }
                ]
            },
            "authentication": {
                "user_auth_required": true,
                "min_loa": "high",
                "supported_schemes": [
                    "it_wallet"
                ]
            },
            "domains": ["IDENTITY", "MOBILITY_TRAVEL"],
            "classes": ["IDENTIFICATION_DOCUMENTS", "LICENSES_AUTHORIZATIONS"],
            "purposes": ["IDENTITY_VERIFICATION", "AGE_VERIFICATION", "DRIVING_RIGHTS"],
            "issuers": [
                {
                    "entity_id": "https://issuer.example.org",
                    "organization_name_l10n_id": "mDL.issuer1.name",
                    "organization_code": "ci_example_it",
                    "organization_country": "IT",
                    "contacts": [
                        "mailto:informazioni@example.it",
                        "mailto:protocollo@pec.example.it"
                    ],
                    "legal_type": "pub-eaa",
                    "homepage_uri": "https://issuer.example.org",
                    "logo_uri": "https://issuer.example.org/logo.svg",
                    "policy_uri": "https://issuer.example.org/privacy",
                    "tos_uri": "https://issuer.example.org/terms",
                    "service_documentation_uri": "https://issuer.example.org/.well-known/service-doc",
                    "issuance_flows": {
                        "wallet_initiated": true,
                        "issuer_initiated": true,
                        "immediate_flow": false,
                        "deferred_flow": true,
                        "max_deferred_issuance_time_minutes": 1440,
                        "notification_methods": [
                            "push",
                            "polling"
                        ]
                    }
                }
            ],
            "authentic_sources": [
                {
                    "id": "https://motorizzazione.gov.example",
                    "dataset_id": "38832801"
                }
            ],
            "trustedAuthorities": [
                {
                    "frameworkType": "etsi_tl",
                    "value": "https://eidas.ec.europa.eu/efda/wallet/lists-of-trusted-entities/mdl-providers",
                    "isLoTE": true
                }
            ],
            "rulebookURI": "https://github.com/eu-digital-identity-wallet/eudi-doc-attestation-rulebooks-catalog/tree/main/rulebooks/mdl",
            "bindingType": "key",
            "attestationLoS": "iso_18045_high"
        }
    ]
}

Note

For a better and more efficient management of the localization of the information contained in the Digital Credentials Catalog, an Entity consulting it SHOULD:

• Request the collection pages it needs, or one versioned entry, as specified in Digital Credentials Catalog Retrieval.

• Determine the User's preferred language.

• Download only the necessary localization bundles.

• Dynamically merge localised content with the catalog entry.

A non-normative example of a localization bundle output is given below:

{
  "mDL.name": "Patente di Guida",
  "mDL.issuer1.name": "Esempio di Credential Issuer",
  "...": "..."
}

Localization bundles MUST be available at the URI composed by appending the locale code and .json to the localization.base_uri value defined in the catalog. Each locale bundle MUST be accessible following the naming pattern {locale_code}.json, where {locale_code} is replaced with the corresponding locale code from the available_locales array.

A non-normative example of the Italian localization URI for the bundle would be https://trust-registry.eid-wallet.example.it/.well-known/l10n/credential-catalog/it.json.

7.7.4. Decentralization of Display and Claim Information

The canonical source for display characteristics and claim structure is determined by the Credential Issuer's Metadata.

The overall logic for presenting a Digital Credential is the following:

1. Depending on the required Trust Framework, the Wallet or Relying Party retrieves the applicable versioned entries from the Digital Credentials Catalog, for both Digital Credentials managed by Credential Issuers anchored in the National or EUDIW Trust Framework, to discover the available credential_type and the entity_id of their Credential Issuers. Retrieval uses the collection or the entry endpoint specified in Digital Credentials Catalog Retrieval.

2. It retrieves the full Credential Issuer Metadata (see Metadata for openid_credential_issuer) as described in Section 12.2.2 of OpenID4VCI.

3. The Credential Issuer Metadata MUST contain the full display characteristics (logos, colors) and the detailed schema information (via links to the appropriate Type Metadata or directly in the configuration). The Issuer builds this metadata based on the suggestions provided by the Authentic Source (via the AS Registry) and the standard schema specifications (via the Schema Registry).

7.8. Registry Integration and Cross-References

As shown in Figure Relationships between National Registries, the registry components are interconnected and work together to support the complete Credential ecosystem:

1. AS Registry ↔ Taxonomy: Authentic Sources declare capabilities using taxonomy classifications for standardized categorization.

2. AS Registry ↔ Claims Registry: Authentic Sources declare capabilities on available claims using the Claim Registry.

3. AS Registry ↔ DC Catalog: Credential types reference AS capabilities for data source validation.

4. DC Catalog ↔ Taxonomy: Credential entries specify domains and purposes from the taxonomy for discovery and authorization.

5. Schema Registry ↔ DC Catalog: Credential types reference to the Schema Registry for data discovery and validation.

Fig. 7.3 Relationships between National Registries

Figure Relationships between National Registries and EUDIW Catalogues shows instead the mapping between the EUDIW catalogues and the national counterparts:

• EUDIW Catalogue of Attributes corresponds to the national Claims Registry for the semantic definition of the attributes and to the Authentic Source Registry for the discovery of the verification point. Note that national attribute definitions align to the EU-level catalogue for cross-border interoperability.

• EUDIW Catalogue of Schemes corresponds to the national Catalogue of Attestations (Catalogue of Attestations), which implements Section 5 of [EUDI-TS 11], and to the Digital Credentials Catalog for the national issuance and presentation requirements. The national catalog keeps the additional information, such as the pricing model and the validity information.

Fig. 7.4 Relationships between National Registries and EUDIW Catalogues

Note

As specified in EIDAS-ARF, the registration of an attestation scheme in the EUDIW Catalogue of Schemes does not create any obligation for acceptance of the relevant type of attestation by any actor in the EUDI Wallet ecosystem. Neither does it automatically imply cross-border recognition of the type of attestation. It is used to discover the corresponding trust framework.

7.9. Registry Infrastructure Usage Journeys

The components of the Registry Infrastructure are designed to support various operational phases of the IT-Wallet ecosystem, each involving specific interactions between entities. The main Journeys below illustrate the operational interactions that read the Registry Infrastructure. The complementary journey that populates the registries is the onboarding registration, which registers the entities, the Authentic Sources, the claims, the schemas and the Credential types, as shown in Figure Registries and Catalogues of the Ecosystem and described in Onboarding Processes.

7.9.1. Catalog Browsing

This Catalog Browsing journey supports Users (both human users via a Wallet Instance and automated systems like Relying Parties or web portals) in discovering and selecting available Digital Credentials.

1. Accessing the Discovery Endpoint: The entity (e.g., a Wallet Provider or informational portal) accesses the Registry Discovery Endpoint (.well-known/it-wallet-registry) to obtain the URI of the Digital Credentials Catalog and of the Taxonomy.

2. Navigation and Selection:

   • Credential Discovery: The entity requests one or more pages of the collection endpoint (Digital Credentials Catalog Retrieval) and reads the credentials array of each page to identify relevant Credential types (e.g., pid, eid, mDL). If needed, it uses the information on the Taxonomy to navigate their hierarchy and to provide different localizations.

   • Issuer Metadata: The entity extracts the Credential Issuer Metadata (see Metadata for openid_credential_issuer) as described in Section 12.2.2 of OpenID4VCI.

   • Detail Consultation: To obtain complete information and specific technical requirements, the entity accesses the Entity Configuration using the retrieved identifier.

3. Final Action: The entity can then use the metadata to display the catalog information to a User, or use it in other ways.

7.9.2. Credential Issuance

This journey defines how a Credential Issuer uses the Registry Infrastructure to prepare and issue a compliant Digital Credential.

1. Identifying Requirements: The Credential Issuer retrieves the versioned entry of the Credential type from the entry endpoint of the Digital Credentials Catalog (Digital Credentials Catalog Retrieval) and reads the technical requirements of that entry (e.g., max_validity_days, min_loa).

2. Schema and Claim Resolution:

The Credential Issuer consults:

• EUDIW Catalogue of Schemes to obtain the SchemaMeta of the sought EUDIW-anchored Digital Credential, or

• Catalogue of Attestations to obtain the SchemaMeta of the sought national Digital Credential through GET /schemas/{schemaId}.

The Credential Issuer verifies the #integrity suffix of each schemaURIs[].uri when that suffix is present. Then, depending on the Trust Framework anchoring the Digital Credential, it accesses the Catalogue of Attributes or Claims Registry to retrieve the standardized semantic definitions and data formats of the necessary attributes (claims).

3. Authentic Data Retrieval:

• The Credential Issuer consults the Authentic Source (AS) Registry to identify the authorized Authentic Source (AS) for the required dataset. The AS Registry provides the AS's entity_id and the technical details of the interface (integration_endpoint, integration_method).

• The Credential Issuer consults the AS endpoint specification to implement the integration needed to retrieve the User data required to populate the Digital Credential.

4. Credential Issuance: The Credential Issuer uses the retrieved data, validated schemas, and specified formats to generate and sign the Digital Credential in the correct format (e.g., SD-JWT or mDOC).

7.9.3. Credential Presentation and Verification

This journey describes how a Wallet Instance and a Relying Party (RP) interact with the Registry Infrastructure when a Digital Credential needs to be presented by a User.

1. Wallet Unit Authorization and Selection:

• The Wallet Unit receives a Presentation Request from the RP. The Wallet Unit MUST evaluate trust with the RP issuing the Presentation Request as follows:

  • (EUDIW Trust Framework):

    • The Wallet Unit validates the Presentation Request signature and evaluates trust with the Relying Party producing it as described in EUDIW Authentication.

    • The Wallet Unit validates whether the RP is entitled to this presentation as described in EUDIW Authorization.

  • (National Trust Framework):

    • The Wallet Unit validates the Presentation Request signature and evaluates trust with the Relying Party producing it as described in Authentication.

    • The Wallet Unit validates whether the RP is entitled to this presentation as described in Authorization.

Regardless of the Trust Framework, the final decision on whether the RP is Authorized during presentation is made according to Authorization Decision and Override Rules.

• The User authorizes the release of the selected, selectively disclosed attributes. The Wallet then packages and presents the Digital Credential to the RP.

2. Discovery and Integrity:

• The RP receives the Digital Credential from the User.

• Depending on the trust framework the RP subscribes to (i.e., the National or EUDIW Trust Framework):

  • (EUDIW Trust Framework):

    • The RP validates the Digital Credential signature and evaluates trust with its issuer as described in EUDIW Attestation Signature Validation.

    • The RP consults the EUDIW Catalogue of Schemes and retrieves the SchemaMeta of the presented Credential, verifying each schemaURIs[].uri that carries an #integrity suffix as defined in [W3C-SRI].

  • (National Trust Framework):

    • The RP validates the Digital Credential signature and evaluates trust with its issuer as described in Signing Trust Anchor Validation Procedure.

    • The RP retrieves the SchemaMeta from GET /schemas/{schemaId} on the Catalogue of Attestations, using the schemaId of the catalog entry, and verifies each schemaURIs[].uri that carries an #integrity suffix as defined in [W3C-SRI].

3. Schema and Final Policy Validation:

• The RP uses the retrieved schema to validate the structure of the Credential and the data types of the revealed attributes.

• The RP performs the final check to ensure that the attributes presented comply with the specific requirements of the initial request and authorization policy.

4. Acceptance or Rejection: Based on cryptographic validation, schema compliance, and policy-based authorization, the RP accepts or rejects the Digital Credential for service access.

7.9.4. Cross-border Attribute Verification by a QTSP

This journey describes how a Qualified Trust Service Provider (QTSP), possibly established in another Member State, verifies the value of an Annex VI attribute against an Italian public-sector Authentic Source to issue a QEAA. It uses the verification_endpoint of the Authentic Source Registry, which is the national counterpart of the verification-point discovery in the EUDIW Catalogue of Attributes. It does not use the national OpenID Federation trust evaluation nor the domestic PDND e-Service.

1. Verification-point discovery: The QTSP discovers the verification point from data_capabilities[].verification_endpoint in the Authentic Source Registry. endpoint is the verification point. The EUDIW Catalogue of Attributes is the cross-border counterpart of this discovery, as described in Registry Integration and Cross-References. The Federation Trust Anchor does not publish that catalogue.

2. Interface selection: Depending on verification_endpoint.method, the QTSP uses the ISO 15000/eDelivery interface (oots_edelivery) or the REST + OAuth 2.0 interface (rest_oauth2) of ETSI TS 119 478 Section 6.

3. Verification request: The QTSP submits the verification request to the endpoint, exposed by the Authentic Source or by the designated national intermediary, which returns the authentic confirmation of the attribute value for the User. As foreseen by Article 45e of [EIDAS], this is an authenticity verification of the attribute and not an access to the underlying data.

4. Issuance: The QTSP issues the QEAA under its own Rulebook and trust anchors, that is the EUDIW Trusted Lists. The trust anchoring of the resulting QEAA does not derive from the presence of any scheme in the Catalogue of Schemes, see the note in Registry Integration and Cross-References.