7. Registry Infrastructure¶

The IT-Wallet ecosystem operates through a registry infrastructure that provides standardized data definitions, entity registration, 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 credential presentation.

The registry architecture addresses semantic standardization, federation trust management, and credential discovery requirements through specialized registry components that ensure interoperability and compliance across the ecosystem.

7.1. Registry Architecture Overview¶

The IT-Wallet registry system comprises six main components:

Claims Registry: Standardized semantic definitions for individual credential attributes, data types, and validation rules.
Authentic Source (AS) Registry: Catalog of registered data providers with their declared capabilities and available claims.
Federation Registry: Authoritative list of trusted entities participating in the federation with their technical configurations.
Digital Credentials Catalog: Public discovery mechanism for available credential types with their metadata and issuance information.
Schema Registry: Authoritative list of Credential Schemas.
Taxonomy: Hierarchical classification system organizing credentials by domain and purpose.

These registry components are interconnected and maintained by the Supervisory Body to ensure consistency, security, and regulatory compliance across the ecosystem.

7.2. Registry Discovery Endpoint¶

The Trust Anchor MUST provide a discovery mechanism for all registry components through standardized well-known endpoints providing metadata and REST API discovery information to handle complex operations like pagination and filtering.

The Trust Anchor MUST publish registry discovery metadata at the .well-known/it-wallet-registry endpoint with content negotiation support:

Default Content-Type: application/jwt (signed JWT ensuring authenticity and integrity)
Alternative Content-Type: application/json (plain JSON for development/debugging purposes)

Moreover, the IT-Wallet registry system MUST use two distinct access patterns:

Data Registry APIs: MUST support pagination and filtering capabilities.
Federation Trust Infrastructure: as defined in The Infrastructure of Trust.

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

JWT payload structure (when decoded):

{
  "registry_version": "1.0",
  "last_updated": "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/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",
    "federation_list": "https://trust-anchor.eid-wallet.example.it/list",
    "federation_fetch": "https://trust-anchor.eid-wallet.example.it/fetch",
    "federation_resolve": "https://trust-anchor.eid-wallet.example.it/resolve",
    "federation_trust_mark_status": "https://trust-anchor.eid-wallet.example.it/trust_mark_status",
    "federation_historical_keys": "https://trust-anchor.eid-wallet.example.it/historical-jwks"
  },
  "content_negotiation": ["application/json", "application/jwt"]
}

7.3. Claims Registry¶

The Claims Registry provides standardized semantic definitions for individual Credential attributes, data types, and validation rules. This registry serves as the semantic foundation for credential attribute standardization across the IT-Wallet ecosystem, working in coordination with the Taxonomy component for hierarchical classification.

The Supervisory Body MUST maintain the Claims Registry to ensure semantic consistency and regulatory compliance across the ecosystem. The 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.3.1. Claims Registry Usage¶

The Claims Registry MUST support the complete ecosystem lifecycle:

During Onboarding Process:

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

CI Registration: Credential Issuers select AS entities based on required claims and register credential types for catalog publication.

RP Registration: Relying Parties specify authorization requirements using domains/purposes for specific credential types and/or User's attributes.

During Operational Activities:

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

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

Policy Enforcement: Authorization policies leverage domain/purpose classifications for access control.

7.3.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 through the Digital Credentials Catalog localization bundles, enabling efficient multilingual support without compromising the registry's structural integrity.

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

{
    "registry_version": "1.0",
    "claims": {
        "given_name": {
            "type": "string",
            "description": "Person's given name(s) as appears on official documents",
            "aliases": ["first_name", "forename", "given_names"],
            "max_length": 100,
            "validation": {
                "pattern": "^[\\p{L}\\s\\-\\'\\.']+$",
                "min_length": 1
            }
        },
        "family_name": {
            "type": "string",
            "description": "Person's family name as appears on official documents",
            "aliases": ["last_name", "surname", "family_names"],
            "max_length": 100,
            "validation": {
                "pattern": "^[\\p{L}\\s\\-\\'\\.']+$",
                "min_length": 1
            }
        },
        "birth_date": {
            "type": "date",
            "description": "Date of birth in ISO 8601 format",
            "format": "YYYY-MM-DD",
            "validation": {
                "min_date": "1900-01-01",
                "max_date": "current_date"
            }
        },
        "birth_place": {
            "type": "string",
            "description": "Place of birth as registered in official records",
            "aliases": ["place_of_birth"],
            "max_length": 100
        },
        "tax_code": {
            "type": "string",
            "description": "Italian fiscal identification code (Codice Fiscale)",
            "validation": {
                "pattern": "^[A-Z]{6}[0-9]{2}[A-Z][0-9]{2}[A-Z][0-9]{3}[A-Z]$",
                "length": 16
            }
        },
        "personal_administrative_number": {
            "type": "string",
            "description": "ANPR unique person identifier",
            "validation": {
                "pattern": "^[A-Z0-9]+$"
            }
        },
        "document_number": {
            "type": "string",
            "description": "Document serial number or identifier",
            "validation": {
                "pattern": "^[A-Z0-9]+$",
                "max_length": 20
            }
        },
        "issue_date": {
            "type": "date",
            "description": "Document issue date",
            "format": "YYYY-MM-DD",
            "validation": {
                "max_date": "current_date"
            }
        },
        "expiry_date": {
            "type": "date",
            "description": "Document expiry date",
            "format": "YYYY-MM-DD",
            "validation": {
                "min_date": "current_date"
            }
        },
        "driving_privileges": {
            "type": "array",
            "description": "Array of authorized vehicle categories with details",
            "items": {
                "type": "object",
                "properties": {
                    "vehicle_category_code": {
                        "type": "string",
                        "enum": ["AM", "A1", "A2", "A", "B", "BE", "C", "CE", "D", "DE"]
                    },
                    "issue_date": {"type": "date", "format": "YYYY-MM-DD"},
                    "expiry_date": {"type": "date", "format": "YYYY-MM-DD"},
                    "restrictions": {"type": "string", "description": "Category-specific restrictions"}
                }
            }
        },
        "portrait": {
            "type": "string",
            "format": "binary",
            "description": "Person's photograph as binary string (JPEG or JPEG2000)",
            "encoding": "base64",
            "content_type": ["image/jpeg", "image/jp2"],
            "validation": {
                "max_size_bytes": 50000,
                "min_width": 100,
                "min_height": 100
            }
        },
        "issuing_authority": {
            "type": "string",
            "description": "Authority that issued the document",
            "max_length": 100
        },
        "issuing_country": {
            "type": "string",
            "description": "Country code that issued the document",
            "validation": {
                "pattern": "^[A-Z]{2}$",
                "length": 2
            }
        }
    }
}

7.4. Authentic Source Registry¶

The Supervisory Body MUST maintain the Authentic Source Registry to enable coordinated data access and credential issuance across the ecosystem. The AS 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 for public AS, custom APIs for private AS).

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

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

The AS Registry MUST ensure:

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

AS-CI Integration: Facilitates approval workflows and data access coordination between entities.

Quality Assurance: Maintains authoritative status and data reliability across different domains.

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

Note

Authentic Source Registry is a technical and non-public registry that provides guidance for the Credential Issuer for Credential provisioning.

7.4.1. Authentic Source Registry Usage¶

The AS Registry supports ecosystem coordination throughout the operational lifecycle:

During Onboarding Process:

AS Self-Declaration: Authentic Sources register capabilities before any credential types exist in the catalog.
CI Discovery: Credential Issuers search for AS entities based on required claims and intended credential types.
Approval Coordination: AS entities evaluate and approve CI access requests for data provision.

During Operational Activities:

Data Source Resolution: CI systems reference AS Registry for real-time data access during credential issuance.
Quality Validation: AS Registry information supports data origin verification and audit requirements.
Integration Management: Technical endpoints and access methods enable standardized AS-CI communication.

7.4.2. Public vs Private AS Coordination¶

The AS Registry architecture supports different coordination patterns reflecting distinct operational requirements:

Public Administration AS (Standardized Integration): Government entities provide authoritative data through regulated mechanisms:

PDND Integration: "integration_method": "pdnd_eservice" for standardized government data access.

Regulatory Compliance: Full transparency requirements with public catalog publication.

Audit Requirements: Complete traceability for government credential issuance processes.

Private Sector AS (Flexible Integration): Private entities provide specialized data through custom arrangements:

Custom APIs: "integration_method": "custom_api" for business-specific data access patterns.

Selective Disclosure: Limited public visibility with CI-specific approval workflows.

Business Flexibility: Tailored integration supporting diverse private sector use cases.

This approach enables both regulatory transparency for public administration and business flexibility for private sector entities while maintaining coordinated data access across the ecosystem.

7.4.3. AS 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.4.3.1. AS 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:

HTTPS Protocol: MUST use HTTPS scheme for security and trust verification
Domain Ownership: Organization MUST control the DNS domain used in the identifier
Uniqueness: Guaranteed through DNS namespace uniqueness
Stability: SHOULD remain stable over time to avoid reference breakage
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.4.3.2. Authentic Source Registry Parameters¶

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

Table 7.1 First-level Fields of the Authentic Source Registry¶
Field Name	Description
version	REQUIRED. The version of the Authentic Source Registry (e.g., `1.0`).
last_modified	REQUIRED. The timestamp indicating when the list was last updated (e.g., `2025-03-15T12:00:00Z`).
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.2 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	string	REQUIRED. Legal name of the organization.
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 technical/administrative contact email addresses.
organization_info.policy_uri	string	REQUIRED. URL to privacy policy document.
organization_info.tos_uri	string	REQUIRED only for Private AS. 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	CONDITIONAL. 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_uri_extended	string	OPTIONAL. URL to the organization's extended logo image.
organization_info.logo_uri_extended#integrity	string	CONDITIONAL. Cryptographic digest of the extended logo image resource for integrity verification. REQUIRED if `logo_uri_extended` is present. Format: `{digest_method}-{digest_value}` (e.g., `"sha-256-abc123..."`).
data_capabilities	JSON Objects Array	REQUIRED. Array containing data capability specifications.
data_capabilities[].dataset_id	string	REQUIRED. The unique identifier of the dataset within the scope of the Authentic Source, which MAY be used as a query parameter for the `GetAttributeClaims` service.
data_capabilities[].data_origin	string	OPTIONAL. Human-readable name of the specific data origin or department providing the data.
data_capabilities[].domains	String Array	REQUIRED. Taxonomy domain (e.g., `["AUTHORIZATION"]`, `["FINANCIAL"]`).
data_capabilities[].intended_purposes	String Array	REQUIRED. Business purposes served (e.g., `["driving-authorization", "identity-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"` for Public AS. Private AS MAY use other authorization frameworks such as: `"oauth2"`, `"api_key"`, `"mtls"`, etc.
data_capabilities[].integration_endpoint	string	REQUIRED. Service access point (PDND endpoint for Public AS, API endpoint for Private AS).
data_capabilities[].api_specification	string	REQUIRED. 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	CONDITIONAL. 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	CONDITIONAL. 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	string	OPTIONAL. A string containing human-readable information about the Digital Credential relevant to the User. This string MUST be provided by the Authentic Source to the Trust Anchor during onboarding and MUST be formatted using Markdown format as defined in RFC 7763. The Markdown formatting can be plain text or a combination of text and links. For example, if the Authentic Source's database only contains the data required for Digital Credential attributes registered after a specific date, this information MUST be conveyed to the Trust Anchor in this Markdown string.
data_capabilities[].service_documentation	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	CONDITIONAL. 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[].background_image	JSON object	OPTIONAL. Object containing information about the background image to be displayed together with the data. The object contains `uri` and `uri#integrity` parameters.
data_capabilities[].watermark_image	JSON object	OPTIONAL. Object containing information about the watermark image to be displayed together with the data. The object contains `uri` and `uri#integrity` parameters.
data_capabilities[].background_color	string	OPTIONAL. String value of the background color related to be displayed together with the data.
data_capabilities[].contacts	String Array	OPTIONAL. Array of customer service contact email addresses.

7.4.3.3. AS Registry Example¶

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

{
    "version": "1.0",
    "last_modified": "2025-03-15T12:00:00Z",
    "authentic_sources": [
        {
            "entity_id": "https://motorizzazione.gov.example",
            "organization_info": {
                "organization_name_l10n_id": "authentic_source1.name",
                "organization_type": "public",
                "ipa_code": "m_inf",
                "legal_identifier": "80192770587",
                "organization_country": "IT",
                "homepage_uri": "https://www.gov.example/transport",
                "policy_uri": "https://www.gov.example/transport/privacy-policy",
                "logo_uri": "https://trust-registry.it-wallet.example.it/logos/{ipa_code}/image.svg",
                "logo_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
                "logo_extended_uri": "https://trust-registry.it-wallet.example.it/logos/{ipa_code}/extended-image.svg",
                "logo_extended_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3",
                "contacts": [
                    "registry@gov.example",
                    "technical-support@gov.example"
                ]
            },
            "data_capabilities": [
                {
                    "dataset_id": "38832801",
                    "data_origin_l10n_id": "authentic_source1.dataset1.origin",
                    "domains": [
                        "IDENTITY",
                        "AUTHORIZATION"
                    ],
                    "intended_purposes": [
                        "DRIVING_LICENSE",
                        "PERSON_IDENTIFICATION"
                    ],
                    "available_claims": [
                        {
                            "claim_name": "given_name",
                            "order": 1,
                            "mandatory": true
                        },
                        {
                            "claim_name": "family_name",
                            "order": 2,
                            "mandatory": true
                        },
                        {
                            "claim_name": "birth_date",
                            "order": 3,
                            "mandatory": true
                        },
                        {
                            "claim_name": "birth_place",
                            "order": 4,
                            "mandatory": false
                        },
                        {
                            "claim_name": "document_number",
                            "order": 5,
                            "mandatory": true
                        },
                        {
                            "claim_name": "issue_date",
                            "order": 6,
                            "mandatory": true
                        },
                        {
                            "claim_name": "expiry_date",
                            "order": 7,
                            "mandatory": true
                        },
                        {
                            "claim_name": "driving_privileges",
                            "order": 8,
                            "mandatory": true
                        },
                        {
                            "claim_name": "portrait",
                            "order": 9,
                            "mandatory": false
                        },
                        {
                            "claim_name": "un_distinguishing_sign",
                            "order": 10,
                            "mandatory": false
                        },
                        {
                            "claim_name": "document_iss_country",
                            "order": 11,
                            "mandatory": true
                        },
                        {
                            "claim_name": "document_iss_authority",
                            "order": 12,
                            "mandatory": true
                        }
                    ],
                    "integration_method": "pdnd",
                    "integration_endpoint": "https://api.gov.example/transport/driving-license",
                    "api_specification": "https://docs.gov.example/transport/api-oas3.yaml",
                    "data_provision": {
                        "immediate_flow": true,
                        "deferred_flow": false
                    },
                    "user_information_l10n_id": "authentic_source1.dataset1.userinfo",
                    "service_documentation": "https://docs.gov.example/transport/api-docs",
                    "update_frequency": "real_time",
                    "logo_uri": "https://trust-registry.it-wallet.example.it/logos/{dataset_id}/image.svg",
                    "logo_uri#integrity": "sha-256-b1946ac92492d2347c6235b4d2611184e2a3f8b8c8f8f8e8f8f8f8f8f8f8f8f8",
                    "contacts": [
                    "citizen-support@gov.example"
                    ],
                    "background_image": {
                                "uri": "https://trust-registry.it-wallet.example.it/images/{dataset_id}/image.svg",
                                "uri#integrity": "3GGZJH7igkyeprXI9Plm3dQsWMYOeuz0MaEK34PC7sOtLfgeoK9scXOvMeiACF8Tk2WOT36NsYCPduoLyOD1Sg=="
                    },
                    "watermark_image": {
                                "uri": "https://trust-registry.it-wallet.example.it/images/{dataset_id}/imag-watermark.svg",
                                "uri#integrity": "3GGZJH7igkyeprXI9Plm3dQsWMYOeuz0MaEK34PC7sOtLfgeoK9scXOvMeiACF8Tk2WOT36NsYCPduoLyOD1Sg=="
                    },
                    "background_color" : "#12107c"
                }
            ]
        },
        {
            "entity_id": "https://api.bank.example/auth-source",
            "organization_info": {
                "organization_name_l10n_id": "authentic_source2.name",
                "organization_type": "private",
                "legal_identifier": "12345678901",
                "homepage_uri": "https://www.bank.example",
                "contacts": [
                    "digital-credentials@bank.example",
                    "api-support@bank.example"
                ],
                "policy_uri": "https://www.bank.example/privacy-policy",
                "tos_uri": "https://www.bank.example/terms-of-service",
                "organization_country": "IT",
                "logo_uri": "https://trust-registry.it-wallet.example.it/logos/{legal_identifier}/image.svg",
                "logo_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"
            },
            "data_capabilities": [
                {
                    "dataset_id": "38854801",
                    "data_origin_l10n_id": "authentic_source2.dataset1.origin",
                    "domains": [
                        "FINANCIAL"
                    ],
                    "intended_purposes": [
                        "BANK_ACCOUNT",
                        "INCOME_CERTIFICATE"
                    ],
                    "available_claims": [
                        {
                            "claim_name": "given_name",
                            "order": 1,
                            "mandatory": true
                        },
                        {
                            "claim_name": "family_name",
                            "order": 2,
                            "mandatory": true
                        },
                        {
                            "claim_name": "birth_date",
                            "order": 3,
                            "mandatory": false
                        },
                        {
                            "claim_name": "tax_code",
                            "order": 4,
                            "mandatory": true
                        },
                        {
                            "claim_name": "account_holder_name",
                            "order": 5,
                            "mandatory": true
                        },
                        {
                            "claim_name": "iban",
                            "order": 6,
                            "mandatory": true
                        },
                        {
                            "claim_name": "account_status",
                            "order": 7,
                            "mandatory": false
                        },
                        {
                            "claim_name": "account_opening_date",
                            "order": 8,
                            "mandatory": false
                        },
                        {
                            "claim_name": "bank_name",
                            "order": 9,
                            "mandatory": true
                        },
                        {
                            "claim_name": "bank_code",
                            "order": 10,
                            "mandatory": true
                        }
                    ],
                    "integration_method": "oauth2",
                    "integration_endpoint": "https://api.bank.example/psd2/v1/accounts",
                    "api_specification": "https://api.bank.example/docs/psd2-openapi.yaml",
                    "data_provision": {
                        "immediate_flow": true,
                        "deferred_flow": false
                    },
                    "user_information_l10n_id": "authentic_source2.dataset1.userinfo",
                    "update_frequency": "daily"
                },
                {
                    "dataset_id": "38854802",
                    "data_origin_l10n_id": "authentic_source2.dataset2.origin",
                    "domains": [
                        "FINANCIAL"
                    ],
                    "intended_purposes": [
                        "PAYMENT_HISTORY"
                    ],
                    "available_claims": [
                        {
                            "claim_name": "given_name",
                            "order": 1,
                            "mandatory": true
                        },
                        {
                            "claim_name": "family_name",
                            "order": 2,
                            "mandatory": true
                        },
                        {
                            "claim_name": "tax_code",
                            "order": 3,
                            "mandatory": true
                        },
                        {
                            "claim_name": "transaction_history",
                            "order": 4,
                            "mandatory": true
                        },
                        {
                            "claim_name": "average_balance",
                            "order": 5,
                            "mandatory": false
                        },
                        {
                            "claim_name": "credit_score_indicator",
                            "order": 6,
                            "mandatory": false
                        }
                    ],
                    "integration_method": "oauth2",
                    "integration_endpoint": "https://api.bank.example/psd2/v1/transactions",
                    "api_specification": "https://api.bank.example/docs/psd2-openapi.yaml",
                    "data_provision": {
                        "immediate_flow": false,
                        "deferred_flow": true,
                        "max_response_time_minutes": 1440,
                        "notification_methods": [
                            "push",
                            "poll"
                        ]
                    },
                    "user_information_l10n_id": "authentic_source2.dataset2.userinfo",
                    "service_documentation": "https://docs.bank.example/psd2-api",
                    "update_frequency": "weekly"
                }
            ]
        }
    ]
}

Note

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

Download the basic version of the Digital Credentials Catalog (compact, without localisations) using the .well-known/authentic-sources endpoint.

Determine the User's preferred language.

Download only the necessary localisation bundles.

Dynamically merge localised content with the Digital Credentials Catalog structure.

A non-normative example of a localisation 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": "Example Bank S.p.A.",
  "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 specified in the localization_info.bundles_base_uri claim of the Digital Credentials 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/authentic-sources/it.json.

Entities SHOULD verify the integrity of downloaded localization bundles using the digest method and values specified in the localization_info.integrity claim. This ensures that the localization data has not been tampered with during transmission.

7.4.4. AS-CI Coordination¶

Following AS registration, the AS Registry enables Credential Issuers to discover suitable AS entities and request integration approval. This coordination process is detailed in Authentic Source to Credential Issuer Authorization Process.

7.5. Federation Registry¶

The Federation Registry provides the cryptographic trust infrastructure for all IT-Wallet ecosystem participants. The Federation Registry maintains the authoritative list of trusted entities and their operational status using federation-specific endpoints as defined in Federation API endpoints.

7.5.1. Registry Integration Role¶

Within the IT-Wallet registry architecture, the Federation Registry serves as the trust validation layer for:

Entity Authentication: Validates the cryptographic identity of all participants before registry operations
Trust Chain Verification: Provides the cryptographic foundation for Credential Issuers, Relying Parties, and Wallet Providers entity validation
Compliance Verification: Maintains Trust Marks that attest regulatory compliance and operational status

7.5.2. Federation Registry Access¶

Federation Registry operations are accessed through the Trust Anchor's federation endpoints as detailed in Federation API endpoints. The registry discovery architecture provides federation endpoint information via the registry discovery endpoint described in Registry Discovery Endpoint.

Note

Federation endpoints are available through both the registry discovery mechanism (for unified registry access) and the Trust Anchor's Entity Configuration at .well-known/openid-federation (for federation-specific operations). Both sources provide the same endpoint URLs but serve different discovery patterns: registry discovery for initial ecosystem orientation, Entity Configuration for standard OpenID Federation 1.0 compliance.

For complete technical specifications of federation protocols, entity configurations, trust evaluation mechanisms, and trust chain validation, see The Infrastructure of Trust.

7.6. Digital Credentials Catalog¶

The Digital Credentials Catalog is the registry of all available Digital Credentials recognized within the IT-Wallet ecosystem. It is published by the Trust Anchor and publicly available by all Entities through a specialized Federation endpoint. It acts as a single reference point for all actors involved in the process of issuing, verifying and using Digital Credentials.

The Digital Credential Catalog aims to:

Facilitate Digital Credential discovery for Users.

Standardize the technical and functional description of Digital Credentials.

Enable interoperability between different Issuers and Relying Parties.

Simplify the integration process for Wallet Providers and Relying Parties.

Ensure trust in the ecosystem through verifiable and trustworthy information.

Provide transparency on the ecosystem of available Digital Credentials.

The main Entities involved in the Digital Credential Catalog are:

Trust Anchor: It manages and maintains the Digital Credential Catalog, guaranteeing its authenticity and integrity.

Supervisory Body: It interacts with the Trust Anchor and the Digital Credential Catalog to monitor the registration phase ensuring security and privacy according to national/European regulations, keeping all the information reliable and updated.

Digital Credential Issuers: The entities authorized to issue Digital Credentials, registering them in the Catalog.

Relying Parties: They use the Digital Credential 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 Credential 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: The Entities that hold the original data that is attested in the Digital Credentials. They provide support to Issuers in registering the Digital Credentials in the Catalog.

The figure illustrates the Digital Credential Entities. — Fig. 7.1 Entity-Relationship diagram of Digital Credential Catalog.¶

The following table summarizes the main information that MUST be provided by the Digital Credential Catalog:

Table 7.3 Digital Credential 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 Trust Anchor MUST publish and keep up to date all the information at the Digital Credential Catalog .well-known endpoint ensuring data reliability, authenticity and integrity. In particular, the Digital Credential Catalog, claims and taxonomy MUST be available through the .well-known/credential-catalog endpoint.

7.6.1. Digital Credentials Hierarchy¶

Digital Credentials recognized within the IT-Wallet ecosystem are hierarchically classified and standardized according to the following main domains and purposes. Additional purposes MAY be added as the IT-Wallet ecosystem grows.

Table 7.4 Digital Credential Domains and Purposes¶
Domain	Purpose	Description
IDENTITY	PERSON_IDENTIFICATION ELECTRONIC_RESIDENCY	Credentials that establish or verify the identity of a person, including physical and digital identity documents legally recognized by national laws.
AUTHORIZATION	DRIVING_LICENSE PROFESSIONAL_LICENSE TRAVEL_DOCUMENT ACCESS_PERMIT	Credentials that grant specific permissions, rights or authorizations to perform certain activities or access restricted areas.
EDUCATION	ACADEMIC_DEGREE CERTIFICATE TRAINING_RECOGNITION	Credentials related to educational achievements, qualifications, and professional training recognition.
HEALTH	INSURANCE_CARD DISABILITY_CARD MEDICAL_PRESCRIPTION	Credentials related to healthcare access, medical history, insurance coverage, and health-related documents.
FINANCIAL	INCOME_CERTIFICATE TAX_STATEMENT FAMILY_ECONOMIC_STATUS BANK_ACCOUNT PAYMENT_HISTORY	Credentials that attest to financial status, income levels, taxation, banking information, or economic situation of individuals or families.
MEMBERSHIP	ASSOCIATION LOYALTY_PROGRAM CLUB_MEMBERSHIP	Credentials that confirm affiliation with organizations, participation in programs, or membership status.
ATTESTATION	PUBLIC_STATEMENT CIVIL_STATUS CERTIFICATION	Credentials that provide official statements, confirmations of status, or certifications issued by authorities.

Each Credential MUST specify domains and purposes to enable both Credential-Specific Scenarios and Credential-Agnostic Scenarios according to Relying Party's requirements and presentation request patterns:

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

Government Services: "vct_values": ["urn:eudi:pid:it:1"] for PID-specific identity verification.

Police Controls: "docType": "org.iso.18013.5.1.mDL" for driving license verification.

Banking KYC: Specific credential types mandated by financial regulations.

Healthcare Services: "vct_values": ["urn:eudi:european_disability_card:it:1"] for EU-compliant disability benefit access.

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/purpose mappings.

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

7.6.2. Digital Credentials Catalog Structure¶

Digital Credentials Catalog contents is secured in a JWS that contains the following JOSE header parameters:

JOSE header	Description	Reference
typ	REQUIRED. It MUST be set to `JOSE`.	[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 JWS. 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 JWS payload contains the following parameters:

Table 7.5 First-level Fields of the Digital Credentials Catalog¶
Field Name	Description
version	REQUIRED. Version of the Digital Credential Catalog format.
last_modified	REQUIRED. Timestamp of the last modification to the Digital Credential Catalog.
iss	REQUIRED. Issuer identifier of the Digital Credential Catalog.
credentials	REQUIRED. Array containing Digital Credential definitions.

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

Table 7.6 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`.
credential_name	REQUIRED. Human-readable name of the Digital Credential.
legal_type	REQUIRED. Legal classification of the Credential (e.g., `pub-eaa`, `qeaa`, `eaa`).
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 by the Trust Anchor in the issuers field of the corresponding Digital Credential.
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	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: Allowed Digital Credential states (e.g. `VALID`, `INVALID`, `SUSPENDED`).
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_eid_schemes: REQUIRED if `user_auth_required` is `true`. Supported digital identity authentication schemes.
purposes	REQUIRED. Array of usage purposes for which the Digital Credential can be used, defining specific usage contexts and required claims for each purpose, such as: id: Unique identifier for the purpose (e.g., "driving-authorization", "person-identification"). description: Human-readable purpose description with a suffix `_l10n_id` for content localisation. claims_required: Array of claim identifiers that are required when using the Credential for this purpose. claims_recommended: Array of claim identifiers that are recommended but not mandatory for this purpose.
issuers	REQUIRED. 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 (for example the deferred flow support).
authentic_sources	REQUIRED. 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.

Note

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

The corresponding example of Digital Credentials Catalog as decoded in JSON for both header and payload is the following:

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

{
    "version": "1.0",
    "last_modified": "2025-03-15T12:00:00Z",
    "iss": "https://trust-registry.eid-wallet.example.it",
    "credentials": [{
        "version": "1.0",
        "credential_type": "mDL",
        "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"
            ]
        },
        "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"
            ],
            "allowed_states": {
                "0x00" : "VALID",
                "0x01" : "INVALID",
                "0x02" : "SUSPENDED",
                "0x03" : "UPDATE",
                "0x0B" : "ATTRIBUTE_UPDATE"
            }
        },
        "authentication": {
            "user_auth_required": true,
            "min_loa": "high",
            "supported_schemes": [
                "it-wallet"
            ]
        },
        "purposes": [{
            "id": "DRIVING_LICENSE"
        },
            {
                "id": "PERSON_IDENTIFICATION"
            }
        ],
        "issuers": [{
            "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": "https://issuer.example.org/.well-known/service-doc",
            "issuance_flows": {
                "deferred_flow": true,
                "max_deferred_issuance_time_minutes": 1440,
                "notification_methods": [
                    "push",
                    "polling"
                ]
            }
        }],
        "authentic_sources": [{
            "id": "https://motorizzazione.gov.example",
            "dataset_id": "38832801"
        }]
    }]
}

Note

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

Download the basic version of the Digital Credentials Catalog (compact, without localisations) using the .well-known/credential-catalog endpoint.
Determine the User's preferred language.
Download only the necessary localisation bundles.
Dynamically merge localised content with the Digital Credentials Catalog structure.

A non-normative example of a localisation 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 specified in the localization_info.bundles_base_uri claim of the Digital Credentials 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/credential-catalog/it.json.

Entities SHOULD verify the integrity of downloaded localization bundles using the digest method and values specified in the localization_info.integrity claim. This ensures that the localization data has not been tampered with during transmission.

7.6.3. Decentralization of Display and Claim Information¶

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

The overall logic for presenting a Credential is:

The Wallet/Relying Party retrieves the lightweight Digital Credentials Catalog to discover the available credential_type and the entity_id of their Credential Issuers.
It retrieves the full Credential Issuer Metadata (Entity Configuration) from the discovered entity_id.
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.7. Taxonomy¶

The Taxonomy provides the semantic foundation for Digital Credential interoperability by maintaining the authoritative vocabulary for organizing Credentials within the IT-Wallet ecosystem. The taxonomy is neutral with respect to the Credential format.

The taxonomy provides, in a single resource, the hierarchical classification system organizing domains and purposes that can be applied to credential types, supporting authorization policy evaluation and ecosystem-wide standardization.

Taxonomy Objectives:

Semantic Foundation: Establish standardized vocabulary for domains and purposes across the ecosystem
Policy Framework: Enable structured authorization decisions based on hierarchical classification
Interoperability: Ensure consistent interpretation of credential classifications
Extensibility: Support evolution of the ecosystem with new domains and purposes
Cross-Border Compliance: Align with EU regulatory requirements and international standards

Taxonomy Structure:

The taxonomy maintains a two-level hierarchical structure:

Domains: Top-level classification representing broad functional areas (e.g., IDENTITY, AUTHORIZATION, FINANCIAL)
Purposes: Specific credential use cases within each domain (e.g., PERSON_IDENTIFICATION, DRIVING_LICENSE, BANK_ACCOUNT) for which credentials can be used

Localization Support:

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

Taxonomy Usage:

Claims Registry: Individual claims catalog
AS Registry: Authentic Sources declare capabilities using taxonomy classifications
Digital Credentials Catalog: Credential types specify domains and supported purposes
Authorization Policies: Policy evaluation leverages taxonomy structure for access control decisions

The taxonomy is accessible through the dedicated taxonomy endpoint as defined in the registry discovery mechanism and is maintained by the Supervisory Body to ensure regulatory compliance and semantic consistency.

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

{
    "version": "1.0",
    "last_modified": "2025-04-10T12:00:00Z",
    "id": "urn:taxonomy:it-wallet",
    "localization": {
        "default_locale": "it",
        "available_locales": ["en", "it", "fr", "de"],
        "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/taxonomy/",
        "version": "1.0.0"
    },
    "name_l10n_id": "taxonomy.name",
    "description_l10n_id": "taxonomy.description",
    "domains": [
        {
            "id": "IDENTITY",
            "name_l10n_id": "domain.identity.name",
            "description_l10n_id": "domain.identity.description",
            "purposes": [
                {
                    "id": "PERSON_IDENTIFICATION",
                    "name_l10n_id": "purpose.person_identification.name",
                    "description_l10n_id": "purpose.person_identification.description"
                },
                {
                    "id": "ELECTRONIC_RESIDENCY",
                    "name_l10n_id": "purpose.electronic_residency.name",
                    "description_l10n_id": "purpose.electronic_residency.description"
                }
            ]
        },
        {
            "id": "AUTHORIZATION",
            "name_l10n_id": "domain.authorization.name",
            "description_l10n_id": "domain.authorization.description",
            "purposes": [
                {
                    "id": "DRIVING_LICENSE",
                    "name_l10n_id": "purpose.driving_license.name",
                    "description_l10n_id": "purpose.driving_license.description"
                },
                {
                    "id": "PROFESSIONAL_LICENSE",
                    "name_l10n_id": "purpose.professional_license.name",
                    "description_l10n_id": "purpose.professional_license.description"
                },
                {
                    "id": "TRAVEL_DOCUMENT",
                    "name_l10n_id": "purpose.travel_document.name",
                    "description_l10n_id": "purpose.travel_document.description"
                },
                {
                    "id": "ACCESS_PERMIT",
                    "name_l10n_id": "purpose.access_permit.name",
                    "description_l10n_id": "purpose.access_permit.description"
                }
            ]
        },
        {
            "id": "EDUCATION",
            "name_l10n_id": "domain.education.name",
            "description_l10n_id": "domain.education.description",
            "purposes": [
                {
                    "id": "ACADEMIC_DEGREE",
                    "name_l10n_id": "purpose.academic_degree.name",
                    "description_l10n_id": "purpose.academic_degree.description"
                },
                {
                    "id": "CERTIFICATE",
                    "name_l10n_id": "purpose.certificate.name",
                    "description_l10n_id": "purpose.certificate.description"
                },
                {
                    "id": "TRAINING_RECOGNITION",
                    "name_l10n_id": "purpose.training_recognition.name",
                    "description_l10n_id": "purpose.training_recognition.description"
                }
            ]
        },
        {
            "id": "HEALTH",
            "name_l10n_id": "domain.health.name",
            "description_l10n_id": "domain.health.description",
            "purposes": [
                {
                    "id": "INSURANCE_CARD",
                    "name_l10n_id": "purpose.insurance_card.name",
                    "description_l10n_id": "purpose.insurance_card.description"
                },
                {
                    "id": "DISABILITY_CARD",
                    "name_l10n_id": "purpose.disability_card.name",
                    "description_l10n_id": "purpose.disability_card.description"
                },
                {
                    "id": "MEDICAL_PRESCRIPTION",
                    "name_l10n_id": "purpose.medical_prescription.name",
                    "description_l10n_id": "purpose.medical_prescription.description"
                }
            ]
        },
        {
            "id": "FINANCIAL",
            "name_l10n_id": "domain.financial.name",
            "description_l10n_id": "domain.financial.description",
            "purposes": [
                {
                    "id": "INCOME_CERTIFICATE",
                    "name_l10n_id": "purpose.income_certificate.name",
                    "description_l10n_id": "purpose.income_certificate.description"
                },
                {
                    "id": "TAX_STATEMENT",
                    "name_l10n_id": "purpose.tax_statement.name",
                    "description_l10n_id": "purpose.tax_statement.description"
                },
                {
                    "id": "FAMILY_ECONOMIC_STATUS",
                    "name_l10n_id": "purpose.family_economic_status.name",
                    "description_l10n_id": "purpose.family_economic_status.description"
                },
                {
                    "id": "BANK_ACCOUNT",
                    "name_l10n_id": "purpose.bank_account.name",
                    "description_l10n_id": "purpose.bank_account.description"
                },
                {
                    "id": "PAYMENT_HISTORY",
                    "name_l10n_id": "purpose.payment_history.name",
                    "description_l10n_id": "purpose.payment_history.description"
                }
            ]
        },
        {
            "id": "MEMBERSHIP",
            "name_l10n_id": "domain.membership.name",
            "description_l10n_id": "domain.membership.description",
            "purposes": [
                {
                    "id": "ASSOCIATION",
                    "name_l10n_id": "purpose.association.name",
                    "description_l10n_id": "purpose.association.description"
                },
                {
                    "id": "LOYALTY_PROGRAM",
                    "name_l10n_id": "purpose.loyalty_program.name",
                    "description_l10n_id": "purpose.loyalty_program.description"
                },
                {
                    "id": "CLUB_MEMBERSHIP",
                    "name_l10n_id": "purpose.club_membership.name",
                    "description_l10n_id": "purpose.club_membership.description"
                }
            ]
        },
        {
            "id": "ATTESTATION",
            "name_l10n_id": "domain.attestation.name",
            "description_l10n_id": "domain.attestation.description",
            "purposes": [
                {
                    "id": "PUBLIC_STATEMENT",
                    "name_l10n_id": "purpose.public_statement.name",
                    "description_l10n_id": "purpose.public_statement.description"
                },
                {
                    "id": "CIVIL_STATUS",
                    "name_l10n_id": "purpose.civil_status.name",
                    "description_l10n_id": "purpose.civil_status.description"
                },
                {
                    "id": "CERTIFICATION",
                    "name_l10n_id": "purpose.certification.name",
                    "description_l10n_id": "purpose.certification.description"
                }
            ]
        }
    ]
}

Note

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

Download the basic version of the Digital Credentials Catalog (compact, without localisations) using the .well-known/taxonomy endpoint.

Determine the User's preferred language.

Download only the necessary localisation bundles.

Dynamically merge localised content with the Digital Credentials Catalog structure.

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

{
  "domain.identity.name": "Identità",
  "domain.identity.description": "Attestati Elettronici che stabiliscono o verificano l`identità di una persona, compresi i documenti di identità fisici e digitali legalmente riconosciuti dalle leggi nazionali.",
  "purpose.person_identification.name": "identificazione della persona",
  "...": "..."
}

Localization bundles MUST be available at the URI specified in the localization_info.bundles_base_uri claim of the Digital Credentials 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/taxonomy/it.json.

Entities SHOULD verify the integrity of downloaded localization bundles using the digest method and values specified in the localization_info.integrity claim. This ensures that the localization data has not been tampered with during transmission.

7.8. 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. It is managed by the Trust Anchor and provides a single, verifiable source for retrieving the technical specifications required for parsing, validating, and displaying Digital Credentials.

Schema Registry Objectives:

Schema Centralization: Provide a centralized access point for all technical schemata used by Digital Credentials.
Integrity and Authenticity: Ensure the integrity and authenticity of the schema documents through cryptographic digests.
Interoperability: Facilitate the seamless integration of Wallet Providers and Relying Parties by providing consistent schema versions.
Credential Lifecycle Support: Act as a verifiable reference point for schema validation during issuance and presentation.

Schema Registry Structure and Access:

The Schema Registry is accessible via the .well-known/it-wallet-registry discovery endpoint under the schema_registry field. It allows for the discovery of schema URIs and their cryptographic integrity checks.

Table 7.7 First-level Fields of the Schema Registry¶
Field Name	Description
version	REQUIRED. The version of the Schema Registry (e.g., `1.0`).
last_modified	REQUIRED. The timestamp indicating when the list was last updated (e.g., `2025-03-15T12:00:00Z`).
schemas	REQUIRED. A JSON Array where each entry is a JSON Object representing a Credential Schema definition. Each object contains the parameters defined in the "Schema Definition Parameters" table below, including schema identification, format specifications, URIs, and integrity verification data.

Table 7.8 Schema Definition Parameters¶
Field Name	Description
id	REQUIRED. The unique identifier of the scheme (e.g., `mDL+mso_mdoc+org.iso.18013.5.1.mDL`).
version	REQUIRED. The version of the schema definition (e.g., `1.0`).
credential_type	REQUIRED. The unique identifier of the Digital Credential type (e.g., `mDL`, `pid`).
format	REQUIRED. The technical format of the schema (e.g., `mso_mdoc`, `dc+sd-jwt`).
vct	CONDITIONAL. It is REQUIRED if the `format` is `dc+sd-jwt`, indicating the Verifiable Credential Type (e.g., `urn:eudi:mDL:it:1`).
docType	CONDITIONAL. It is REQUIRED if the `format` is `mso_mdoc`, indicating the document type used (e.g., `org.iso.18013.5.1.mDL`).
schema_uri	REQUIRED. The URI where the schema document can be retrieved (e.g., `https://trust-registry.it-wallet.example.it/.well-known/schemas/mdoc/mDL`).
schema_uri#integrity	REQUIRED. Cryptographic digest of the schema document for integrity verification. Format: `{digest_method}-{digest_value}` (e.g., `sha256-c8b708728e4c5756e35c03aeac257ca878d1f717d7b61f621be4d36dbd9b9c16`).
description	OPTIONAL. A human-readable description of the schema, which may be localized (e.g., "Schema tecnico per la mobile Driving License in formato mdoc.").

Schema Registry Example:

A non-normative example of the Schema Registry payload:

{
    "version": "1.0",
    "last_updated": "2025-03-15T12:00:00Z",
    "schemas": [
        {
            "id": "mDL+mso_mdoc+org.iso.18013.5.1.mDL",
            "version": "1.0",
            "credential_type": "mDL",
            "format": "mso_mdoc",
            "docType": "org.iso.18013.5.1.mDL",
            "schema_uri": "https://trust-registry.it-wallet.example.it/.well-known/schemas/mdoc/mDL",
            "schema_uri#integrity": "sha256-c8b708728e4c5756e35c03aeac257ca878d1f717d7b61f621be4d36dbd9b9c16",
            "description": "Schema tecnico per la mobile Driving License in formato mdoc."
        },
        {
            "id": "pid+dc+sd-jwt+urn:eudi:pid:it:1",
            "version": "1.0",
            "credential_type": "pid",
            "format": "dc+sd-jwt",
            "vct": "urn:eudi:pid:it:1",
            "schema_uri": "https://trust-registry.it-wallet.example.it/.well-known/schemas/sd-jwt/pid",
            "schema_uri#integrity": "sha256-a1b2c3d4e5f67890...",
            "description": "Schema tecnico per la Person Identification Data (PID) in formato SD-JWT."
        }
    ]
}

7.9. Registry Integration and Cross-References¶

The registry components are interconnected and work together to support the complete credential ecosystem:

AS Registry ↔ Taxonomy: AS entities declare capabilities using taxonomy classifications for standardized categorization.
AS Registry ↔ Catalog: Credential types reference AS capabilities for data source validation.
Catalog ↔ Taxonomy: Credential entries specify domains and purposes from the taxonomy for discovery and authorization.
Federation Registry ↔ All Components: Provides cryptographic trust validation for all registry operations and entity authentication.
Schema Registry ↔ Issuer/RPs: Provides the verifiable link to all known Credential format specifications used in the ecosystem.

7.10. 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 interactions with the Registry Infrastructure.

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

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.
Navigation and Selection:

Credential Discovery: The entity browses the list of Credentials (credentials field) to identify relevant Credential types (e.g., pid, driving_license).

Issuer Metadata: The entity extracts the Issuer Identifier (entity_id within the issuers field) associated with the desired Credential.

Detail Consultation: To obtain complete information oand specific technical requirements, the entity accesses the Entity Configuration (Issuer Metadata) using the retrieved identifier.

Final Action: The entity can then can use the metadata to display the catalog information to a User (or use the information in other way).

7.10.2. Credential Issuance¶

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

Identifying Requirements: The CI consults the Digital Credentials Catalog for the technical requirements of the Credential type to be issued (e.g., max_validity_days, min_loa).
Schema and Claim Resolution:

The CI consults the Schema Registry to retrieve the technical specification of the format and schema (e.g., JSON Schema for SD-JWT) required by the Catalog, ensuring validity and integrity via the hash (schema_uri#integrity).

The CI accesses the Claims Registry to retrieve the standardized semantic definitions and data formats (data types) of the necessary attributes (claims).

Authentic Data Retrieval:

The CI 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 CI consults the AS endpoint specification to implement the integration needed to retrieve the User data required to populate the Digital Credential.

Credential Issuance: The CI 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.10.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.

Wallet Authorization and Selection:

The Wallet receives a Presentation Request from the RP, verifies the validity of the request comparing the requested claims with the Authorization Policies related to the RP (via the Taxonomy definitions).

The Wallet consults the Digital Credentials Catalog to verify the Domains and Purposes associated with the Credential types it holds, evaluating which Credentials are suitable for the request.

The Wallet verifies if the required attributes (claims) are available and authorized for disclosure based on the request policy (Credential-Specific or Credential-Agnostic scenarios).

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

Discovery and Integrity:

The RP receives the Digital Credential from the User.

The RP consults the Federation Registry via the Trust Anchor's endpoint (federation_resolve, federation_trust_mark_status) to verify the cryptographic trust (Trust Mark) of the Issuer and Wallet Provider as defined in Section The Infrastructure of Trust.

The RP consults the Schema Registry to download the schema of the presented Credential (schema_uri), verifying its integrity (schema_uri#integrity).

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.

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