7. Registry Infrastructure¶
L'ecosistema IT-Wallet opera tramite un'infrastruttura di registro che fornisce definizioni di dati standardizzate e capacità di discovery delle Credenziali. Il sistema di registro è costituito da più componenti interconnessi che supportano l'intero ciclo di vita delle operazioni sugli Attestati Elettronici, dall'onboarding delle entità alla presentazione dell'Attestato Elettronico. L'architettura del registro affronta i requisiti di standardizzazione semantica e di discovery delle Credenziali tramite componenti di registro specializzati che assicurano interoperabilità e conformità nell'ecosistema.
A livello UE la Commissione Europea mantiene due cataloghi EUDIW che sono le controparti transfrontaliere dei registri semantici nazionali a cui i registri nazionali si allineano, definiti in ARF TS11 (EUDI-TS 11) (Interfaces and formats for the Catalogue of Attributes and the Catalogue of Schemes):
Catalogue of Attributes è il catalogo a livello UE delle definizioni e dei namespace di attributi standardizzati utilizzati negli Attestati.
Catalogue of Schemes è il catalogo a livello UE degli schema di Attestato (
SchemaMeta): i metadata machine-readable che vincolano un tipo di Attestato al proprio Rulebook e schema.
I registri e i cataloghi utilizzati all'interno dell'ecosistema IT-Wallet hanno finalità e ambiti diversi. I registri il cui contenuto è evidenza di una decisione di trust, quali il Register of WRPs operato da un Registrar nazionale ai sensi di CIR2025/848 e i Federation API Endpoints del National Trust Framework, sono specificati in Infrastructure of Trust. I registri per la definizione semantica e la discovery dei dati sono dettagliati in questa Sezione.
In particolare, questa sezione fornisce innanzitutto una panoramica dell'infrastruttura di registro IT-Wallet (Registries and Catalogues of the Ecosystem) e del suo meccanismo di discovery (Endpoint di Discovery del Registro). Quindi, ne dettaglia i componenti: Taxonomy, Claims Registry, Authentic Source Registry, Schema Registry e Catalogo degli Attestati Elettronici. Infine, descrive le loro relazioni (Registry Integration and Cross-References) e i journey di utilizzo (Registry Infrastructure Usage Journeys).
7.1. Registries and Catalogues of the Ecosystem¶
L'ecosistema IT-Wallet utilizza diversi registri e cataloghi, a livello nazionale e a livello UE, e essi servono due finalità diverse.
Finalità di trust: il contenuto del registro è consumato da un Trust Evaluator per accettare o rifiutare un'entità o un artifact. Questi registri sono Trust Artifact, sono definiti in Infrastructure of Trust e il modo in cui sono consumati è definito in Trust Evaluation Process.
Finalità semantica e di discovery: il contenuto del registro definisce gli attributi, gli schema e i tipi di Credenziale, o li rende scopribili. Questi registri sono definiti in questa Sezione.
Nota
La distinzione tra registri di trust e registri semantici/di discovery è sulla finalità e non sul contenuto. Ad esempio, un registro con finalità semantica e di discovery può recare un parametro che punta a un trust framework, come fa trustedAuthorities del Digital Credentials Catalog, ma tale parametro identifica il trust framework applicabile e non è di per sé l'evidenza di una decisione di trust.
Registry or Catalogue |
Purpose |
Maintained by |
Specified in |
|---|---|---|---|
Taxonomy, Claims Registry, Schema Registry, Authentic Source Registry, Digital Credentials Catalog |
Semantica e discovery |
Federation Trust Anchor, sotto l'Organismo di Supervisione |
Questa Sezione |
Register of WRPs |
Trust |
Registrar |
|
Federation API Endpoints, Entity Statements and Trust Marks |
Trust |
Federation Trust Anchor e Federation Intermediate |
|
Catalogue of Attributes and Catalogue of Schemes |
Semantica e discovery |
Commissione Europea |
[EUDI-TS 11]. L'allineamento dei registri nazionali è descritto in Registry Integration and Cross-References |
Lists of Trusted Entities, Trusted Lists and List of Trusted Lists |
Trust |
Commissione Europea e Stati membri |
Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities |
Nota
I meccanismi che pubblicano lo stato di un certificato o di un Attestato, quali le Certificate Revocation List, i responder OCSP e le Token Status List, non sono registri e non sono elencati nella tabella precedente. Sono descritti in Revocation Mechanisms.
Cinque registri nazionali semantici e di discovery forniscono le definizioni standardizzate e i dati di discovery:
Taxonomy: Sistema di classificazione gerarchica che organizza le Credenziali per dominio e scopo.
Claims Registry: Definizioni semantiche standardizzate per i singoli attributi delle Credenziali e i tipi di dato.
Authentic Source Registry: Fonti Autentiche (AS) registrate con le loro capacità dichiarate, i claim disponibili e gli endpoint di verifica.
Schema Registry: Elenco autorevole degli Schema delle Credenziali.
Digital Credentials Catalog: Tipi di Credenziale disponibili con i relativi metadata e le informazioni di emissione.
I registri nazionali sono mantenuti dal Federation Trust Anchor sotto l'Organismo di Supervisione per assicurare coerenza, sicurezza e conformità normativa. Sono popolati dai processi di onboarding descritti in Onboarding Processes, e sono letti sia durante l'onboarding sia durante le fasi operative.
Le Entità che forniscono le informazioni sono le seguenti:
l'Attestation Scheme Provider, per la definizione di un tipo di Credenziale e del suo schema.
le Fonti Autentiche, per le loro capacità dati dichiarate.
le Wallet-Relying Party e i Fornitori di Wallet, per i loro dati di registrazione.
Questi ruoli sono descritti in System Actors and Roles.
Nessuna di queste Entità scrive direttamente in un registro. Forniscono le informazioni tramite i processi di onboarding, che le verificano e le scrivono. Ciascun registro è poi firmato e pubblicato dal Federation Trust Anchor per i registri nazionali e per gli statement di federazione, dal Registrar per il Register of WRPs, e dalla Commissione Europea per i cataloghi e le liste UE.
Nota
Non tutto il contenuto di un registro è fornito da un'Entità. Parte di esso è impostato dal Sistema di Onboarding stesso, quale lo stato di un tipo di Credenziale nel Digital Credentials Catalog, che deriva dalle condizioni della voce versionata. I componenti interni del Sistema di Onboarding e il processo che ciascuno di essi realizza sono descritti in System Components and Services.
Nota
Un'Entità che fornisce un'informazione non è necessariamente l'Entità che la decide, perché le decisioni su un tipo di Credenziale sono assunte nel suo Attestation Rulebook, che è un input del Sistema di Onboarding.
La Figura Registries and Catalogues of the Ecosystem mostra l'insieme completo dei registri e dei cataloghi, raggruppati per finalità e per livello, con le Entità che ne forniscono il contenuto e le autorità che li pubblicano.
La Figura Discovery on the Registry Infrastructure mostra, per i registri definiti in questa Sezione, la fase di onboarding o operativa in cui ciascuno di essi è letto e da chi. Maggiori dettagli sono forniti in ciascuna sezione. Il modo in cui i registri con finalità di trust sono letti è descritto in Trust Evaluation Process.
7.2. Endpoint di Discovery del Registro¶
Il Federation Trust Anchor DEVE fornire un meccanismo di discovery per i componenti del registro tramite endpoint well-known standardizzati che forniscono metadata e informazioni di discovery delle API REST.
La paginazione e il filtraggio del Digital Credentials Catalog sono specificati in Digital Credentials Catalog Retrieval.
Il Federation Trust Anchor DEVE pubblicare i metadata di discovery del registro all'endpoint .well-known/it-wallet-registry con supporto alla content negotiation, come specificato in Content Negotiation and Signed Representation.
Default Content-Type:
application/jwt(JWT firmato che assicura autenticità e integrità)Alternative Content-Type:
application/json(JSON in chiaro per finalità di sviluppo/debug)
Di seguito è fornito un esempio non normativo.
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¶
Il payload JWT della risposta del Registry Discovery DEVE contenere i seguenti parametri:
Field Name |
Description |
|---|---|
id |
OBBLIGATORIO. Identificativo univoco del documento Registry Discovery (ad es., |
version |
OBBLIGATORIO. La versione del documento Registry Discovery (ad es., |
last_modified |
OBBLIGATORIO. Il timestamp che indica quando l'elenco è stato aggiornato l'ultima volta (ad es., |
endpoints |
OBBLIGATORIO. Oggetto JSON contenente gli URI di tutti i componenti del registro. Le seguenti chiavi di endpoint DEVONO essere presenti:
|
content_negotiation |
OBBLIGATORIO. Array dei content type supportati dall'endpoint di discovery (ad es., |
Struttura del payload JWT (quando decodificato):
{
"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¶
Ogni endpoint della Registry Infrastructure DEVE supportare la content negotiation e servire il proprio contenuto in due rappresentazioni:
Default Content-Type:
application/jwt(JWT firmato che fornisce autenticità e integrità)Alternative Content-Type:
application/json(JSON in chiaro per sviluppo e debug)
Entrambe le rappresentazioni sono servite allo stesso URL di endpoint, non come risorse o path distinti. Il client seleziona la rappresentazione con l'header di richiesta Accept, e il Federation Trust Anchor indica la rappresentazione restituita nell'header di risposta Content-Type. Se la richiesta non chiede un tipo supportato (Accept assente, */*, o solo tipi non supportati), l'endpoint DEVE restituire la rappresentazione application/jwt.
Questo requisito si applica a tutti gli endpoint della Registry Infrastructure elencati nella tabella seguente:
Registry component |
How the endpoint is located |
|---|---|
Registry Discovery |
Path well-known fisso |
Claims Registry |
URL assoluto pubblicato sotto la chiave |
Authentic Source Registry |
URL assoluto pubblicato sotto la chiave |
Schema Registry |
URL assoluto pubblicato sotto la chiave |
Taxonomy |
URL assoluto pubblicato sotto la chiave |
Digital Credentials Catalog |
URL assoluto pubblicato sotto la chiave |
Il Registry Discovery Endpoint è l'unico a un path well-known fisso. Un client lo legge per primo per ottenere l'URL di ogni altro componente dal suo oggetto endpoints firmato (si veda Endpoint di Discovery del Registro). Un client NON DEVE assumere un path fisso per gli altri componenti. La content negotiation si applica all'endpoint di discovery e a ogni URL di componente che pubblica.
Tutti questi endpoint gestiscono la content negotiation allo stesso modo: la stessa richiesta, gli stessi due valori di Content-Type e la stessa rappresentazione firmata.
La rappresentazione firmata è un JWT in compact serialization, servito come application/jwt. Il suo header DEVE contenere i parametri nella tabella seguente.
Header parameter |
Description |
Reference |
|---|---|---|
typ |
OBBLIGATORIO. DEVE essere impostato a |
[RFC 7515 Section 4.1.9]. |
alg |
OBBLIGATORIO. Un identificativo di algoritmo di firma digitale come da registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati nella Sezione Algoritmi Crittografici e NON DEVE essere impostato a |
[RFC 7515 Section 4.1.1]. |
kid |
OBBLIGATORIO. Identificativo univoco della chiave pubblica. |
[RFC 7515 Section 4.1.4]. |
x5c |
OPZIONALE. Contiene il certificato a chiave pubblica X.509 o la catena di certificati [RFC 5280] corrispondente alla chiave utilizzata per firmare digitalmente il JWT. Quando il valore del parametro di header kid è presente, DEVE fare riferimento alla stessa chiave pubblica crittografica della foglia utilizzata con il certificato X.509. |
[RFC 7515 Section 4.1.6.]. |
cty |
OBBLIGATORIO. DEVE essere impostato a |
[RFC 7515 Section 4.1.6.]. |
La rappresentazione in chiaro è lo stesso contenuto, servito come oggetto JSON in chiaro anziché come JWT firmato.
L'esempio non normativo seguente richiede entrambe le rappresentazioni dall'endpoint del Digital Credentials Catalog. L'URL è quello risolto dal documento di discovery, qui accorciato per leggibilità.
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
L'esempio richiede la prima pagina della collection. I parametri di query, le pagine successive e la risorsa entry sono specificati in Digital Credentials Catalog Retrieval.
7.3. Taxonomy¶
La Taxonomy è il vocabolario autorevole che organizza le Credenziali nell'ecosistema IT-Wallet, ed è il fondamento semantico della loro interoperabilità. È indipendente dal formato della Credenziale.
In una singola risorsa, definisce la gerarchia di Domain, Class e Purpose che i tipi di Credenziale referenziano, a supporto della valutazione delle policy di autorizzazione e della standardizzazione a livello di ecosistema.
L'URL dell'endpoint Taxonomy è pubblicato sotto la chiave taxonomy del documento Registry Discovery. L'endpoint supporta la content negotiation e la rappresentazione firmata comuni a tutti gli endpoint della Registry Infrastructure (si veda Content Negotiation and Signed Representation).
7.3.1. Taxonomy Objectives¶
Fondamento semantico: Stabilire un vocabolario standardizzato per i domain e i purpose nell'ecosistema
Framework di policy: Abilitare decisioni di autorizzazione strutturate basate sulla classificazione gerarchica
Interoperabilità: Assicurare un'interpretazione coerente delle classificazioni delle Credenziali
Estensibilità: Supportare l'evoluzione dell'ecosistema con nuovi Domain, Class, tipi di Credenziale e Purpose
Conformità transfrontaliera: Allinearsi ai requisiti regolamentari UE e agli standard internazionali
7.3.2. Taxonomy Usage¶
Authentic Source Registry: Le Fonti Autentiche dichiarano le capacità utilizzando le classificazioni della taxonomy
Digital Credentials Catalog: I tipi di Credenziale specificano Domain, Class e Purpose
Policy di autorizzazione: La valutazione delle policy sfrutta la struttura della taxonomy per le decisioni di controllo degli accessi
7.3.3. Digital Credentials Hierarchy¶
Gli Attestati Elettronici riconosciuti all'interno dell'ecosistema IT-Wallet sono classificati e standardizzati secondo il seguente modello gerarchico a più livelli, progettato per migliorare la chiarezza semantica, la discovery delle Credenziali e la compatibilità sia con i workflow di verifica specifici della Credenziale sia con quelli basati sui claim.
La gerarchia è definita come segue:
7.3.3.1. Domain¶
Un Domain rappresenta un'area tematica di alto livello che raggruppa famiglie di Credenziali relative allo stesso contesto ampio (ad es., Identity, Health, Education, Mobility). I Domain forniscono uno strato organizzativo di primo livello.
7.3.3.2. Credential Class¶
Una Credential Class rappresenta una famiglia di Credenziali che condividono natura, funzione o struttura simili (ad es., Identification Documents, Civil Status Certificates).
Ciascuna Class DOVREBBE definire:
un identificativo di Class stabile (URI),
la semantica attesa della Credential Family.
Le Class consentono alle Relying Party e alle Soluzioni Wallet di richiedere o abbinare Credenziali in base alla loro categoria di tipo.
7.3.3.3. Credential Type¶
Un Credential Type rappresenta una Credenziale specifica all'interno di una Class (ad es. Digital Travel Credential, Birth Certificate, Mobile Driving License). Ciascun Credential Type DEVE includere:
un identificativo univoco,
l'identificativo del Credential Issuer,
l'insieme di Attributi che possono essere inclusi nelle presentazioni.
I Credential Type consentono un targeting preciso per i flussi di verifica guidati dalla conformità o imposti dalla regolamentazione.
7.3.3.4. Purpose (Verification Intent)¶
Un Purpose (Verification Intent) descrive perché una Credenziale può essere richiesta da una Relying Party (ad es., Identity Verification, Age Verification, Eligibility for specific services). I Purpose DEVONO descrivere esiti di verifica. Ciascun Credential Type DEVE dichiarare il proprio Domain, la propria Class e i Purpose supportati.
Le tabelle seguenti forniscono esempi non esaustivi che illustrano le relazioni tra Domain, Credential Class e Credential Type, seguiti dalla loro mappatura sui Purpose di verifica. Domain, Class, Credenziali specifiche e Purpose di verifica aggiuntivi POSSONO essere aggiunti nel tempo con l'evoluzione dell'ecosistema IT-Wallet.
Domain |
Description |
Credential Class |
Credential Type |
|---|---|---|---|
IDENTITY |
Credenziali che instaurano o confermano l'identità legale di una persona e lo stato personale, civile o giuridico. |
|
|
HOME AND FAMILY |
Credenziali che attestano la composizione del nucleo familiare, la residenza e i rapporti giuridici o fiscali relativi all'abitazione. |
|
|
EDUCATION |
Credenziali che attestano i risultati formativi, i titoli accademici e la formazione professionale. |
|
|
HEALTH |
Credenziali relative alla copertura sanitaria, allo stato medico e alle certificazioni sanitarie. |
|
|
FINANCIAL |
Credenziali relative agli strumenti di pagamento, alle autorizzazioni finanziarie e alla prova dei pagamenti. |
|
|
CULTURE AND LEISURE |
Credenziali che attestano l'appartenenza, l'affiliazione o la partecipazione a programmi culturali o ricreativi. |
|
|
EMPLOYMENT |
Credenziali che attestano i rapporti di lavoro, lo stato professionale e i contributi. |
|
|
MOBILITY AND TRAVEL |
Credenziali che attestano i diritti di mobilità, lo stato relativo al veicolo e i diritti connessi al viaggio. |
|
|
BONUSES |
Credenziali che attestano il diritto a benefici economici, incentivi o voucher. |
|
|
Credential Class |
Supported Purposes |
|---|---|
Identification Documents |
|
Civil Registry and Personal Status Certificates |
|
Economic and Legal Status |
|
Property and Cadastral Documents |
|
Family Documents |
|
Local Tax Documents |
|
Educational Qualifications |
|
Professional Certifications |
|
Certifications and Eligibility |
|
Medical Records |
|
Payment Instruments |
|
Payment Credentials and Authorisations |
|
Public Payments and Fees |
|
Recurring Payments and Subscriptions |
|
Cultural Cards and Benefits |
|
Membership and Loyalty Programs |
|
Employment Documents |
|
Employment Status |
|
Licenses and Authorizations |
|
Vehicle Documents |
|
Transport Subscriptions |
|
Travel Documents |
|
Travel Insurance and Bookings |
|
Discounts and Benefits |
|
Economic Benefits and Allowances |
|
Incentives and Vouchers |
|
Health and Wellbeing Bonuses |
|
Employment Affiliation |
|
Ciascuna Credenziale DEVE specificare domain, class e purpose per abilitare sia gli scenari specifici della Credenziale sia gli scenari agnostici rispetto alla Credenziale secondo i requisiti della Relying Party e i pattern di richiesta di presentazione, come definito nelle tabelle di mappatura precedenti.
Scenari specifici della Credenziale (primari per i settori governativi/regolamentati): le RP richiedono tipi di Credenziale specifici per requisiti di conformità e audit, inclusi ad esempio:
Servizi governativi:
"credential_type":"pid"per la verifica di identità specifica del PID o"credential_type":"eid"per la verifica di identità specifica dell'IT-Wallet ID.Controlli di polizia:
"credential_type":"mDL"per la verifica della patente di guida.KYC bancario: tipi di Credenziale specifici imposti dalla regolamentazione finanziaria.
Servizi sanitari:
"credential_type":"european_disability_card"per l'accesso ai benefici di disabilità conformi all'UE.
Scenari agnostici rispetto alla Credenziale (tipici per le attività private): le RP richiedono claim specifici indipendentemente dalla fonte della Credenziale per l'efficienza operativa, quali:
Consegna e-commerce: qualsiasi Credenziale, tra quelle a cui è autorizzato ad accedere, contenente
given_name,family_name,addressper la spedizione.Abbonamenti: qualsiasi Credenziale, tra quelle a cui è autorizzato ad accedere, con
given_name,Personalizzazione del servizio: applicazioni business che richiedono dati personali di base senza requisiti stringenti sulla fonte.
Questo approccio consente:
Autorizzazione basata su policy utilizzando le mappature Domain / Class / Credential Type / Purpose.
Registrazione flessibile delle RP a supporto sia delle esigenze di conformità governativa sia dei requisiti operativi business.
7.3.4. Taxonomy Structure¶
La taxonomy mantiene una struttura gerarchica a quattro livelli, ossia i Domain, le Class, i Credential Type e i Purpose definiti in Digital Credentials Hierarchy sopra.
Nota
Il Credential Type è un concetto definito a livello di Digital Credentials Catalog, non all'interno della Taxonomy. La Taxonomy fornisce il vocabolario di classificazione (Domain, Class, Purpose) che i Credential Type nel Catalog referenziano.
7.3.4.1. Supporto alla localizzazione¶
La taxonomy supporta ambienti multilingue tramite il pattern di suffisso _l10n_id, consentendo una gestione efficiente della localizzazione per le interfacce utente e le implementazioni transfrontaliere.
7.3.4.2. Struttura JSON della Taxonomy¶
Field Name |
Description |
|---|---|
id |
OBBLIGATORIO. Identificativo univoco della Taxonomy (ad es., |
version |
OBBLIGATORIO. La versione della Taxonomy (ad es., |
last_modified |
OBBLIGATORIO. Il timestamp che indica quando l'elenco è stato aggiornato l'ultima volta (ad es., |
name_l10n_id |
OBBLIGATORIO. Chiave di localizzazione che referenzia il nome leggibile della Taxonomy (ad es., |
description_l10n_id |
OBBLIGATORIO. Chiave di localizzazione che referenzia la descrizione leggibile della Taxonomy (ad es., |
localization |
OBBLIGATORIO. Oggetto di configurazione della localizzazione contenente:
|
domains |
OBBLIGATORIO. Array di oggetti Domain, ciascuno contenente:
|
purposes |
OBBLIGATORIO. Array piatto di tutti gli oggetti Purpose definiti nella taxonomy, ciascuno contenente:
|
Di seguito è fornito un esempio non normativo della struttura della Taxonomy:
{
"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"
}
]
}
Nota
Per una gestione migliore e più efficiente della localizzazione della Taxonomy, un'Entità che la consulta DOVREBBE:
Scaricare la versione di base della Taxonomy (compatta, senza localizzazioni) utilizzando l'endpoint
.well-known/taxonomy.Determinare la lingua preferita dell'Utente.
Scaricare solo i bundle di localizzazione necessari.
Unire dinamicamente il contenuto localizzato con la struttura della Taxonomy.
Di seguito è fornito un esempio non normativo dell'output di un bundle di localizzazione:
{
"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",
"...": "..."
}
I bundle di localizzazione DEVONO essere disponibili all'URI composto concatenando il codice locale e .json al valore localization.base_uri definito nella taxonomy. Ciascun bundle di locale DEVE essere accessibile seguendo il pattern di naming {locale_code}.json, dove {locale_code} è sostituito con il corrispondente codice locale dell'array available_locales.
Un esempio non normativo dell'URI di localizzazione italiana per il bundle sarebbe https://trust-registry.eid-wallet.example.it/.well-known/l10n/taxonomy/it.json.
7.4. Claims Registry¶
L'URL dell'endpoint Claims Registry è pubblicato sotto la chiave claims_registry del documento Registry Discovery. L'endpoint supporta la content negotiation e la rappresentazione firmata comuni a tutti gli endpoint della Registry Infrastructure (si veda Content Negotiation and Signed Representation).
Il Claims Registry DEVE contenere:
Claim standardizzati: Definizioni semantiche per tutti gli attributi delle Credenziali con tipi di dato e regole di validazione.
Mapping di interoperabilità: Definizioni di alias per i claim che utilizzano una terminologia diversa tra gli standard (ad es., ISO18013-5
place_of_birthmappato sul canonicobirth_place).Formati di dati: Tipi di dato standardizzati (string, date, numeric, boolean, email, url, image, array, object) con pattern di validazione.
Il Claims Registry DEVE assicurare:
Coerenza semantica: Previene i conflitti tra claim duplicati o sovrapposti nell'ecosistema.
Interoperabilità transfrontaliera: Assicura la conformità UE e un'interpretazione coerente dei claim.
Validazione dello schema: Fornisce definizioni autorevoli per la validazione dei claim in tutti gli scenari di Credenziale.
Allineamento regolamentare: Si coordina con il quadro regolamentare nazionale e UE.
Scenari agnostici rispetto alla Credenziale: Supporta gli scenari in cui la convenienza dell'utente e l'efficienza operativa business sono prioritarie rispetto alla conformità regolamentare e alle piste di audit.
Nota
Il Claims Registry definisce le proprietà semantiche dei singoli attributi, ma NON DEVE specificare le capacità di selective disclosure. La selective disclosure dipende dalle implementazioni del formato della Credenziale (SD-JWT, mDocs), dalle configurazioni tecniche dell'issuer e dal contesto di presentazione. Queste capacità sono specificate a livello di tipo di Credenziale all'interno del Digital Credentials Catalog e implementate durante i flussi di presentazione delle Credenziali.
7.4.1. Claims Registry Usage¶
Come mostrato nella Figura Registries and Catalogues of the Ecosystem e nella Figura Discovery on the Registry Infrastructure, il Claims Registry DEVE supportare l'intero ciclo di vita dell'ecosistema:
7.4.1.1. Claims Registry Usage: Durante il processo di Onboarding¶
Registrazione AS: Le Fonti Autentiche dichiarano i claim disponibili dal registro standardizzato durante la registrazione delle capacità.
Registrazione CI: I Credential Issuer selezionano le entità Fonte Autentica in base ai claim richiesti. I tipi di Credenziale che utilizzano tali claim sono registrati nel catalogo dall'Attestation Scheme Provider, si veda Credential Type Registration.
Registrazione RP: Le Relying Party specificano i requisiti di autorizzazione utilizzando domain/purpose per attributi specifici dell'Utente.
7.4.1.2. Claims Registry Usage: Durante le attività operative¶
Emissione delle Credenziali: Le definizioni dei claim assicurano una rappresentazione coerente dei dati tra tipi di Credenziale diversi.
Richieste di presentazione: Le Relying Party referenziano i claim per la validazione dello schema e la verifica dell'autorizzazione sia negli scenari specifici della Credenziale sia in quelli agnostici rispetto alla Credenziale.
7.4.2. Claims Registry Structure¶
Il Claims Registry mantiene definizioni tecniche language-neutral per la coerenza semantica nell'ecosistema. Le localizzazioni rivolte all'utente per i nomi e le descrizioni dei claim sono fornite tramite bundle di localizzazione dedicati referenziati tramite il campo localization.base_uri, consentendo un supporto multilingue efficiente senza compromettere l'integrità strutturale del registro.
Field Name |
Description |
|---|---|
id |
OBBLIGATORIO. Identificativo univoco del Claims Registry (ad es., |
version |
OBBLIGATORIO. La versione del Claims Registry (ad es., |
last_modified |
OBBLIGATORIO. Il timestamp che indica quando l'elenco è stato aggiornato l'ultima volta (ad es., |
localization |
OBBLIGATORIO. Oggetto di configurazione della localizzazione contenente:
|
claims |
OBBLIGATORIO. Un oggetto JSON in cui ciascuna chiave è un nome di claim e ciascun valore è un oggetto JSON che descrive tale claim. Ciascun oggetto claim contiene i parametri definiti nella tabella "Claim Entry Parameters" seguente. |
Field Name |
Description |
|---|---|
description_l10n_id |
OBBLIGATORIO. Chiave di localizzazione che referenzia la descrizione leggibile del claim nel bundle di localizzazione (ad es., |
type |
OBBLIGATORIO. Tipo di dato del claim. Valori supportati: |
format |
OPZIONALE. Qualificatore di formato semantico per i tipi string (ad es., |
encoding |
OPZIONALE. Encoding applicato al valore (ad es., |
aliases |
OPZIONALE. Array di nomi di claim alternativi utilizzati in altri standard che mappano su questo claim canonico (ad es., |
nested_claims |
OPZIONALE. Array di nomi di claim che formano le proprietà di un claim di tipo |
nested_item_claims |
OPZIONALE. Array di nomi di claim che rappresentano le proprietà di ciascun elemento in un claim di tipo |
items |
OPZIONALE. Oggetto JSON che descrive lo schema di ciascun elemento in un claim di tipo |
attribute_identifier |
OPZIONALE. Identificativo dell'attributo corrispondente nel EUDIW Catalogue of Attributes quando il claim è allineato a quel catalogo, come descritto in Registry Integration and Cross-References. Quando presente, DEVE essere uguale all' |
Di seguito è fornito un esempio non normativo della struttura del Claims Registry:
{
"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"
}
}
}
Nota
Per una gestione migliore e più efficiente della localizzazione delle informazioni contenute nel Claims Registry, un'Entità che lo consulta DOVREBBE:
Scaricare la versione di base del Claims Registry (compatta, senza localizzazioni) utilizzando l'endpoint
.well-known/claims.Determinare la lingua preferita dell'Utente.
Scaricare solo i bundle di localizzazione necessari.
Unire dinamicamente il contenuto localizzato con la struttura del Claims Registry.
Di seguito è fornito un esempio non normativo dell'output di un bundle di localizzazione:
{
"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.",
"...": "..."
}
I bundle di localizzazione DEVONO essere disponibili all'URI composto concatenando il codice locale e .json al valore localization.base_uri (ad es., https://trust-registry.eid-wallet.example.it/.well-known/l10n/claims/it.json).
7.5. Authentic Source Registry¶
L'URL dell'endpoint Authentic Source Registry è pubblicato sotto la chiave authentic_sources del documento Registry Discovery. L'endpoint supporta la content negotiation e la rappresentazione firmata comuni a tutti gli endpoint della Registry Infrastructure (si veda Content Negotiation and Signed Representation).
L'Authentic Source Registry DEVE contenere almeno:
Informazioni sull'organizzazione: Dettagli della persona giuridica, status regolamentare e ruolo autorevole all'interno di domain specifici.
Capacità dati: Disponibilità dei claim dichiarati con riferimento alle definizioni standardizzate del Claims Registry con le corrispondenti classificazioni della Taxonomy.
Metodi di integrazione: Meccanismi tecnici di accesso (PDND).
Scopi previsti: Tipi di Credenziale supportati e contesti business per il coordinamento AS-CI.
Assicurazione della qualità dei dati: Status autorevole, frequenza di aggiornamento e capacità di pista di audit.
L'Authentic Source Registry DEVE assicurare:
Accesso coordinato ai dati: Consente al CI la discovery dei dati appropriati dalle Fonti Autentiche per l'emissione delle Credenziali.
Integrazione AS-CI: Gli endpoint tecnici e i metodi di accesso consentono una comunicazione AS-CI standardizzata. Facilita i workflow di approvazione e il coordinamento dell'accesso ai dati tra le entità.
Conformità regolamentare: Supporta i requisiti di trasparenza della pubblica amministrazione e di coordinamento del settore privato.
Nota
L'Authentic Source Registry è un registro pubblico che fornisce al Credential Issuer indicazioni per il provisioning delle Credenziali.
7.5.1. Authentic Source Registry Usage¶
Come mostrato nella Figura Registries and Catalogues of the Ecosystem e nella Figura Discovery on the Registry Infrastructure, l'Authentic Source Registry supporta il coordinamento dell'ecosistema durante l'intero ciclo di vita operativo:
- Durante il processo di Onboarding:
Auto-dichiarazione AS: Le Fonti Autentiche registrano le capacità prima che esistano tipi di Credenziale nel catalogo.
Discovery CI: I Credential Issuer cercano entità Fonte Autentica in base ai claim richiesti e ai tipi di Credenziale previsti.
7.5.1.1. Authentic Source Registry Usage: Durante le attività operative¶
Emissione delle Credenziali: I sistemi del Credential Issuer referenziano l'Authentic Source Registry per l'accesso ai dati in tempo reale durante l'emissione delle Credenziali.
7.5.2. Authentic Source Registry Structure¶
Durante la registrazione, le Fonti Autentiche dichiarano le proprie capacità prima che esistano tipi di Credenziale nel catalogo. Questa dichiarazione costituisce il fondamento per la successiva registrazione dei CI e la creazione dei tipi di Credenziale.
7.5.2.1. Schema dell'identificativo univoco della Fonte Autentica¶
A ciascuna Fonte Autentica DEVE essere assegnato un identificativo univoco che segue lo schema URL HTTPS definito di seguito. Questo identificativo è utilizzato per referenziare le entità AS nel sistema di registro e nel Digital Credentials Catalog, assicurando coerenza con i pattern di identificazione delle entità OpenID Federation.
Schema dell'identificativo AS:
https://{organization_domain}[/{optional_path}]
Componenti dello schema:
organization_domain: Dominio DNS controllato dall'organizzazione
optional_path: Componente di path aggiuntivo per servizi o dipartimenti specifici
L'identificativo AS DEVE seguire queste regole normative:
Protocollo HTTPS: DEVE utilizzare lo schema HTTPS per la verifica di sicurezza e trust
Titolarità del dominio: L'organizzazione DEVE controllare il dominio DNS utilizzato nell'identificativo
Univocità: Garantita tramite l'univocità del namespace DNS
Stabilità: DOVREBBE rimanere stabile nel tempo per evitare la rottura dei riferimenti
Risolvibilità: L'URL DOVREBBE essere risolvibile (sebbene non sia richiesto che serva contenuto)
Esempi di identificativi AS conformi:
https://motorizzazione.gov.example: Pubblico - Ministero dei Trasporti, Dip. Motorizzazionehttps://registry.anpr.example: Pubblico - Anagrafe Nazionale della Popolazione Residentehttps://api.bank.example/auth-source: Privato - Servizi finanziari Banca Esempio
7.5.2.2. Parametri dell'Authentic Source Registry¶
L'Authentic Source Registry DEVE contenere i seguenti parametri per ciascuna Fonte Autentica registrata:
Field Name |
Description |
|---|---|
id |
OBBLIGATORIO. Identificativo univoco dell'Authentic Source Registry (ad es., |
version |
OBBLIGATORIO. La versione dell'Authentic Source Registry (ad es., |
last_modified |
OBBLIGATORIO. Il timestamp che indica quando l'elenco è stato aggiornato l'ultima volta (ad es., |
localization |
OBBLIGATORIO. Oggetto di configurazione della localizzazione contenente:
|
authentic_sources |
OBBLIGATORIO. Un array JSON in cui ciascuna voce è un oggetto JSON che rappresenta un'entità Fonte Autentica. Ciascun oggetto contiene i parametri definiti nella tabella "Authentic Sources Parameters" seguente, compresi identificazione dell'entità, informazioni organizzative, capacità dati e metodi di integrazione. |
Parameter |
Type |
Description |
|---|---|---|
entity_id |
string |
OBBLIGATORIO. Identificativo univoco che segue lo schema normativo: |
organization_info |
JSON object |
OBBLIGATORIO. Dettagli della persona giuridica e metadata organizzativi. |
organization_info.organization_name_l10n_id |
string |
OBBLIGATORIO. Chiave di localizzazione che referenzia il nome localizzato dell'organizzazione nel bundle di localizzazione (ad es., |
organization_info.organization_type |
string |
OBBLIGATORIO. Classificazione dell'entità: |
organization_info.ipa_code |
string |
OBBLIGATORIO solo per AS pubbliche. Codice di registrazione IPA per le entità governative. |
organization_info.legal_identifier |
string |
OBBLIGATORIO. Identificativo di registrazione legale (Codice Fiscale/Partita IVA, o identificativo nazionale equivalente per le entità estere). |
organization_info.homepage_uri |
string |
OBBLIGATORIO. URL che punta alla homepage dell'organizzazione. |
organization_info.contacts |
String Array |
OBBLIGATORIO. Array di indirizzi e-mail di contatto per almeno un supporto utente, un'applicazione e uno specialista di sistemi. |
organization_info.dpa_contact |
string |
OBBLIGATORIO. Un indirizzo e-mail del DPA della Fonte Autentica. |
organization_info.policy_uri |
string |
OBBLIGATORIO. URL del documento di informativa sulla privacy. |
organization_info.tos_uri |
string |
OPZIONALE. URL del documento dei termini di servizio. |
organization_info.organization_country |
string |
OBBLIGATORIO. Codice paese ISO 3166-1 alpha-2 a due lettere dell'organizzazione. |
organization_info.logo_uri |
string |
OPZIONALE. URL dell'immagine del logo dell'organizzazione. |
organization_info.logo_uri#integrity |
string |
Digest crittografico della risorsa immagine del logo per la verifica di integrità. OBBLIGATORIO se |
organization_info.logo_alt_text_l10n_id |
string |
OPZIONALE. Testo alternativo per l'immagine del logo dell'organizzazione. |
organization_info.logo_extended_uri |
string |
OPZIONALE. URL dell'immagine del logo esteso dell'organizzazione. |
organization_info.logo_extended_uri#integrity |
string |
Digest crittografico della risorsa immagine del logo esteso per la verifica di integrità. OBBLIGATORIO se |
organization_info.logo_extended_alt_text_l10n_id |
string |
OPZIONALE. Testo alternativo per l'immagine del logo esteso dell'organizzazione. |
data_capabilities |
JSON Objects Array |
OBBLIGATORIO. Array contenente le specifiche delle capacità dati. |
data_capabilities[].dataset_id |
string |
OBBLIGATORIO. Il Dataset_id nell'ambito della Fonte Autentica, che PUÒ essere utilizzato come parametro di query per il servizio |
data_capabilities[].data_origin_l10n_id |
string |
OBBLIGATORIO. Chiave di localizzazione che referenzia il nome leggibile dell'origine dei dati o del dipartimento che fornisce i dati (ad es., |
data_capabilities[].intended_purposes |
String Array |
OBBLIGATORIO. Scopi business serviti, utilizzando gli identificativi di purpose della taxonomy (ad es., |
data_capabilities[].available_claims |
String Array |
OBBLIGATORIO. Claim disponibili da questa capacità dati. |
data_capabilities[].available_claims.claim_name |
string |
OBBLIGATORIO. Contiene il nome del claim. |
data_capabilities[].available_claims.order |
number |
OBBLIGATORIO. Definisce l'ordine in cui le informazioni sarebbero mostrate. |
data_capabilities[].available_claims.mandatory |
boolean |
OBBLIGATORIO. Definisce se un claim è sempre disponibile o meno. |
data_capabilities[].integration_method |
string |
OBBLIGATORIO. Framework di autorizzazione utilizzato per l'accesso ai dati. DEVE essere |
data_capabilities[].integration_endpoint |
string |
OPZIONALE. Punto di accesso al servizio (endpoint PDND). |
data_capabilities[].api_specification |
string |
OPZIONALE. URL del documento di specifica OAS3 per questa capacità dati. |
data_capabilities[].data_provision |
JSON object |
OPZIONALE. Capacità di fornitura dei dati e specifiche di tempistica. |
data_capabilities[].data_provision.immediate_flow |
boolean |
OBBLIGATORIO. Indica se la Fonte Autentica supporta la fornitura immediata dei dati. |
data_capabilities[].data_provision.deferred_flow |
boolean |
OBBLIGATORIO. Indica se la Fonte Autentica supporta la fornitura differita dei dati. |
data_capabilities[].data_provision.max_response_time_minutes |
integer |
Tempo massimo in minuti per la Fonte Autentica per rispondere a una richiesta di fornitura dati differita. OBBLIGATORIO se |
data_capabilities[].data_provision.notification_methods |
String Array |
Array dei metodi di notifica supportati dalla Fonte Autentica per la fornitura dati differita, quali |
data_capabilities[].user_information_l10n_id |
string |
OPZIONALE. Chiave di localizzazione che referenzia una stringa formattata in Markdown con informazioni leggibili sulla capacità dati rilevanti per l'Utente (ad es., |
data_capabilities[].service_documentation_uri |
string |
OPZIONALE. URL che punta alla documentazione del servizio della Fonte Autentica. |
data_capabilities[].update_frequency |
string |
OPZIONALE. Indica con quale frequenza la Fonte Autentica aggiorna i propri dati. Valori possibili: |
data_capabilities[].logo_uri |
string |
OPZIONALE. URL dell'immagine del logo relativa ai dati. |
data_capabilities[].logo_uri#integrity |
string |
Digest crittografico della risorsa immagine del logo per la verifica di integrità. OBBLIGATORIO se |
data_capabilities[].logo_alt_text_l10n_id |
string |
OPZIONALE. Testo alternativo per l'immagine del logo dell'organizzazione. |
data_capabilities[].background_color |
string |
OPZIONALE. Valore stringa del colore di sfondo da visualizzare insieme ai dati. |
data_capabilities[].contacts |
String Array |
OPZIONALE. Array di contatti del servizio clienti o canali di supporto utente (ad es., indirizzo e-mail). |
data_capabilities[].verification_endpoint |
JSON object |
OPZIONALE. Presente solo per gli attributi dell'Annex VI che fanno affidamento su una Fonte Autentica del settore pubblico e che sono esportati nel EUDIW Catalogue of Attributes. Descrive l'interfaccia di verifica transfrontaliera esposta ai Qualified Trust Service Provider, distinta dall'e-Service PDND nazionale e conforme a ETSI TS 119 478. Contiene |
Nota
Per ulteriori dettagli sulle funzionalità richieste e sull'esito atteso in termini di esperienza utente, si veda la Sezione Ottenimento dal Catalogo dell'Istanza del Wallet per il parametro data_capabilities.user_information e la Sezione Focus sugli Attestati Elettronici di Attributi per i parametri organization_info.logo_uri, organization_info.logo_extended_uri, data_capabilities.logo_uri, data_capabilities.background_color e data_capabilities.available_claims.order.
7.5.2.3. Esempio di Authentic Source Registry¶
Di seguito è fornito un esempio non normativo della struttura dell'AS Registry:
{
"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"
}
]
}
]
}
Nota
Per una gestione migliore e più efficiente della localizzazione delle informazioni contenute nell'Authentic Source Registry, un'Entità che lo consulta DOVREBBE:
Scaricare la versione di base dell'Authentic Source Registry (compatta, senza localizzazioni) utilizzando l'endpoint
.well-known/authentic-sources.Determinare la lingua preferita dell'Utente.
Scaricare solo i bundle di localizzazione necessari.
Unire dinamicamente il contenuto localizzato con la struttura dell'Authentic Source Registry.
Di seguito è fornito un esempio non normativo dell'output di un bundle di localizzazione:
{
"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.",
"...": "..."
}
I bundle di localizzazione DEVONO essere disponibili all'URI composto concatenando il codice locale e .json al valore localization.base_uri definito nel registro. Ciascun bundle di locale DEVE essere accessibile seguendo il pattern di naming {locale_code}.json, dove {locale_code} è sostituito con il corrispondente codice locale dell'array available_locales.
Un esempio non normativo dell'URI di localizzazione italiana per il bundle sarebbe https://trust-registry.eid-wallet.example.it/.well-known/l10n/authentic-sources/it.json.
7.6. Schema Registry¶
Lo Schema Registry è l'inventario autorevole di tutti gli Schema delle Credenziali noti e accettati (JSON Schema per SD-JWT, CBOR Schema per mDOC) all'interno dell'ecosistema IT-Wallet.
7.6.1. Schema Registry Objectives¶
Centralizzazione degli schema: Fornire un punto di accesso centralizzato per tutti gli schema tecnici utilizzati dagli Attestati Elettronici.
Integrità e autenticità: Assicurare l'integrità e l'autenticità dei documenti di schema tramite digest crittografici.
Interoperabilità: Facilitare l'integrazione senza soluzione di continuità dei Fornitori di Wallet e delle Relying Party fornendo versioni di schema coerenti.
Supporto al ciclo di vita delle Credenziali: Agire come punto di riferimento verificabile per la validazione dello schema durante l'emissione e la presentazione.
7.6.2. Utilizzo dello Schema Registry¶
Come mostrato nella Figura Registries and Catalogues of the Ecosystem e nella Figura Discovery on the Registry Infrastructure, le principali Entità che interagiscono con lo Schema Registry sono:
Attestation Scheme Provider: Forniscono lo schema di un tipo di Credenziale, o il suo allineamento allo schema di un Rulebook esterno, e il Sistema di Onboarding lo registra con il suo digest di integrità durante lo Schema Provisioning.
Credential Issuer: Utilizzano lo Schema Registry per costruire i propri metadata e per emettere gli Attestati Elettronici secondo lo schema registrato.
Relying Party: Utilizzano lo Schema Registry per raccogliere tutte le informazioni necessarie sugli Attestati Elettronici che intendono richiedere durante la fase di presentazione.
Fornitori di Wallet: Accedono allo Schema Registry per recuperare tutte le informazioni necessarie per integrarli nelle proprie Soluzioni Wallet.
7.6.3. Catalogo delle Attestazioni¶
Il valore schema_registry nel documento Registry Discovery è la radice dell'API del Catalogue of Attestations.
Il Federation Trust Anchor DEVE implementare la Section 5 di [EUDI-TS 11] e il documento OpenAPI dell'Annex A.3 ([EUDI-TS 11 OpenAPI]).
Ciascuno schema di attestazione DEVE essere un oggetto SchemaMeta come definito nella Section 4.3 di [EUDI-TS 11]. Lo schema DEVE essere valido rispetto allo JSON Schema dell'Annex A.2 ([EUDI-TS 11 Attestation Schema]).
L'oggetto NON DEVE contenere proprietà esterne a quello schema.
La radice dell'API ha questi path:
GET /schemaselenca gli schema con i parametri di query dell'Annex A.3.GET /schemas/{schemaId}restituisce uno schema.schemaIdè l'iddelloSchemaMeta.PUT /schemas/{schemaId}sostituisce uno schema.DELETE /schemas/{schemaId}elimina uno schema.
id DEVE essere un UUID assegnato dal Federation Trust Anchor alla prima registrazione dello schema.
version DEVE seguire il semantic versioning. La prima versione pubblicata DEVE essere 1.0.0.
supportedFormats e ciascun elemento di schemaURIs DEVONO usare gli identificativi di formato della Section 4.3 di [EUDI-TS 11].
Il documento di schema specifico del formato servito a schemaURIs[].uri DEVE seguire la Section 4.3.4 di [EUDI-TS 11].
Un rulebookURI o un schemaURIs[].uri PUÒ recare un suffisso #integrity. Il valore del suffisso DEVE essere integrity metadata come definito nella Section 3 di [W3C-SRI]. Quando il suffisso è presente, il consumatore DEVE verificare il documento come definito nella Section 3.3.5 di [W3C-SRI].
Il frameworkType openid_federation DEVE essere usato solo per un EAA non qualificato.
isLoTE DEVE seguire la Section 4.3.3 di [EUDI-TS 11].
L'Attestation Rulebook di una QEAA o di una PuB-EAA DEVE essere pubblicato come richiesto dalla Section 4.2 di [EUDI-TS 11].
La pubblicazione del rulebook di un EAA è RACCOMANDATO.
7.6.3.1. List of schemas¶
GET /schemas DEVE essere disponibile senza autenticazione.
La risposta DEVE essere HTTP 200 quando la query è valida.
Il payload del JWT DEVE contenere iss, iat e data.
data DEVE contenere total, limit, offset e data.
L'array data interno contiene gli oggetti SchemaMeta corrispondenti.
iss DEVE identificare il Federation Trust Anchor.
iat DEVE essere il tempo Unix in cui il JWT è stato emesso, come definito in RFC 7519.
Quando limit è assente, si applica il valore 20.
Quando offset è assente, si applica il valore 0.
Quando non è presente alcun filtro, l'insieme dei risultati è ogni schema registrato, restituito a partire da offset per al massimo limit elementi.
Il Federation Trust Anchor DEVE ordinare tale insieme per id crescente.
Un client che richiede ogni schema corrispondente DEVE richiedere la pagina successiva aumentando offset di limit fino a quando offset è maggiore o uguale a total.
Il Federation Trust Anchor DEVE rispondere con HTTP 400 quando la query non è conforme all'Annex A.3.
Una risposta application/jwt con esito positivo DEVE includere l'header x-jku-url. Il suo valore DEVE essere l'URI HTTPS del JSON Web Key Set usato per verificare la firma.
La stessa risposta DEVE essere disponibile anche come application/json secondo Content Negotiation and Signed Representation. Il corpo JSON è il payload del JWT.
L'esempio non normativo seguente è una pagina di 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} DEVE essere disponibile senza autenticazione.
Il Federation Trust Anchor DEVE rispondere con HTTP 200 e un JWS il cui payload è lo SchemaMeta corrispondente quando schemaId esiste.
Il Federation Trust Anchor DEVE rispondere con HTTP 404 quando schemaId non esiste.
La risposta JWT DEVE includere x-jku-url come specificato per l'elenco.
7.6.3.3. Update and deletion¶
PUT /schemas/{schemaId} e DELETE /schemas/{schemaId} DEVONO essere accettati solo da un rappresentante autenticato dell'Attestation Scheme Provider che ha registrato lo schema, come richiesto dalla Section 4.5.3 e dalla Section 5.2.2 di [EUDI-TS 11].
Il corpo della richiesta PUT DEVE essere lo SchemaMeta completo.
Un PUT con esito positivo DEVE rispondere con HTTP 200 e lo SchemaMeta memorizzato come application/json, come specificato nell'Annex A.3. Questa risposta non è selezionata dalla content negotiation che si applica al GET.
Un DELETE con esito positivo DEVE rispondere con HTTP 204.
Il Federation Trust Anchor DEVE rispondere con HTTP 401 quando il chiamante non è autenticato.
Il Federation Trust Anchor DEVE rispondere con HTTP 403 quando il chiamante autenticato non è un rappresentante dell'Attestation Scheme Provider che ha registrato lo schema.
Il Federation Trust Anchor DEVE rispondere con HTTP 404 quando schemaId non esiste.
La Section 5.2.2 di [EUDI-TS 11] lascia il meccanismo di autenticazione della Commissione a una versione successiva. Fino a quando quel meccanismo è definito, il Sistema di Onboarding è il rappresentante che il Federation Trust Anchor DEVE accettare per questi due metodi.
L'implementazione di GET /schemas DEVE tenere conto delle vulnerabilità descritte nella Section 5.4 di [EUDI-TS 11].
L'implementazione DOVREBBE applicare le misure della Section 5.5 e della Section 5.6 di [EUDI-TS 11].
7.7. Catalogo degli Attestati Elettronici¶
Il Digital Credentials Catalog è il registro di tutti gli Attestati Elettronici disponibili riconosciuti all'interno dell'ecosistema IT-Wallet. Agisce come singolo punto di riferimento per tutti gli attori coinvolti nel processo di emissione, verifica e utilizzo degli Attestati Elettronici. Il Digital Credentials Catalog DEVE contenere almeno:
Information related to |
Description |
|---|---|
Digital Credential Metadata |
Informazioni identificative essenziali e caratteristiche dell'Attestato Elettronico, compresi:
|
Digital Credential Issuers |
Dettagli sull'organizzazione autorizzata a emettere l'Attestato Elettronico, quali:
|
Authentic Sources |
Informazioni sulla fonte dati autorevole. |
Technical Specification |
Dettagli tecnici, compresi:
|
Terms of Use |
Condizioni e limitazioni per l'utilizzo dell'Attestato Elettronico, quali:
|
Il Digital Credentials Catalog DEVE assicurare di:
Facilitare la discovery degli Attestati Elettronici per gli Utenti.
Standardizzare la descrizione tecnica e funzionale degli Attestati Elettronici.
Abilitare l'interoperabilità tra Issuer e Relying Party diversi.
Semplificare il processo di integrazione per i Fornitori di Wallet e le Relying Party.
Assicurare la trust nell'ecosistema tramite informazioni verificabili e affidabili.
Fornire trasparenza sull'ecosistema degli Attestati Elettronici disponibili.
7.7.1. Digital Credentials Catalog Usage¶
Come mostrato nella Figura Registries and Catalogues of the Ecosystem e nella Figura Discovery on the Registry Infrastructure, le principali Entità coinvolte nel Digital Credentials Catalog sono:
Attestation Scheme Provider: Le Entità che possiedono l'Attestation Rulebook di un Attestato Elettronico e che richiedono la registrazione della corrispondente voce versionata, si veda Attestation Scheme Provider.
Digital Credential Issuer: Sono aggiunti al campo
issuersdi una voce versionata come risultato degli Attestati Elettronici che dichiarano nei propri dati di registrazione.Relying Party: Utilizzano il Digital Credentials Catalog per raccogliere tutte le informazioni necessarie sugli Attestati Elettronici che intendono richiedere durante la fase di presentazione.
Fornitori di Wallet: Accedono al Digital Credentials Catalog per identificare gli Attestati Elettronici disponibili e per recuperare tutte le informazioni necessarie per integrarli nelle proprie Soluzioni Wallet.
Utenti: Gli Utenti che utilizzano indirettamente il Digital Credentials Catalog tramite le proprie Istanze del Wallet per scoprire e richiedere Attestati Elettronici.
Fonti Autentiche: Sono referenziate dalla voce versionata come sua fonte dati e agiscono come Attestation Scheme Provider quando possiedono l'Attestation Rulebook.
Una voce versionata non è fornita da una singola Entità. I suoi campi provengono da fonti diverse e sono scritti in fasi di onboarding diverse, come sintetizzato nella tabella seguente. I Data Identifier che recano queste informazioni attraverso l'onboarding, e la loro mappatura sui campi della voce, sono definiti in Registration Data Model.
Fields |
Provided by |
Process |
|---|---|---|
|
L'Attestation Scheme Provider, che trae i valori dall'Attestation Rulebook che possiede |
|
|
L'Attestation Scheme Provider, referenziando le voci dell'Authentic Source Registry o un tipo di Credenziale già registrato |
|
|
L'Attestation Scheme Provider, tramite lo |
|
|
Ciascun elemento deriva dagli Attestati Elettronici che un Credential Issuer dichiara nei propri dati di registrazione, con le capacità di emissione che offre per ciascuno di essi |
|
|
Non fornito. Deriva dalle condizioni della voce versionata |
La registrazione della voce versionata è approvata dall'Organismo di Supervisione, come descritto in Eligibility and Compliance Preconditions, è scritta dal Sistema di Onboarding ed è pubblicata dal Federation Trust Anchor con il resto del catalogo.
Nota
Lo schema è la definizione machine-readable di un tipo di Attestato, che a livello UE è registrata nel Catalogue of Schemes e che a livello nazionale corrisponde alla voce versionata del Digital Credentials Catalog. Il Credential Schema è lo JSON Schema o lo CBOR Schema che valida la struttura dell'Attestato Elettronico, ed è registrato nello Schema Registry. L'Attestation Scheme Provider possiede il primo e fornisce il secondo come parte della specifica tecnica del tipo di Credenziale.
7.7.2. Digital Credentials Catalog Retrieval¶
Il Federation Trust Anchor DEVE pubblicare il Digital Credentials Catalog come due risorse HTTP. Entrambe le risorse usano la content negotiation e la rappresentazione firmata comuni a tutti gli endpoint della Registry Infrastructure (si veda Content Negotiation and Signed Representation).
L'URL della collection è l'URL assoluto pubblicato sotto la chiave credential_catalog del documento Registry Discovery.
L'URL della entry è l'URL della collection con due segmenti di path aggiunti, il credential_type e la version di una voce versionata.
Un client DEVE costruire l'URL della entry a partire da quell'URL di collection.
Entrambi i segmenti di path DEVONO essere percent-encoded come definito in RFC 3986.
Una risposta con esito positivo di ciascuna risorsa è un JWS in compact serialization. I parametri di header DEVONO essere quelli definiti nella tabella corrispondente. Il Federation Trust Anchor DEVE firmare ciascuna risposta per proprio conto. Una scrittura che modifica una voce versionata non richiede una nuova firma sulle voci versionate che la scrittura ha lasciato invariate.
Il metodo di elenco e il metodo di lettura della singola voce seguono la Section 5.3.1 di [EUDI-TS 11]. La risposta reca la voce versionata nazionale definita in Digital Credentials Catalog Structure.
7.7.2.1. Collection¶
L'endpoint di collection DEVE accettare HTTP GET sull'URL della collection. Il Federation Trust Anchor DEVE rispondere con HTTP 200 a una richiesta di collection valida.
La richiesta PUÒ includere i parametri di query in Query Parameters of the Digital Credentials Catalog Collection.
limit e offset seguono la Section 5.3.1 di [EUDI-TS 11].
attestationLoS, bindingType, trustedAuthoritiesFrameworkType, trustedAuthoritiesValue e rulebookUri sono i filtri di quella sezione che corrispondono a un campo della voce versionata nazionale.
credential_type e state selezionano la stessa voce.
La risposta di collection DEVE includere una voce versionata solo quando quella voce corrisponde a ogni filtro fornito.
Il Federation Trust Anchor DEVE rispondere con HTTP 400 quando la richiesta ripete un parametro di query, contiene un parametro di query non elencato in Query Parameters of the Digital Credentials Catalog Collection, o contiene un valore che non soddisfa quel parametro.
Il Federation Trust Anchor DEVE ordinare le voci corrispondenti secondo l'ordine dei code point Unicode di credential_type e, a parità di credential_type, secondo l'ordine dei code point Unicode di version.
L'array credentials DEVE contenere le voci corrispondenti in quell'ordine, a partire dalle voci successive a offset. L'array credentials DEVE contenere al massimo limit voci.
Quando nessuna voce versionata corrisponde, o quando offset è maggiore o uguale a total, credentials DEVE essere un array vuoto. In quello stesso caso, total DEVE essere il numero di voci corrispondenti.
Un client NON DEVE trattare credentials come l'insieme di tutte le voci versionate del catalogo.
Il client che richiede ogni voce corrispondente DEVE richiedere la pagina successiva aumentando offset di limit fino a quando offset è maggiore o uguale a total.
Parameter |
Description |
|---|---|
|
OPZIONALE. Numero massimo di voci versionate restituite in |
|
OPZIONALE. Numero di voci corrispondenti da saltare prima di questa pagina. Quando è assente, si applica il valore 0. Il valore DEVE essere un intero maggiore o uguale a 0. |
|
OPZIONALE. Corrispondenza esatta su |
|
OPZIONALE. Corrispondenza esatta su |
|
OPZIONALE. Corrispondenza esatta su |
|
OPZIONALE. Corrispondenza esatta su |
|
OPZIONALE. La voce corrisponde quando almeno un oggetto di |
|
OPZIONALE. La voce corrisponde quando almeno un oggetto di |
|
OPZIONALE. Corrispondenza esatta su |
L'esempio non normativo seguente richiede la prima pagina delle voci attive.
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...
Il payload di una risposta di collection con esito positivo DEVE contenere i campi in First-level Fields of a Collection Response.
7.7.2.2. Entry¶
L'endpoint di entry DEVE accettare HTTP GET sull'URL della entry.
Il path identifica la voce versionata il cui credential_type e la cui version sono i due segmenti di path.
Il Federation Trust Anchor DEVE rispondere con HTTP 200 quando quella coppia esiste.
Il Federation Trust Anchor DEVE rispondere con HTTP 404 quando nessuna voce versionata ha quella coppia.
Field Name |
Description |
|---|---|
iss |
OBBLIGATORIO. Identificativo dell'issuer. DEVE essere lo stesso valore di |
iat |
OBBLIGATORIO. Si veda |
localization |
OBBLIGATORIO. L'oggetto di localizzazione definito per la risposta di collection. |
credential |
OBBLIGATORIO. La voce versionata identificata dal path. I suoi campi sono quelli in First-level Fields of Each Credential Entry. |
L'esempio non normativo seguente richiede una voce versionata. Il membro credential è abbreviato.
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¶
Questa sezione definisce il payload della risposta di collection e i campi di ciascuna voce versionata. Il payload della collection contiene i seguenti parametri.
Field Name |
Description |
|---|---|
id |
OBBLIGATORIO. Identificativo univoco del Digital Credentials Catalog (ad es., |
version |
OBBLIGATORIO. La versione del Digital Credentials Catalog (ad es., |
last_modified |
OBBLIGATORIO. Il timestamp che indica quando il contenuto del catalogo è stato aggiornato l'ultima volta (ad es., |
iss |
OBBLIGATORIO. Identificativo dell'issuer del Digital Credentials Catalog. |
iat |
OBBLIGATORIO. Tempo Unix in cui questo JWT di risposta è stato emesso, come definito in RFC 7519. |
localization |
OBBLIGATORIO. Oggetto di configurazione della localizzazione contenente:
|
total |
OBBLIGATORIO. Intero. Numero di voci versionate che corrispondono alla richiesta, prima che siano applicati |
limit |
OBBLIGATORIO. Intero. La dimensione di pagina applicata a questa risposta. |
offset |
OBBLIGATORIO. Intero. Il numero di voci corrispondenti saltate prima di questa pagina. |
credentials |
OBBLIGATORIO. Array delle voci versionate di questa pagina. Il numero di elementi DEVE essere minore o uguale a |
Ciascun elemento dell'array credentials contiene almeno le seguenti informazioni:
Field Name |
Description |
|---|---|
version |
OBBLIGATORIO. Versione della definizione dell'Attestato Elettronico. |
credential_type |
OBBLIGATORIO. Identificativo univoco del tipo di Attestato Elettronico. Per il PID DEVE essere |
schemaId |
OBBLIGATORIO. UUID dello |
state |
OBBLIGATORIO. Stato di questa voce versionata del tipo di Credenziale. DEVE essere uno tra:
Una sola voce versionata dello stesso |
credential_name_l10n_id |
OBBLIGATORIO. Chiave di localizzazione che referenzia il nome leggibile dell'Attestato Elettronico nel bundle di localizzazione (ad es., |
legal_type |
OBBLIGATORIO. Classificazione legale della Credenziale (ad es., |
restriction_policy |
OPZIONALE. Restrizioni legali sulle Soluzioni Wallet e/o sui Credential Issuer autorizzati a richiedere/emettere l'Attestato Elettronico.
|
pricing_policy |
OPZIONALE. Informazioni sul prezzo dell'Attestato Elettronico, comprese:
|
validity_info |
OBBLIGATORIO. Informazioni sulla validità dell'Attestato Elettronico, comprese almeno:
|
authentication |
OBBLIGATORIO. Requisiti di autenticazione dell'Attestato Elettronico.
|
domains |
OBBLIGATORIO. Array di ID di domain a cui l'Attestato Elettronico appartiene (ad es., |
classes |
OBBLIGATORIO. Array di ID di class a cui l'Attestato Elettronico appartiene (ad es., |
purposes |
OBBLIGATORIO. Array di ID di scopo di utilizzo per i quali l'Attestato Elettronico può essere utilizzato, che definiscono contesti di utilizzo specifici e i claim richiesti per ciascun purpose (ad es., |
issuers |
È OBBLIGATORIO solo se state è
|
authentic_sources |
È OBBLIGATORIO solo se
|
parent_credentials |
È OBBLIGATORIO solo se |
trustedAuthorities |
OBBLIGATORIO. Array di oggetti JSON che risolvono i trust anchor applicabili, contenenti:
Il Nota L'uso di |
rulebookURI |
OBBLIGATORIO. URI dell'Attestation Rulebook in forma leggibile che definisce tutti gli aspetti non machine-readable del tipo di Attestato Elettronico. |
bindingType |
OBBLIGATORIO. Indica il tipo di associazione crittografica della chiave richiesto per l'emissione dell'Attestato Elettronico. Il valore consentito è una stringa dall'insieme di: |
attestationLoS |
OBBLIGATORIO. Livello di sicurezza (LoS) a cui l'Attestato Elettronico deve essere fornito. Il valore consentito è una stringa dall'insieme di: |
Nota
Mentre min_loa nel claim authentication specifica i requisiti di autenticazione dell'Attestato Elettronico con riferimento al livello di garanzia del mezzo di identificazione elettronica richiesto durante l'autenticazione dell'utente nel processo di emissione, il claim attestationLoS integra questo requisito specificando la resistenza al potenziale di attacco sia per l'autenticazione dell'utente sia per l'archiviazione delle chiavi.
Nota
L'unione di credential_type e version DEVE essere univoca nel Credential Catalog.
L'esempio non normativo seguente è una pagina di una risposta di collection, decodificata in JSON sia per l'header sia per il 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"
}
]
}
Nota
Per una gestione migliore e più efficiente della localizzazione delle informazioni contenute nel Digital Credentials Catalog, un'Entità che lo consulta DOVREBBE:
Richiedere le pagine di collection di cui ha bisogno, o una voce versionata, come specificato in Digital Credentials Catalog Retrieval.
Determinare la lingua preferita dell'Utente.
Scaricare solo i bundle di localizzazione necessari.
Unire dinamicamente il contenuto localizzato con la voce del catalogo.
Di seguito è fornito un esempio non normativo dell'output di un bundle di localizzazione:
{
"mDL.name": "Patente di Guida",
"mDL.issuer1.name": "Esempio di Credential Issuer",
"...": "..."
}
I bundle di localizzazione DEVONO essere disponibili all'URI composto concatenando il codice locale e .json al valore localization.base_uri definito nel catalogo. Ciascun bundle di locale DEVE essere accessibile seguendo il pattern di naming {locale_code}.json, dove {locale_code} è sostituito con il corrispondente codice locale dell'array available_locales.
Un esempio non normativo dell'URI di localizzazione italiana per il bundle sarebbe https://trust-registry.eid-wallet.example.it/.well-known/l10n/credential-catalog/it.json.
7.7.4. Decentralization of Display and Claim Information¶
La fonte canonica per le caratteristiche di visualizzazione e la struttura dei claim è determinata dai Metadata del Credential Issuer.
La logica complessiva per presentare un Attestato Elettronico è la seguente:
A seconda del Trust Framework richiesto, il Wallet o la Relying Party recupera le voci versionate applicabili dal Catalogo degli Attestati Elettronici, per entrambi gli Attestati Elettronici gestiti da Credential Issuer ancorati nel National o nel Trust Framework EUDIW, per scoprire i credential_type disponibili e l'entity_id dei loro Credential Issuer. Il recupero usa l'endpoint di collection o di entry specificato in Digital Credentials Catalog Retrieval.
Recupera i Metadata completi del Credential Issuer (si veda Metadata per openid_credential_issuer) come descritto nella Section 12.2.2 di OpenID4VCI.
I Metadata del Credential Issuer DEVONO contenere le caratteristiche di visualizzazione complete (loghi, colori) e le informazioni dettagliate di schema (tramite link ai Type Metadata appropriati o direttamente nella configurazione). L'Issuer costruisce questi metadata sulla base dei suggerimenti forniti dalla Fonte Autentica (tramite l'AS Registry) e delle specifiche di schema standard (tramite lo Schema Registry).
7.8. Registry Integration and Cross-References¶
Come mostrato nella Figura Relationships between National Registries, i componenti del registro sono interconnessi e collaborano per supportare l'intero ecosistema delle Credenziali:
AS Registry ↔ Taxonomy: Le Fonti Autentiche dichiarano le capacità utilizzando le classificazioni della taxonomy per una categorizzazione standardizzata.
AS Registry ↔ Claims Registry: Le Fonti Autentiche dichiarano le capacità sui claim disponibili utilizzando il Claim Registry.
AS Registry ↔ DC Catalog: I tipi di Credenziale referenziano le capacità AS per la validazione della fonte dati.
DC Catalog ↔ Taxonomy: Le voci di Credenziale specificano domain e purpose dalla taxonomy per la discovery e l'autorizzazione.
Schema Registry ↔ DC Catalog: I tipi di Credenziale fanno riferimento allo Schema Registry per la discovery e la validazione dei dati.
La Figura Relationships between National Registries and EUDIW Catalogues mostra invece la mappatura tra i cataloghi EUDIW e le controparti nazionali:
EUDIW Catalogue of Attributes corrisponde al Claims Registry nazionale per la definizione semantica degli attributi e all'Authentic Source Registry per la discovery del punto di verifica. Si noti che le definizioni nazionali degli attributi si allineano al catalogo a livello UE per l'interoperabilità transfrontaliera.
EUDIW Catalogue of Schemes corrisponde al Catalogue of Attestations nazionale (Catalogo delle Attestazioni), che implementa la Section 5 di [EUDI-TS 11], e al Digital Credentials Catalog per i requisiti nazionali di emissione e presentazione. Il catalogo nazionale mantiene le informazioni aggiuntive, quali il modello di prezzo e le informazioni di validità.
Fig. 7.4 Relationships between National Registries and EUDIW Catalogues¶
Nota
Come specificato in EIDAS-ARF, la registrazione di uno schema di attestazione nel EUDIW Catalogue of Schemes non crea alcun obbligo di accettazione del relativo tipo di attestazione da parte di qualsiasi attore dell'ecosistema EUDI Wallet. Né implica automaticamente il riconoscimento transfrontaliero del tipo di attestazione. È utilizzato per scoprire il corrispondente trust framework.
7.9. Registry Infrastructure Usage Journeys¶
I componenti della Registry Infrastructure sono progettati per supportare diverse fasi operative dell'ecosistema IT-Wallet, ciascuna delle quali coinvolge interazioni specifiche tra le entità. I principali Journey seguenti illustrano le interazioni operative che leggono la Registry Infrastructure. Il journey complementare che popola i registri è la registrazione di onboarding, che registra le entità, le Fonti Autentiche, i claim, gli schema e i tipi di Credenziale, come mostrato nella Figura Registries and Catalogues of the Ecosystem e descritto in Onboarding Processes.
7.9.1. Catalog Browsing¶
Questo journey di Catalog Browsing supporta gli Utenti (sia utenti umani tramite un'Istanza del Wallet sia sistemi automatizzati quali Relying Party o portali web) nella discovery e nella selezione degli Attestati Elettronici disponibili.
Accesso al Discovery Endpoint: L'entità (ad es., un Fornitore di Wallet o un portale informativo) accede al Registry Discovery Endpoint (
.well-known/it-wallet-registry) per ottenere l'URI del Digital Credentials Catalog e della Taxonomy.Navigazione e selezione:
Discovery delle Credenziali: L'entità richiede una o più pagine dell'endpoint di collection (Digital Credentials Catalog Retrieval) e legge l'array
credentialsdi ciascuna pagina per identificare i tipi di Credenziale rilevanti (ad es.,pid,eid,mDL). Se necessario, utilizza le informazioni sulla Taxonomy per navigarne la gerarchia e per fornire localizzazioni diverse.Metadata dell'Issuer: L'entità estrae i Metadata del Credential Issuer (si veda Metadata per openid_credential_issuer) come descritto nella Section 12.2.2 di OpenID4VCI.
Consultazione di dettaglio: Per ottenere informazioni complete e requisiti tecnici specifici, l'entità accede all'Entity Configuration utilizzando l'identificativo recuperato.
Azione finale: L'entità può quindi utilizzare i metadata per visualizzare le informazioni del catalogo a un Utente, o utilizzarli in altri modi.
7.9.2. Credential Issuance¶
Questo journey definisce come un Credential Issuer utilizza la Registry Infrastructure per preparare e emettere un Attestato Elettronico conforme.
Identificazione dei requisiti: Il Credential Issuer recupera la voce versionata del tipo di Credenziale dall'endpoint di entry del Digital Credentials Catalog (Digital Credentials Catalog Retrieval) e legge i requisiti tecnici di quella voce (ad es.,
max_validity_days,min_loa).Risoluzione di schema e claim:
Il Credential Issuer consulta:
il EUDIW Catalogue of Schemes per ottenere lo
SchemaMetadell'Attestato Elettronico ancorato a EUDIW, oCatalogo delle Attestazioni per ottenere lo
SchemaMetadell'Attestato Elettronico nazionale medianteGET /schemas/{schemaId}.Il Credential Issuer verifica il suffisso
#integritydi ciascunschemaURIs[].uriquando tale suffisso è presente. Quindi, a seconda del Trust Framework che ancora l'Attestato Elettronico, accede al Catalogue of Attributes o al Claims Registry per recuperare le definizioni semantiche standardizzate e i formati di dato degli attributi (claim) necessari.
Recupero dei dati autentici:
Il Credential Issuer consulta l'Authentic Source (AS) Registry per identificare la Fonte Autentica (AS) autorizzata per il dataset richiesto. L'AS Registry fornisce l'
entity_iddell'AS e i dettagli tecnici dell'interfaccia (integration_endpoint, integration_method).Il Credential Issuer consulta la specifica dell'endpoint AS per implementare l'integrazione necessaria a recuperare i dati dell'Utente richiesti per popolare l'Attestato Elettronico.
Emissione della Credenziale: Il Credential Issuer utilizza i dati recuperati, gli schema validati e i formati specificati per generare e firmare l'Attestato Elettronico nel formato corretto (ad es., SD-JWT o mDOC).
7.9.3. Credential Presentation and Verification¶
Questo journey descrive come un'Istanza del Wallet e una Relying Party (RP) interagiscono con la Registry Infrastructure quando un Attestato Elettronico deve essere presentato da un Utente.
Autorizzazione e selezione della Wallet Unit:
La Wallet Unit riceve una Presentation Request dalla RP. La Wallet Unit DEVE valutare la trust con la RP che emette la Presentation Request come segue:
(EUDIW Trust Framework):
La Wallet Unit valida la firma della Presentation Request e valuta la trust con la Relying Party che la produce come descritto in EUDIW Authentication.
La Wallet Unit valida se la RP è titolata a questa presentazione come descritto in EUDIW Authorization.
(National Trust Framework):
La Wallet Unit valida la firma della Presentation Request e valuta la trust con la Relying Party che la produce come descritto in Authentication.
La Wallet Unit valida se la RP è titolata a questa presentazione come descritto in Authorization.
Indipendentemente dal Trust Framework, la decisione finale su se la RP è Authorized durante la presentazione è assunta secondo Authorization Decision and Override Rules.
L'Utente autorizza il rilascio degli attributi selezionati, oggetto di selective disclosure. Il Wallet quindi impacchetta e presenta l'Attestato Elettronico alla RP.
Discovery e integrità:
La RP riceve l'Attestato Elettronico dall'Utente.
A seconda del trust framework a cui la RP aderisce (ossia, il National o il Trust Framework EUDIW):
(EUDIW Trust Framework):
La RP valida la firma dell'Attestato Elettronico e valuta la trust con il suo issuer come descritto in EUDIW Attestation Signature Validation.
La RP consulta il EUDIW Catalogue of Schemes e recupera lo
SchemaMetadella Credenziale presentata, verificando ciascunschemaURIs[].uriche reca un suffisso#integritycome definito in [W3C-SRI].(National Trust Framework):
La RP valida la firma dell'Attestato Elettronico e valuta la trust con il suo issuer come descritto in Signing Trust Anchor Validation Procedure.
La RP recupera lo
SchemaMetadaGET /schemas/{schemaId}sul Catalogo delle Attestazioni, usando loschemaIddella voce di catalogo, e verifica ciascunschemaURIs[].uriche reca un suffisso#integritycome definito in [W3C-SRI].
Validazione dello schema e della policy finale:
La RP utilizza lo schema recuperato per validare la struttura della Credenziale e i tipi di dato degli attributi rivelati.
La RP esegue il controllo finale per assicurare che gli attributi presentati siano conformi ai requisiti specifici della richiesta iniziale e della policy di autorizzazione.
Accettazione o rifiuto: Sulla base della validazione crittografica, della conformità allo schema e dell'autorizzazione basata su policy, la RP accetta o rifiuta l'Attestato Elettronico per l'accesso al servizio.
7.9.4. Cross-border Attribute Verification by a QTSP¶
Questo journey descrive come un Qualified Trust Service Provider (QTSP), eventualmente stabilito in un altro Stato membro, verifica il valore di un attributo dell'Annex VI rispetto a una Fonte Autentica italiana del settore pubblico per emettere una QEAA.
Utilizza il verification_endpoint dell'Authentic Source Registry, che è la controparte nazionale della discovery del punto di verifica nel EUDIW Catalogue of Attributes. Non utilizza la valutazione di trust OpenID Federation nazionale né l'e-Service PDND nazionale.
Discovery del punto di verifica: Il QTSP scopre il punto di verifica da
data_capabilities[].verification_endpointnell'Authentic Source Registry.endpointè il punto di verifica. Il EUDIW Catalogue of Attributes è la controparte transfrontaliera di questa discovery, come descritto in Registry Integration and Cross-References. Il Federation Trust Anchor non pubblica quel catalogo.Selezione dell'interfaccia: A seconda di
verification_endpoint.method, il QTSP utilizza l'interfaccia ISO 15000/eDelivery (oots_edelivery) o l'interfaccia REST + OAuth 2.0 (rest_oauth2) di ETSI TS 119 478 Section 6.Richiesta di verifica: Il QTSP presenta la richiesta di verifica all'endpoint, esposto dalla Fonte Autentica o dall'intermediario nazionale designato, che restituisce la conferma autentica del valore dell'attributo per l'Utente. Come previsto dall'Articolo 45e di [EIDAS], questa è una verifica di autenticità dell'attributo e non un accesso ai dati sottostanti.
Emissione: Il QTSP emette la QEAA secondo il proprio Rulebook e i propri trust anchor, ossia le EUDIW Trusted Lists. L'ancoraggio di trust della QEAA risultante non deriva dalla presenza di alcun schema nel Catalogue of Schemes, si veda la nota in Registry Integration and Cross-References.