7. Infrastruttura del Registro

L'ecosistema IT-Wallet opera attraverso un'infrastruttura di registro che fornisce definizioni standardizzate dei dati, registrazione delle entità e capacità di discovery delle credenziali. Il sistema di registro è composto da più componenti interconnessi che supportano l'intero ciclo di vita delle operazioni degli Attestati Elettronici, dall'onboarding delle entità alla presentazione delle credenziali.

L'architettura del registro è necessaria a definire i requisiti di standardizzazione semantica, gestione del trust della federazione e discovery delle credenziali attraverso componenti di registro specializzati che garantiscono interoperabilità e conformità in tutto l'ecosistema.

7.1. Panoramica dell'Architettura del Registro

Il sistema di registro IT-Wallet comprende cinque componenti principali:

  1. Registro degli Attributi: Definizioni semantiche standardizzate per singoli attributi delle credenziali, tipi di dati e regole di validazione.

  2. Registro delle Fonti Autentiche (AS): Catalogo dei fornitori di dati registrati con le loro capacità dichiarate e claim disponibili.

  3. Registro della Federazione: Elenco autorevole delle entità fidate che partecipano alla federazione con le loro configurazioni tecniche.

  4. Catalogo degli Attestati Elettronici: Meccanismo di discovery pubblico per i tipi di credenziali disponibili con i loro metadati e informazioni di rilascio.

  5. Tassonomia: Sistema di classificazione gerarchica che organizza le credenziali per dominio e scopo.

Questi componenti del registro sono interconnessi e mantenuti dall'Organismo di Supervisione per garantire coerenza, sicurezza e conformità normativa in tutto l'ecosistema.

7.2. Endpoint di Discovery del Registro

Il Trust Anchor DEVE fornire un meccanismo di discovery per tutti i componenti del registro attraverso endpoint well-known standardizzati che forniscono metadati e informazioni di discovery delle API REST per gestire operazioni complesse come paginazione e filtraggio.

Il Trust Anchor DEVE pubblicare i metadati di discovery del registro all'endpoint .well-known/it-wallet-registry con supporto per la negoziazione del contenuto:

  • Content-Type Predefinito: application/jwt (JWT firmato che garantisce autenticità e integrità)

  • Content-Type Alternativo: application/json (JSON semplice per scopi di sviluppo/debug)

Inoltre, il sistema di registro IT-Wallet DEVE utilizzare due modelli di accesso distinti:

  • API del Registro Dati: DEVONO supportare capacità di paginazione e filtraggio.

  • Infrastruttura di Trust della Federazione: come definito in L'Infrastruttura di Trust.

Di seguito viene 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

Struttura del payload JWT (decodificato):

{
  "registry_version": "1.0",
  "last_updated": "2024-03-15T10:30:00Z",
  "endpoints": {
    "claims_registry": "https://trust-anchor.eid-wallet.example.it/api/v1/claims",
    "authentic_sources": "https://trust-anchor.eid-wallet.example.it/api/v1/authentic-sources",
    "credential_catalog": "https://trust-anchor.eid-wallet.example.it/api/v1/credential-catalog",
    "taxonomy": "https://trust-anchor.eid-wallet.example.it/api/v1/taxonomy",
    "federation_list": "https://trust-anchor.eid-wallet.example.it/list",
    "federation_fetch": "https://trust-anchor.eid-wallet.example.it/fetch",
    "federation_resolve": "https://trust-anchor.eid-wallet.example.it/resolve",
    "federation_trust_mark_status": "https://trust-anchor.eid-wallet.example.it/trust_mark_status",
    "federation_historical_keys": "https://trust-anchor.eid-wallet.example.it/historical-jwks"
  },
  "content_negotiation": ["application/json", "application/jwt"]
}

7.3. Registro degli Attributi

Il Registro degli Attributi fornisce definizioni semantiche standardizzate per singoli attributi delle credenziali, tipi di dati e regole di validazione. Questo registro serve come fondamento semantico per la standardizzazione degli attributi delle credenziali in tutto l'ecosistema IT-Wallet, lavorando in coordinamento con il componente Tassonomia per la classificazione gerarchica.

L'Organismo di Supervisione DEVE mantenere il Registro degli Attributi per garantire coerenza semantica e conformità normativa in tutto l'ecosistema. Il registro DEVE contenere:

  • Claim Standardizzati: Definizioni semantiche per tutti gli attributi delle credenziali con tipi di dati e regole di validazione.

  • Mappature di Interoperabilità: Definizioni di alias per gli attributi che utilizzano terminologie diverse tra gli standard (ad esempio, ISO18013-5 place_of_birth mappato al canonico birth_place).

  • Formati dei Dati: Tipi di dati standardizzati (string, date, numeric, boolean, email, url, image, array, object) con pattern di validazione.

Il Registro degli Attributi DEVE garantire:

  • Coerenza Semantica: Previene conflitti tra attributi duplicati o ridondanti in tutto l'ecosistema.

  • Interoperabilità Transfrontaliera: Garantisce conformità UE e interpretazione coerente degli attributi.

  • Validazione dello Schema: Fornisce definizioni autorevoli per la validazione degli attributi in tutti gli scenari di credenziali.

  • Allineamento Normativo: Si coordina con il quadro normativo nazionale ed europeo.

  • Scenari Credential-Agnostic: Supporta scenari in cui la convenienza dell'utente e l'efficienza operativa aziendale sono prioritarie rispetto alla conformità normativa e ai log di audit.

Nota

Il Registro degli Attributi definisce le proprietà semantiche dei singoli attributi, ma NON DEVE specificare le capacità di selective disclosure. La selective disclosure dipende dalle implementazioni del formato delle credenziali (SD-JWT, mDocs), dalle configurazioni tecniche dell'emittente e dal contesto di presentazione. Queste capacità sono specificate a livello del tipo di credenziale all'interno del Catalogo degli Attestati Elettronici e implementate durante i flussi di presentazione delle credenziali.

7.3.1. Utilizzo del Registro degli Attributi

Il Registro degli Attributi DEVE supportare l'intero ciclo di vita dell'ecosistema:

Durante il Processo di Onboarding:

  • Registrazione AS: Le Fonti Autentiche dichiarano i proprio claim disponibili tra quelli presenti nel registro standardizzato durante la registrazione delle capacità di fornitura dati.

  • Registrazione CI: I Credential Issuer selezionano le entità AS basandosi sugli attributi richiesti e registrano i tipi di credenziali per la pubblicazione nel catalogo.

  • Registrazione RP: Le Relying Party specificano i requisiti di autorizzazione utilizzando domini/scopi per tipi di credenziali specifici e/o attributi dell'Utente.

Durante le Attività Operative:

  • Rilascio di Credenziali: Le definizioni degli attributi garantiscono rappresentazione coerente dei dati tra diversi tipi di credenziali.

  • Richieste di Presentazione: Le RP fanno riferimento agli attributi per la validazione dello schema e la verifica dell'autorizzazione in scenari sia credential-specific che credential-agnostic.

  • Applicazione delle Policy: Le policy di autorizzazione sfruttano le classificazioni dominio/scopo per il controllo degli accessi.

7.3.2. Struttura del Registro degli Attributi

Il Registro degli Attributi mantiene definizioni tecniche, linguisticamente neutrali per la coerenza semantica in tutto l'ecosistema. Le localizzazioni rivolte all'utente per nomi e descrizioni degli attributi sono fornite attraverso i bundle di localizzazione del Catalogo degli Attestati Elettronici, abilitando un supporto multilingue efficiente senza compromettere l'integrità strutturale del registro.

Un esempio non normativo della struttura del Registro degli Attributi è fornito di seguito:

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

7.4. Registro delle Fonti Autentiche

L'Organismo di Supervisione DEVE mantenere il Registro delle Fonti Autentiche per abilitare l'accesso coordinato ai dati e il rilascio di credenziali in tutto l'ecosistema. Il Registro AS DEVE contenere almeno:

  • Informazioni sull'Organizzazione: Dettagli dell'entità legale, stato normativo e ruolo autorevole all'interno di domini specifici.

  • Capacità di Fornitura Dati: Disponibilità dichiarata degli attributi che fanno riferimento alle definizioni standardizzate del Registro degli Attributi con le corrispondenti classificazioni della Tassonomia.

  • Metodi di Integrazione: Meccanismi di accesso tecnico (PDND per AS pubbliche, API personalizzate per AS private).

  • Scopi Previsti: Tipi di credenziali supportati e contesti aziendali per il coordinamento AS-CI.

  • Garanzia della Qualità dei Dati: Stato autoritativo, frequenza di aggiornamento e capacità di traccia di audit.

Il Registro AS DEVE garantire:

  • Accesso Coordinato ai Dati: Abilita la discovery CI di dati appropriati dalle Fonti Autentiche per il rilascio di credenziali.

  • Integrazione AS-CI: Facilita i flussi di lavoro di approvazione e il coordinamento dell'accesso ai dati tra le entità.

  • Garanzia della Qualità: Mantiene lo stato autoritativo e l'affidabilità dei dati tra diversi domini.

  • Conformità Normativa: Supporta i requisiti di trasparenza dell'amministrazione pubblica e il coordinamento del settore privato.

7.4.1. Utilizzo del Registro AS

Il Registro AS supporta il coordinamento dell'ecosistema durante tutto il ciclo di vita operativo:

Durante il Processo di Onboarding:

  • Auto-Dichiarazione AS: Le Fonti Autentiche registrano le specifiche prima che esista un qualsiasi tipo di credenziali nel catalogo.

  • Discovery dei CI: I Credential Issuer cercano entità AS basandosi sugli attributi richiesti e sui tipi di credenziali previsti.

  • Coordinamento delle Approvazioni: Le entità AS valutano e approvano le richieste di accesso CI per la fornitura di dati.

Durante le Attività Operative:

  • Risoluzione della Fonte Dati: I sistemi CI fanno riferimento al Registro AS per l'accesso ai dati in tempo reale durante il rilascio delle credenziali.

  • Validazione della Qualità: Le informazioni del Registro AS supportano la verifica dell'origine dei dati e i requisiti di audit.

  • Gestione dell'Integrazione: Gli endpoint tecnici e i metodi di accesso abilitano la comunicazione standardizzata AS-CI.

7.4.2. Coordinamento AS Pubbliche vs Private

L'architettura del Registro AS supporta diversi pattern di coordinamento che riflettono requisiti operativi distinti:

  1. AS dell'Amministrazione Pubblica (Integrazione Standardizzata): Le entità governative forniscono dati autorevoli attraverso meccanismi regolamentati:

  • Integrazione PDND: "integration_method": "pdnd_eservice" per l'accesso standardizzato ai dati governativi.

  • Conformità Normativa: Requisiti di trasparenza completa con pubblicazione nel catalogo pubblico.

  • Requisiti di Audit: Tracciabilità completa per i processi di rilascio delle credenziali governative.

  1. AS del Settore Privato (Integrazione Flessibile): Le entità private forniscono dati specializzati attraverso accordi personalizzati:

  • API Personalizzate: "integration_method": "custom_api" per pattern di accesso ai dati specifici dell'azienda.

  • Selective Disclosurea: Visibilità pubblica limitata con flussi di lavoro di approvazione specifici per CI.

  • Flessibilità Aziendale: Integrazione su misura che supporta diversi casi d'uso del settore privato.

Questo approccio abilita sia la trasparenza normativa per l'amministrazione pubblica che la flessibilità aziendale per le entità del settore privato mantenendo l'accesso coordinato ai dati in tutto l'ecosistema.

7.4.3. Struttura del Registro AS

Durante la registrazione, le Fonti Autentiche dichiarano le loro specifiche prima che esista un qualsiasi tipo di credenziale nel catalogo. Questa dichiarazione stabilisce le fondamenta per la successiva registrazione CI e creazione di tipi di credenziali.

7.4.3.1. Schema dell'Identificatore Univoco AS

Ad ogni Fonte Autentica DEVE essere assegnato un identificatore univoco che segue lo schema URL HTTPS definito di seguito. Questo identificatore è utilizzato per fare riferimento alle entità AS in tutto il sistema di registro e nel Catalogo degli Attestati Elettronici, garantendo coerenza con i pattern di identificazione delle entità OpenID Federation.

Schema dell'Identificatore 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'identificatore AS DEVE seguire queste regole normative:

  1. Protocollo HTTPS: DEVE utilizzare lo schema HTTPS per sicurezza e verifica del trust

  2. Proprietà del Dominio: L'organizzazione DEVE controllare il dominio DNS utilizzato nell'identificatore

  3. Unicità: Garantita attraverso l'unicità del namespace DNS

  4. Stabilità: DOVREBBE rimanere stabile nel tempo per evitare la corruzione dei riferimenti

  5. Risolvibilità: L'URL DOVREBBE essere risolvibile (anche se non è richiesto che serva contenuto)

Esempi di identificatori AS conformi:

  • https://motorizzazione.gov.example: Pubblico - Ministero dei Trasporti, Dipartimento Motorizzazione

  • https://registry.anpr.example: Pubblico - Anagrafe Nazionale della Popolazione Residente

  • https://api.bank.example/auth-source: Privato - Servizi Finanziari Banca Esempio

7.4.3.2. Parametri del Registro AS

Il Registro AS DEVE contenere i seguenti parametri per ogni Fonte Autentica registrata:

Tabella 7.1 Registro AS - Parametri Richiesti

Parametro

Tipo

Descrizione

entity_id

string

RICHIESTO. Identificatore univoco che segue lo schema normativo: https://{organization_domain}[/{optional_path}].

organization_info

JSON object

RICHIESTO. Dettagli dell'entità legale e metadati organizzativi.

organization_info.organization_name

string

RICHIESTO. Nome legale dell'organizzazione.

organization_info.organization_type

string

RICHIESTO. Classificazione dell'entità: "public" o "private".

organization_info.ipa_code

string

RICHIESTO solo per AS Pubbliche. Codice di registrazione IPA per entità governative.

organization_info.legal_identifier

string

RICHIESTO. Identificatore di registrazione legale (Codice Fiscale/Partita IVA, o identificatore nazionale equivalente per entità straniere).

organization_info.homepage_uri

string

RICHIESTO. URL che punta alla homepage dell'organizzazione.

organization_info.contacts

String Array

RICHIESTO. Array di indirizzi email di contatto tecnico/amministrativo.

organization_info.policy_uri

string

RICHIESTO. URL al documento della privacy policy.

organization_info.tos_uri

string

RICHIESTO solo per AS Private. URL al documento dei termini di servizio.

organization_info.organization_country

string

RICHIESTO. Codice paese ISO 3166-1 alpha-2 a due lettere dell'organizzazione.

organization_info.logo_uri

string

OPZIONALE. URL al logo dell'organizzazione.

organization_info.service_documentation

string

OPZIONALE. URL che punta alla documentazione del servizio della Fonte Autentica.

organization_info.user_information

string

OPZIONALE. Una stringa contenente informazioni "human-readable" sulla Attestato Elettronico rilevante per l'Utente. Questa stringa DEVE essere fornita dalla Fonte Autentica al Trust Anchor durante l'onboarding e DEVE essere formattata utilizzando il formato Markdown come definito in RFC 7763. La formattazione Markdown può essere testo semplice o una combinazione di testo e link. Ad esempio, se il database della Fonte Autentica contiene solo i dati richiesti per gli attributi dell'Attestato Elettronico registrati dopo una data specifica, questa informazione DEVE essere comunicata al Trust Anchor in questa stringa Markdown.

data_capabilities

JSON Objects Array

RICHIESTO. Array contenente le specifiche delle capacità dei dati.

data_capabilities[].domains

String Array

RICHIESTO. Dominio della tassonomia (ad esempio, ["AUTHORIZATION"], ["FINANCIAL"]).

data_capabilities[].intended_purposes

String Array

RICHIESTO. Scopi aziendali serviti (ad esempio, ["driving-authorization", "identity-verification"]).

data_capabilities[].available_claims

String Array

RICHIESTO. I claim disponibili da questa capacità di fornitura dati.

data_capabilities[].integration_method

string

RICHIESTO. Framework di autorizzazione utilizzato per l'accesso ai dati. DEVE essere "pdnd" per AS Pubbliche. Le AS Private POSSONO utilizzare altri framework di autorizzazione come: "oauth2", "api_key", "mtls", ecc.

data_capabilities[].integration_endpoint

string

RICHIESTO. Punto di accesso al servizio (endpoint PDND per AS Pubbliche, endpoint API per AS Private).

data_capabilities[].api_specification

string

RICHIESTO. URL al documento di specifica OAS3 per questa capacità di fornitura dati.

data_capabilities[].data_provision

JSON object

OPZIONALE. Capacità di fornitura dati e specifiche di tempistica.

data_capabilities[].data_provision.immediate_flow

boolean

RICHIESTO. Indica se la Fonte Autentica supporta la fornitura immediata dei dati.

data_capabilities[].data_provision.deferred_flow

boolean

RICHIESTO. Indica se la Fonte Autentica supporta la fornitura differita dei dati.

data_capabilities[].data_provision.max_response_time_minutes

integer

CONDIZIONALE. Tempo massimo in minuti per la Fonte Autentica per rispondere a una richiesta di fornitura dati differita. RICHIESTO se deferred_flow è true.

data_capabilities[].data_provision.notification_methods

String Array

CONDIZIONALE. Array di metodi di notifica supportati dalla Fonte Autentica per la fornitura dati differita, come "push", "poll". RICHIESTO se deferred_flow è true.

data_capabilities[].update_frequency

string

OPZIONALE. Indica quanto frequentemente la Fonte Autentica aggiorna i suoi dati. Valori possibili: "real_time" (aggiornamenti quasi in tempo reale, tipicamente entro minuti), "daily", "weekly", "monthly", "on_demand".

display

JSON object

OPZIONALE. Suggerimenti di branding visivo che le Fonti Autentiche possono fornire per le credenziali che utilizzano i loro dati.

display.background_color

string

OPZIONALE. Colore di sfondo suggerito per le credenziali in formato esadecimale (ad esempio, "#003d82").

display.text_color

string

OPZIONALE. Colore del testo suggerito per le credenziali in formato esadecimale (ad esempio, "#ffffff").

display.logo_uri

string

OPZIONALE. URI al logo della Fonte Autentica per il branding delle credenziali.

display.logo_uri#integrity

string

CONDIZIONALE. Digest crittografico del logo per la verifica dell'integrità. RICHIESTO se logo_uri è presente. Formato: {digest_method}-{digest_value} (ad esempio, "sha-256-abc123...")

display.template_uri

string

OPZIONALE. URI a un template visivo che la Fonte Autentica suggerisce per le credenziali che utilizzano i loro dati.

display.template_uri#integrity

string

CONDIZIONALE. Digest crittografico del template per la verifica dell'integrità. RICHIESTO se template_uri è presente. Formato: {digest_method}-{digest_value} (ad esempio, "sha-256-def456...").

7.4.3.3. Esempio del Registro AS

Un esempio non normativo della struttura del Registro AS è fornito di seguito:

[
  {
    "entity_id": "https://motorizzazione.gov.example",
    "organization_info": {
      "organization_name": "MIT -- Direzione Generale per la Motorizzazione",
      "organization_type": "public",
      "ipa_code": "m_inf",
      "legal_identifier": "80192770587",
      "organization_country": "IT",
      "homepage_uri": "https://www.gov.example/transport",
      "contacts": ["registry@gov.example", "technical-support@gov.example"],
      "policy_uri": "https://www.gov.example/transport/privacy-policy",
      "logo_uri": "https://www.gov.example/assets/transport-logo.svg",
      "service_documentation": "https://docs.gov.example/transport/api-docs",
      "user_information": "Vehicle registration data is available for licenses issued after January 1, 2020. For older licenses, contact the local motorization office."
    },
    "data_capabilities": [
      {
        "domains": ["IDENTITY", "AUTHORIZATION"],
        "intended_purposes": ["DRIVING_LICENSE", "PERSON_IDENTIFICATION"],
        "available_claims": [
          "given_name", "family_name", "birth_date", "birth_place",
          "issue_date", "expiry_date", "document_number", "driving_privileges",
          "portrait", "un_distinguishing_sign", "document_iss_country", "document_iss_authority"
        ],
        "integration_method": "pdnd",
        "integration_endpoint": "https://api.gov.example/transport/driving-license",
        "api_specification": "https://docs.gov.example/transport/api-oas3.yaml",
        "data_provision": {
          "immediate_flow": true,
          "deferred_flow": false
        },
        "update_frequency": "real_time"
      }
    ],
    "display": {
      "background_color": "#003d82",
      "text_color": "#ffffff",
      "logo_uri": "https://www.gov.example/assets/transport-logo.svg",
      "logo_uri#integrity": "sha-256-a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3"
    }
  },
  {
    "entity_id": "https://api.bank.example/auth-source",
    "organization_info": {
      "organization_name": "Example Bank S.p.A.",
      "organization_type": "private",
      "legal_identifier": "12345678901",
      "homepage_uri": "https://www.bank.example",
      "contacts": ["digital-credentials@bank.example", "api-support@bank.example"],
      "policy_uri": "https://www.bank.example/privacy-policy",
      "tos_uri": "https://www.bank.example/terms-of-service",
      "organization_country": "IT",
      "logo_uri": "https://www.bank.example/assets/logo.svg",
      "service_documentation": "https://docs.bank.example/psd2-api",
      "user_information": "Financial data access requires customer consent and is subject to PSD2 regulations. Account information is available for active accounts only."
    },
    "data_capabilities": [
      {
        "domains": ["FINANCIAL"],
        "intended_purposes": ["BANK_ACCOUNT", "INCOME_CERTIFICATE"],
        "available_claims": [
          "given_name", "family_name", "birth_date", "tax_code",
          "account_holder_name", "iban", "account_status", "account_opening_date",
          "bank_name", "bank_code"
        ],
        "integration_method": "oauth2",
        "integration_endpoint": "https://api.bank.example/psd2/v1/accounts",
        "api_specification": "https://api.bank.example/docs/psd2-openapi.yaml",
        "data_provision": {
          "immediate_flow": true,
          "deferred_flow": false
        },
        "update_frequency": "daily"
      },
      {
        "domains": ["FINANCIAL"],
        "intended_purposes": ["PAYMENT_HISTORY"],
        "available_claims": [
          "given_name", "family_name", "tax_code",
          "transaction_history", "average_balance", "credit_score_indicator"
        ],
        "integration_method": "oauth2",
        "integration_endpoint": "https://api.bank.example/psd2/v1/transactions",
        "api_specification": "https://api.bank.example/docs/psd2-openapi.yaml",
        "data_provision": {
          "immediate_flow": false,
          "deferred_flow": true,
          "max_response_time_minutes": 1440,
          "notification_methods": ["push", "poll"]
        },
        "update_frequency": "weekly"
      }
    ]
  }
]

7.4.4. Coordinamento AS-CI

Dopo la registrazione AS, il Registro AS abilita i Credential Issuer a scoprire entità AS adatte e richiedere l'approvazione dell'integrazione. Questo processo di coordinamento è dettagliato in Processo di Integrazione AS-CI.

7.5. Registro della Federazione

Il Registro della Federazione fornisce l'infrastruttura di trust crittografico per tutti i partecipanti dell'ecosistema IT-Wallet. Il Registro della Federazione mantiene l'elenco autorevole delle entità fidate e il loro stato operativo utilizzando endpoint specifici della federazione come definito in trust:Endpoint API di Federazione.

7.5.1. Ruolo di Integrazione del Registro

All'interno dell'architettura del registro IT-Wallet, il Registro della Federazione serve come livello di validazione del trust per:

  1. Autenticazione delle Entità: Valida l'identità crittografica di tutti i partecipanti prima delle operazioni del registro

  2. Verifica della Catena di Trust: Fornisce le fondamenta crittografiche per la validazione delle entità Credential Issuer, Relying Party e Wallet Provider

  3. Verifica della Conformità: Mantiene Trust Mark che attestano la conformità normativa e lo stato operativo

7.5.2. Accesso al Registro della Federazione

Le operazioni del Registro della Federazione sono accessibili attraverso gli endpoint della federazione del Trust Anchor come dettagliato in trust:Endpoint API di Federazione. L'architettura di discovery del registro fornisce informazioni sugli endpoint della federazione tramite l'Endpoint di Discovery del Registro descritto in Endpoint di Discovery del Registro.

Nota

Gli endpoint della federazione sono disponibili sia attraverso il meccanismo di discovery del registro (per l'accesso unificato al registro) che attraverso l'Entity Configuration del Trust Anchor a .well-known/openid-federation (per operazioni specifiche della federazione). Entrambe le fonti forniscono gli stessi URL degli endpoint ma servono pattern di discovery diversi: discovery del registro per l'orientamento iniziale dell'ecosistema, Entity Configuration per la conformità standard OpenID Federation 1.0.

Per le specifiche tecniche complete dei protocolli di federazione, configurazioni delle entità, meccanismi di valutazione del trust e validazione della catena di trust, vedere L'Infrastruttura di Trust.

7.6. Catalogo degli Attestati Elettronici

Il Catalogo degli Attestati Elettronici è il registro di tutti gli Attestati Elettronici disponibili riconosciuti all'interno dell'ecosistema IT-Wallet. È pubblicato dal Trust Anchor e pubblicamente disponibile da tutte le Entità attraverso un endpoint specializzato della Federazione. Agisce come un singolo punto di riferimento per tutti gli attori coinvolti nel processo di rilascio, verifica e utilizzo degli Attestati Elettronici.

Il Catalogo degli Attestati Elettronici mira a:

  1. Facilitare la discovery degli Attestati Elettronici per gli Utenti.

  2. Standardizzare la descrizione tecnica e funzionale degli Attestati Elettronici.

  3. Abilitare l'interoperabilità tra diversi Issuer e Relying Party.

  4. Semplificare il processo di integrazione per Wallet Provider e Relying Party.

  5. Garantire il trust nell'ecosistema attraverso informazioni certificate.

  6. Fornire trasparenza sull'ecosistema degli Attestati Elettronici disponibili.

Le principali Entità coinvolte nel Catalogo degli Attestati Elettronici sono:

  • Trust Anchor: Gestisce e mantiene il Catalogo degli Attestati Elettronici, garantendone l'autenticità e l'integrità.

  • Organismo di Supervisione: Interagisce con il Trust Anchor e il Catalogo degli Attestati Elettronici per monitorare la fase di registrazione garantendo sicurezza e privacy secondo le normative nazionali/europee, mantenendo tutte le informazioni affidabili e aggiornate.

  • Credential Issuer: Le entità autorizzate a rilasciare Attestati Elettronici, registrandoli nel Catalogo.

  • Relying Party: Utilizzano il Catalogo degli Attestati Elettronici per raccogliere tutte le informazioni necessarie sugli Attestati Elettronici che intendono richiedere durante la fase di presentazione.

  • Wallet Provider: Accedono al Catalogo degli Attestati Elettronici per identificare gli Attestati Elettronici disponibili e per recuperare tutte le informazioni necessarie per integrarli nelle loro Soluzioni Wallet.

  • Utenti: Gli Utenti che utilizzano indirettamente il Catalogo degli Attestati Elettronici attraverso le loro Istanze del Wallet per scoprire e richiedere Attestati Elettronici.

  • Fonti Autentiche: Le Entità che detengono i dati originali che sono attestati negli Attestati Elettronici. Forniscono supporto agli Issuer nella registrazione degli Attestati Elettronici nel Catalogo.

La figura illustra le Entità degli Attestati Elettronici.

Fig. 7.1 Diagramma Entità-Relazione del Catalogo degli Attestati Elettronici.

La seguente tabella riassume le principali informazioni che DEVONO essere fornite dal Catalogo degli Attestati Elettronici:

Tabella 7.2 Catalogo degli Attestati Elettronici - Informazioni principali

Informazioni relative a

Descrizione

Metadati degli Attestati Elettronici

Informazioni identificative essenziali e caratteristiche degli Attestati Elettronici, inclusi:

  • Identificatore univoco delle credenziali: Una stringa identificatore univoco di ogni Attestato Elettronico.

  • Metodi di autenticazione dell'utente: Meccanismi di autenticazione dell'utente utilizzati per richiedere l'Attestato Elettronico, se richiesto dagli Issuer o dalle Fonti Autentiche.

  • Livello di Garanzia minimo: Il Livello di Garanzia minimo richiesto per l'affidabilità dell'Attestato Elettronico. DEVE tenere conto del Livello di Garanzia dell'autenticazione dell'Utente, quando applicabile, e dell'Istanza del Wallet.

  • Caratteristiche di visualizzazione aggiuntive: Specifiche visive e di formattazione, come un'immagine di riferimento di sfondo, logo, ecc.

Credential Issuer

Dettagli sull'organizzazione autorizzata a rilasciare l'Attestato Elettronico, come:

  • Identificatori dell'issuer: Identificatore univoco per il Credential Issuer.

  • Tipo di issuer: Classificazione come PID, (Q)EAA, o Fornitore Pub-EAA.

  • Informazioni aggiuntive: Dettagli organizzativi inclusi nome, codice e informazioni di contatto.

Fonti Autentiche

Informazioni sulla fonte dati autorevole.

Specifiche Tecniche

Dettagli tecnici, inclusi:

  • Schemi degli Attestati Elettronici: Specifiche del framework e della struttura.

  • Formati degli Attestati Elettronici: Standard di formato dati e codifica.

  • Policy di autenticazione: Metodi e requisiti per la verifica.

Termini di Utilizzo

Condizioni e limitazioni per l'utilizzo degli Attestati Elettronici, come:

  • Validità delle credenziali: Periodo di tempo durante il quale l'Attestato Elettronico è valido e, quando applicabile, meccanismi e dettagli tecnici per invalidare gli Attestati Elettronici (metodi di revoca/sospensione).

  • Policy di restrizione: Se applicabile, regole che governano l'uso e le limitazioni dell'Attestato Elettronico secondo le normative nazionali. È utilizzata, ad esempio, per specificare se solo specifici tipi legali di Entità, ad esempio Fornitore Pub-EAA e Soluzioni Wallet pubbliche, sono autorizzate a rilasciare e ottenere l'Attestato Elettronico.

  • Policy di costo: Informazioni relative ai modelli di costo dell'Attestato Elettronico, come free, issuance_based, verification_based.

  • Scopi degli Attestati Elettronici: Informazioni relative agli scopi consentiti per i quali l'Attestato Elettronico può essere utilizzato. Ogni tipo di Attestato Elettronico può essere utilizzato per scopi multipli.

Attributi e Riferimenti alla Tassonomia

Informazioni di contenuto e classificazione:

  • Elenco degli attributi visualizzate: Contenuto specifico dell'Attestato Elettronico visualizzato all'Utente.

  • Riferimenti strutturati alla tassonomia: Sistemi di classificazione e vocabolari controllati utilizzati.

Il Trust Anchor DEVE pubblicare e mantenere aggiornate tutte le informazioni all'endpoint .well-known del Catalogo degli Attestati Elettronici garantendo affidabilità, autenticità e integrità dei dati. In particolare, il Catalogo degli Attestati Elettronici, i claim e la tassonomia DEVONO essere disponibili attraverso l'endpoint .well-known/credential-catalog.

7.6.1. Gerarchia degli Attestati Elettronici

Gli Attestati Elettronici riconosciuti all'interno dell'ecosistema IT-Wallet sono classificati e standardizzati gerarchicamente secondo i seguenti domini e scopi principali. Scopi aggiuntivi POSSONO essere aggiunti man mano che l'ecosistema IT-Wallet cresce.

Tabella 7.3 Domini e Scopi degli Attestati Elettronici

Dominio

Scopo

Descrizione

IDENTITY

  • PERSON_IDENTIFICATION

  • ELECTRONIC_RESIDENCY

Credenziali che stabiliscono o verificano l'identità di una persona, inclusi documenti di identità fisici e digitali legalmente riconosciuti dalle leggi nazionali.

AUTHORIZATION

  • DRIVING_LICENSE

  • PROFESSIONAL_LICENSE

  • TRAVEL_DOCUMENT

  • ACCESS_PERMIT

Credenziali che concedono permessi, diritti o autorizzazioni specifiche per svolgere certe attività o accedere ad aree ristrette.

EDUCATION

  • ACADEMIC_DEGREE

  • CERTIFICATE

  • TRAINING_RECOGNITION

Credenziali relative a risultati educativi, qualifiche e riconoscimento di formazione professionale.

HEALTH

  • INSURANCE_CARD

  • DISABILITY_CARD

  • MEDICAL_PRESCRIPTION

Credenziali relative all'accesso sanitario, storia medica, copertura assicurativa e documenti relativi alla salute.

FINANCIAL

  • INCOME_CERTIFICATE

  • TAX_STATEMENT

  • FAMILY_ECONOMIC_STATUS

  • BANK_ACCOUNT

  • PAYMENT_HISTORY

Credenziali che attestano lo stato finanziario, livelli di reddito, tassazione, informazioni bancarie o situazione economica di individui o famiglie.

MEMBERSHIP

  • ASSOCIATION

  • LOYALTY_PROGRAM

  • CLUB_MEMBERSHIP

Credenziali che confermano l'affiliazione con organizzazioni, partecipazione a programmi o stato di appartenenza.

ATTESTATION

  • PUBLIC_STATEMENT

  • CIVIL_STATUS

  • CERTIFICATION

Credenziali che forniscono dichiarazioni ufficiali, conferme di stato o certificazioni rilasciate dalle autorità.

Ogni Credenziale DEVE specificare domini e scopi per abilitare sia Scenari Credential-Specific che Scenari Credential-Agnostic secondo i requisiti delle Relying Party e i pattern di richiesta di presentazione:

  1. Scenari Credential-Specific (Primari per Settori Governativi/Regolamentati): Le RP richiedono tipi specifici di credenziali per requisiti di conformità e audit, inclusi ad esempio:

  • Servizi Governativi: "vct_values": ["person_identification_data"] per la verifica dell'identità specifica del PID.

  • Controlli di Polizia: "docType": "org.iso.18013.5.1.mDL" per la verifica della patente di guida.

  • KYC Bancario: Tipi di credenziali specifici richiesti dalle normative finanziarie.

  • Servizi Sanitari: "vct_values": ["european_disability_card"] per l'accesso ai benefici per disabilità conforme all'UE.

  1. Scenari Credential-Agnostic (Tipici per Aziende Private): Le RP richiedono gli attributi specifichi indipendentemente dalla fonte delle credenziali per efficienza operativa, come:

  • Consegna E-commerce: Qualsiasi credenziale, tra quelle a cui è autorizzato ad accedere, contenente given_name, family_name, address per la spedizione.

  • Abbonamenti: Qualsiasi credenzialetra quelle a cui è autorizzato ad accedere, con given_name, email per la personalizzazione.

  • Personalizzazione del Servizio: Applicazioni aziendali che richiedono dati personali di base senza forti requisiti di fonte.

Questo approccio consente:

  • Autorizzazione basata su policy tramite l'utilizzo della mappatura dominio/scopo.

  • Registrazione RP flessibile che supporta sia le esigenze di conformità governativa che i requisiti operativi aziendali.

7.6.2. Struttura del Catalogo degli Attestati Elettronici

Il contenuto del Catalogo degli Attestati Elettronici è protetto in un JWS che contiene i seguenti parametri dell'header JOSE:

Header JOSE

Descrizione

Riferimento

typ

RICHIESTO. DEVE essere impostato a JOSE.

[RFC 7515 Sezione 4.1.9].

alg

RICHIESTO. Un identificatore di algoritmo di firma digitale come per il registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati nella Sezione Algoritmi Crittografici e NON DEVE essere impostato a none o con un identificatore di algoritmo simmetrico (MAC).

[RFC 7515 Sezione 4.1.1].

kid

RICHIESTO. Identificatore univoco della chiave pubblica.

[RFC 7515 Sezione 4.1.4].

x5c

OPZIONALE. Contiene il Certificato X.509 della chiave pubblica o la catena di Certificati [RFC 5280] corrispondente alla chiave utilizzata per firmare digitalmente il JWS. Quando il valore del parametro header kid è presente, DEVE riferirsi alla stessa chiave pubblica crittografica del leaf utilizzata con il Certificato X.509.

[RFC 7515 Sezione 4.1.6.].

cty

RICHIESTO. DEVE essere impostato a application/json.

[RFC 7515 Sezione 4.1.6.].

Il payload JWS contiene i seguenti parametri:

Tabella 7.4 Campi di Primo Livello del Catalogo

Nome Campo

Descrizione

catalog_version

RICHIESTO. Versione del formato del Catalogo degli Attestati Elettronici.

iss

RICHIESTO. Identificatore dell'issuer del Catalogo degli Attestati Elettronici.

last_modified

RICHIESTO. Timestamp dell'ultima modifica al Catalogo degli Attestati Elettronici.

credentials

RICHIESTO. Array contenente le definizioni degli Attestati Elettronici.

wallet_attestation

RICHIESTO. Un Oggetto JSON contenente definizioni per le Attestazioni del Wallet, inclusi i loro formati supportati, attributi associati e Livelli di Garanzia (LoA). Questo Oggetto è utilizzato da altre entità, come Issuer e Relying Party, per recuperare informazioni sui formati di Attestazione del Wallet supportati all'interno dell'ecosistema.

Ogni elemento dell'array credentials contiene almeno le seguenti informazioni:

Tabella 7.5 Campi di Primo Livello di Ogni Voce di Credenziale

Nome Campo

Descrizione

version

RICHIESTO. Versione della definizione dell'Attestato Elettronico.

credential_type

RICHIESTO. Identificatore univoco del tipo di Attestato Elettronico.

legal_type

RICHIESTO. Classificazione legale della Credenziale (ad esempio, pub-eaa, qeaa, eaa).

localization

OPZIONALE. Impostazioni di localizzazione, inclusi:

  • default_locale: Lingua predefinita per il testo.

  • available_locales: Elenco delle lingue supportate.

  • base_uri: URI base per le risorse di localizzazione.

  • version: Versione dei file di localizzazione.

name

RICHIESTO. Nome "human-readable" dell'Attestato Elettronico. Un suffisso _l10n_id PUÒ essere aggiunto per la gestione della localizzazione del contenuto.

description

RICHIESTO. Descrizione "human-readable" dell'Attestato Elettronico. Un suffisso _l10n_id PUÒ essere aggiunto per la gestione della localizzazione del contenuto.

restriction_policy

OPZIONALE. Restrizioni legali su Soluzioni Wallet e/o Credential Issuer autorizzati a richiedere/rilasciare l'Attestato Elettronico.

  • allowed_wallet_ids: Elenco degli identificatori delle Soluzioni Wallet consentite.

  • allowed_issuer_ids: Elenco degli identificatori dei Credential Issuer consentiti. Se presente, rappresenta una whitelist di Credential Issuer che possono essere aggiunti dal Trust Anchor nel campo issuers dell'Attestato Elettronico corrispondente.

pricing_policy

OPZIONALE. Informazioni sui prezzi degli Attestati Elettronici, inclusi:

  • models: RICHIESTO. Array di modelli di costo applicabili all'Attestato Elettronico, ognuno contenente

    • pricing_type: Tipo di modello di costo, come issuance_based, verification_based, subscription_based, other.

    • price: Costo associato al modello.

    • currency: Valuta del costo.

  • pricing_model_uri: URI alla documentazione dettagliata del modello di costo.

validity_info

Informazioni sulla validità degli Attestati Elettronici, inclusi almeno:

  • max_validity_days: Periodo di validità massimo in giorni.

  • status_methods: Metodi di verifica dello stato supportati (ad esempio status_list).

  • allowed_states: Stati degli Attestati Elettronici consentiti (ad esempio valid, revoked, suspended).

authentication

RICHIESTO. Requisiti di autenticazione degli Attestati Elettronici.

  • user_auth_required: RICHIESTO. Flag che indica se l'autenticazione dell'Utente è richiesta durante il rilascio dell'Attestato Elettronico.

  • min_loa: RICHIESTO. Livello di Garanzia minimo richiesto per l'autenticazione dell'Attestato Elettronico. DEVE includere il Livello di Garanzia dell'autenticazione dell'Utente e dell'Istanza del Wallet che richiede l'Attestato Elettronico.

  • supported_eid_schemes: RICHIESTO se user_auth_required è true. Schemi di autenticazione dell'identità digitale supportati.

purposes

RICHIESTO. Array di scopi di utilizzo per i quali l'Attestato Elettronico può essere utilizzato, definendo contesti di utilizzo specifici e attributi richiesti per ogni scopo, come:

  • id: Identificatore univoco per lo scopo (ad esempio, "driving-authorization", "person-identification").

  • description: Descrizione "human-readable" dello scopo con un suffisso _l10n_id per la localizzazione del contenuto.

  • claims_required: Array di identificatori di attributi che sono richiesti quando si utilizza la Credenziale per questo scopo.

  • claims_recommended: Array di identificatori di attributi che sono raccomandati ma non obbligatori per questo scopo.

issuers

RICHIESTO. Array di informazioni rilevanti sui Credential Issuer autorizzati, inclusi dati amministrativi e tecnici come nome dell'Organizzazione, riferimento al documento di specifica API e meccanismi di rilascio supportati (ad esempio il supporto del flusso differito).

authentic_sources

RICHIESTO. Array di identificatori stringa che fanno riferimento alle Fonti Autentiche autorizzate come registrate nel Registro delle Fonti Autentiche. Ogni identificatore corrisponde a un valore entity_id dal Registro AS, che fornisce metadati organizzativi e tecnici completi incluse capacità di fornitura dati, metodi di integrazione e informazioni di contatto.

formats

RICHIESTO. Array di formati tecnici supportati degli Attestati Elettronici, inclusi:

  • format: Tipo di formato (ad esempio, dc+sd-jwt, mso_mdoc)

  • configuration_id: Identificatore di configurazione del :term:formato Credenziale. Questo è formato concatenando il valore credential_type al format (ad esempio, dc_sd_jwt_mDL o mso_mdoc_mDL), ed è utilizzato per fare riferimento univocamente alla configurazione per questo :term:formato Credenziale.

  • vct: CONDIZIONALE. È RICHIESTO solo se il format è dc+sd-jwt. DEVE essere impostato come una Stringa URI della forma https://{dominio Trust Anchor}/{versione}/{credential_type} (ad esempio, https://trust-registry.it-wallet.example.it/v1.0/mDL). La corrispondenza dei letterali inclusi in questa stringa URI DEVE essere eseguita in modo case-insensitive.

  • docType: CONDIZIONALE. È RICHIESTO solo se il format è mso_mdoc. Se la :term:Credenziale è:

    • definita da uno standard ISO, DEVE essere una stringa della forma iso.org.{iso-number}.{part}.{version}.{credential_type} (ad esempio, iso.org.18013.5.1.mDL).

    • definita a livello europeo, DEVE essere una stringa della forma eu.europa.ec.{credential_type}.{version} (ad esempio, eu.europa.ec.loyaltycard.1.0).

    • definita da uno standard nazionale, DEVE essere una stringa della forma {dominio inverso Trust Anchor}.{credential_type}.{version} (ad esempio, it.wallet.trust-registry.personidentificationdata.1).

  • schema_uri: URI che punta al documento di specifica del formato.

  • schema_uri#integrity: Digest crittografico del documento di specifica del formato per la verifica dell'integrità. DEVE essere una stringa della forma {digest_method}-{digest_value}, dove {digest_method} è l'algoritmo di digest utilizzato (ad esempio, sha-256) e {digest_value} è il valore del digest codificato in base64url.

display_properties

RICHIESTO. Proprietà di presentazione visiva degli Attestati Elettronici, ad esempio:

  • templates: Template visivi per la Credenziale, ad esempio template svg.

  • background_color: Colore di sfondo in formato esadecimale.

  • text_color: Colore del testo in formato esadecimale.

  • logo_uri: URI al logo dell'Attestato Elettronico.

claims

RICHIESTO. Array di attributi contenuti nell'Attestato Elettronico. DEVE includere almeno i seguenti attributi:

  • name: Il nome nell'Attestato Elettronico.

  • namespaces: CONDIZIONALE. Namespace a cui appartiene il claim.

  • display_name_l10n_id: OPZIONALE. Identificativo "human readable" con un suffisso _l10n_id per la gestione della localizzazione del contenuto.

L'Oggetto wallet_attestation contiene almeno le seguenti informazioni:

Tabella 7.6 Campi di Primo Livello di Ogni Voce di Credenziale

Nome Campo

Descrizione

credential_type

RICHIESTO. Identificatore univoco dell'Attestazione del Wallet. DEVE essere impostato a WalletAttestation.

name

RICHIESTO. Nome "human-readable" dell'Attestazione del Wallet. DEVE essere impostato a Wallet Attestation.

description

RICHIESTO. Descrizione "human-readable" dell'Attestato Elettronico.

aal_values_supported

RICHIESTO. Array di Stringhe ognuna delle quali è un Livello di Garanzia (LoA) supportato dall'Attestazione del Wallet. DEVE includere almeno i livelli low, medium e high.

formats

RICHIESTO. Array di formati supportati per l'Attestazione del Wallet, inclusi:

  • format: Tipo di formato (ad esempio, dc+sd-jwt, mso_mdoc o oauth-client-attestation+jwt)

  • configuration_id: Identificatore di configurazione dell'Attestazione del Wallet. Questo è formato concatenando la stringa wa al format (ad esempio, dc_sd_jwt_wa, mso_mdoc_wa, o jwt_wa), ed è utilizzato per fare riferimento univocamente alla configurazione del formato dell'Attestazione del Wallet.

  • vct: CONDIZIONALE. È presente solo se il format è dc+sd-jwt. DEVE essere impostato come una Stringa URI della forma https://{dominio Trust Anchor}/{credential_type} (ad esempio, https://trust-registry.it-wallet.example.it/WalletAttestation). La corrispondenza dei letterali inclusi in questa stringa URI DEVE essere eseguita in modo case-insensitive.

  • docType: CONDIZIONALE. È presente solo se il format è mso_mdoc. È una stringa della forma {dominio inverso Trust Anchor}.{credential_type} (ad esempio, it.wallet.trust-registry.WalletAttestation).

  • schema_uri: URI che punta al documento di specifica del formato.

  • schema_uri#integrity: Digest crittografico del documento di specifica del formato per la verifica dell'integrità. DEVE essere una stringa della forma {digest_method}-{digest_value}, dove {digest_method} è l'algoritmo di digest utilizzato (ad esempio, sha-256) e {digest_value} è il valore del digest codificato in base64url.

claims

RICHIESTO. Array di claim contenute nell'Attestazione del Wallet. DEVE includere almeno i seguenti attributi:

  • Name: Il nome dell' attributo (ad esempio, sub, aal, wallet_link, wallet_name).

  • Namespaces: CONDIZIONALE. Array di namespace a cui appartiene l'attibuto. DEVE essere impostato a {dominio inverso Trust Anchor}.{credential_type} (ad esempio, it.wallet.trust-registry.WalletAttestation).

L'esempio corrispondente del Catalogo degli Attestati Elettronici come decodificato in JSON sia per header che payload è il seguente:

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

{
   "catalog_version": "1.0",
   "iss": "https://trust-registry.eid-wallet.example.it",
   "last_modified": "2025-03-15T12:00:00Z",
   "credentials": [
      {
         "version": "1.0",
         "credential_type": "mDL",
         "legal_type": "pub-eaa",
         "localization": {
            "default_locale": "it",
            "available_locales": ["en", "it", "fr", "de"],
            "base_uri": "https://trust-registry.eid-wallet.example.it/.well-known/l10n/mdl/",
            "version": "1.0.0"
         },
         "name_l10n_id": "credential.mdl.name",
         "description_l10n_id": "credential.mdl.description",
         "restriction_policy": {
            "allowed_wallet_ids": [
               "https://wallet-provider.example.org/wallet_solution",
               "https://wallet-provider2.example.org/wallet_solution"
            ],
            "allowed_issuer_ids": [
               "https://issuer.example.org"
            ]
         },
         "pricing_policy": {
             "models": [
               {
                 "pricing_type": "verification_based",
                 "price": 0.01,
                 "currency": "EUR"
               }
             ],
             "pricing_model_uri": "https://example.com/pricing"
           },
         "validity_info": {
            "max_validity_days": 365,
            "status_methods": ["status_list"],
            "allowed_states": [
               "valid",
               "revoked",
               "suspended"
            ]
         },       
         "authentication": {
            "user_auth_required": true,
            "min_loa": "high",
            "supported_schemes": ["it-wallet"]
         },
         "purposes": [
            {
               "id": "DRIVING_LICENSE"            
            },
            {
               "id": "PERSON_IDENTIFICATION"
            }
         ],
         "issuers": [
            {
               "id": "https://issuer.example.org",
               "organization_name": "Digital Credential Issuer of Example",
               "organization_code": "ci_example_it",
               "organization_country": "IT",
               "contacts": [
                  "mailto:informazioni@example.it",
                  "mailto:protocollo@pec.example.it"
               ],
               "legal_type": "pub-eaa",
               "homepage_uri": "https://issuer.example.org",
               "logo_uri": "https://issuer.example.org/logo.svg",
               "policy_uri": "https://issuer.example.org/privacy",
               "tos_uri": "https://issuer.example.org/terms",
               "service_documentation": "https://issuer.example.org/.well-known/service-doc",
               "issuance_flows": {
                  "deferred_flow": true,
                  "max_deferred_issuance_time_minutes": 1440,
                  "notification_methods": ["push", "polling"]
               }
            }
         ],
         "authentic_sources": [
            "https://motorizzazione.gov.example"
         ],
         "formats": [
            {
               "configuration_id": "dc_sd_jwt_mDL",
               "format": "dc+sd-jwt",
               "vct": "https://trust-registry.eid-wallet.example.it/1.0/mDL",
               "schema_uri": "https://trust-registry.eid-wallet.example.it/.well-known/schemas/sd-jwt/mDL",
               "schema_uri#integrity": "sha256-c8b708728e4c5756e35c03aeac257ca878d1f717d7b61f621be4d36dbd9b9c16"
            },
            {
               "configuration_id": "mso_mdoc_mDL",
               "format": "mso_mdoc",
               "docType": "org.iso.18013.5.1",
               "schema_uri": "https://trust-registry.eid-wallet.example.it/.well-known/schemas/mdoc/mDL",
               "schema_uri#integrity": "sha256-c8b708728e4c5756e35c03aeac257ca878d1f717d7b61f621be4d36dbd9b9c16"
            }
         ],
         "display_properties": {
            "templates": [
               {
                  "authentic_source_id": "https://authentic-sources.example.org",
                  "template_uri": "https://authsource.example.com/.well-known/templates/mDL.svg",
                  "template_uri#integrity": "sha256-8cLlJNXN-TsMk-PmKjZ5t0WRL5ca_xGgX3c1VLmXfh-9c",
                  "properties": {
                     "orientation": "landscape",
                     "color_scheme": "light",
                     "contrast": "high"
                  }
               }
            ],
            "background_color": "#008558",
            "text_color": "#FFFFFF",
            "logo_uri": "https://trust-registry.eid-wallet.example.it/.well-known/logos/mDL.svg"
         },
         "claims": [
            {
               "name": "family_name",
               "display_name_l10n_id": "claims.family_name.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "given_name",
               "display_name_l10n_id": "claims.given_name.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "birth_date",
               "display_name_l10n_id": "claims.birth_date.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "issue_date",
               "display_name_l10n_id": "claims.issue_date.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "expiry_date",
               "display_name_l10n_id": "claims.expiry_date.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "issuing_authority",
               "display_name_l10n_id": "claims.issuing_authority.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "document_number",
               "display_name_l10n_id": "claims.document_number.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "portrait",
               "display_name_l10n_id": "claims.portrait.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "driving_privileges",
               "display_name_l10n_id": "claims.driving_privileges.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "un_distinguishing_sign",
               "display_name_l10n_id": "claims.un_distinguishing_sign.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "administrative_number",
               "display_name_l10n_id": "claims.administrative_number.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "issuing_country",
               "display_name_l10n_id": "claims.issuing_country.name",
               "namespaces": ["org.iso.18013.5.1"]
            },
            {
               "name": "issuing_jurisdiction",
               "display_name_l10n_id": "claims.issuing_jurisdiction.name",
               "namespaces": ["org.iso.18013.5.1"]
            }
         ]
      }
   ],
   "wallet_attestation": {
      "version": "1.0",
      "credential_type": "WalletAttestation",
      "name": "Wallet Attestation",
      "description": "Attestation of the Wallet capabilities and compliance with the EUDI Wallet specifications.",
      "aal_values_supported": [
            "https://trust-list.eu/aal/low",
            "https://trust-list.eu/aal/medium",
            "https://trust-list.eu/aal/high"
         ],
      "formats": [
         {
            "format": "dc+sd-jwt",
            "configuration_id": "dc_sd_jwt_wa",
            "vct": "https://trust-registry.it-wallet.example.it/WalletAttestation",
            "schema_uri": "https://trust-registry.it-wallet.example.it/.well-known/schemas/sd-jwt/WalletAttestation",
            "schema_uri#integrity": "sha256-Lxn6dNpkPdoeoRgO5+n0jNhJZ8MbKfXfP195+dNR0dc="
         },
         {
            "format": "mso_mdoc",
            "configuration_id": "mso_mdoc_wa",
            "docType": "it.wallet.trust-registry.WalletAttestation",
            "schema_uri": "https://trust-registry.eid-wallet.example.it/.well-known/schemas/mdoc/WalletAttestation",
            "schema_uri#integrity": "sha256-GcqnMfzyCw+0UTz9EI6JO0oUTD0WS3p+hQ2E7VfjTLA="
         },
         {
            "format": "oauth-client-attestation+jwt",
            "configuration_id": "jwt_wa",
            "schema_uri": "https://trust-registry.it-wallet.example.it/.well-known/schemas/jwt/WalletAttestation",
            "schema_uri#integrity": "sha256-2s9AJsZwjuAZ4D4EAl3qDJGvy92sThQkX6W9zDF2Sgg="
         }
      ],
      "claims": [
         {
            "name": "sub",
            "namespaces": ["it.wallet.trust-registry.WalletAttestation"]
         },
         {
            "name": "aal",
            "namespaces": ["it.wallet.trust-registry.WalletAttestation"]
         },
         {
            "name": "wallet_link",
            "namespaces": ["it.wallet.trust-registry.WalletAttestation"]
         },
         {
            "name": "wallet_name",
            "namespaces": ["it.wallet.trust-registry.WalletAttestation"]
         }
      ]
   }
}

Nota

Per una gestione migliore e più efficiente della localizzazione delle informazioni contenute nel Catalogo degli Attestati Elettronici, un'Entità che lo consulta DOVREBBE:

  • Scaricare la versione base del Catalogo degli Attestati Elettronici (compatta, senza localizzazioni) utilizzando l'endpoint .well-known/credential-catalog.

  • Determinare la lingua preferita dell'Utente.

  • Scaricare solo i bundle di localizzazione necessari.

  • Unire dinamicamente il contenuto localizzato con la struttura del Catalogo degli Attestati Elettronici.

Un esempio non normativo di output di un bundle di localizzazione è fornito di seguito:

{
  "driving_license.name": "Patente di Guida",
  "driving_license.description": "Patente di guida ufficiale valida in Italia e nell'UE",
  "purpose.driving_authorization.name": "Abilitazione alla guida",
  "purpose.driving_authorization.description": "Verifica di Abilitazione alla guida",
  "claims.given_name.name": "Nome",
  "...": "..."
}

I bundle di localizzazione DEVONO essere disponibili all'URI specificato nell'attibuto localization_info.bundles_base_uri del Catalogo degli Attestati Elettronici. Ogni bundle locale DEVE essere accessibile seguendo il pattern di denominazione {locale_code}.json, dove {locale_code} è sostituito con il codice locale corrispondente dall'array available_locales.

Un esempio non normativo dell'URI di localizzazione italiana per il bundle mDL sarebbe https://trust-registry.eid-wallet.example.it/.well-known/l10n/mdl/it.json.

Le Entità DOVREBBERO verificare l'integrità dei bundle di localizzazione scaricati utilizzando il metodo di digest e i valori specificati nel claim localization_info.integrity. Questo garantisce che i dati di localizzazione non siano stati manomessi durante la trasmissione.

7.7. Tassonomia

La Tassonomia fornisce le fondamenta semantiche per l'interoperabilità degli Attestati Elettronici mantenendo il vocabolario autorevole per organizzare le credenziali all'interno dell'ecosistema IT-Wallet. La tassonomia è neutrale rispetto al formato delle credenziali e ha l'obiettivo di facilitare le integrazioni degli Attestati Elettronici nelle Soluzioni Tecniche IT-Wallet.

La tassonomia fornisce, in una singola risorsa, il sistema di classificazione gerarchica che organizza domini e scopi che possono essere applicati ai tipi di credenziali, supportando la valutazione delle policy di autorizzazione e la standardizzazione a livello di ecosistema.

Obiettivi della Tassonomia:

  1. Fondamento Semantico: Stabilire vocabolario standardizzato per domini e scopi in tutto l'ecosistema

  2. Framework delle Policy: Abilitare decisioni di autorizzazione strutturate basate sulla classificazione gerarchica

  3. Interoperabilità: Garantire interpretazione coerente delle classificazioni delle credenziali

  4. Estensibilità: Supportare l'evoluzione dell'ecosistema con nuovi domini e scopi

  5. Conformità Transfrontaliera: Allinearsi con i requisiti normativi UE e gli standard internazionali

Struttura della Tassonomia:

La tassonomia mantiene una struttura gerarchica a due livelli:

  • Domini: Classificazione di livello superiore che rappresenta aree funzionali ampie (ad esempio, IDENTITY, AUTHORIZATION, FINANCIAL)

  • Scopi: Casi d'uso specifici delle credenziali all'interno di ogni dominio (ad esempio, PERSON_IDENTIFICATION, DRIVING_LICENSE, BANK_ACCOUNT) per i quali le credenziali possono essere utilizzate

Supporto alla Localizzazione:

La tassonomia supporta ambienti multilingue attraverso il pattern del suffisso _l10n_id, abilitando una gestione efficiente della localizzazione per interfacce utente e implementazioni transfrontaliere.

Utilizzo della Tassonomia:

  • Registro degli Attributi: Catalogo degli attributi individuali

  • Registro AS: Le Fonti Autentiche dichiarano capacità di fornitura dati utilizzando classificazioni della tassonomia

  • Catalogo degli Attestati Elettronici: I tipi di credenziali specificano domini e scopi supportati

  • Policy di Autorizzazione: La valutazione delle policy sfrutta la struttura della tassonomia per decisioni di controllo degli accessi

La tassonomia è accessibile attraverso l'endpoint dedicato della tassonomia come definito nel meccanismo di discovery del registro ed è mantenuta dall'Organismo di Supervisione per garantire conformità normativa e coerenza semantica.

Un esempio non normativo della struttura della Tassonomia è fornito di seguito:

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

7.8. Integrazione del Registro e Riferimenti Incrociati

I componenti del registro sono interconnessi e lavorano insieme per supportare l'ecosistema completo delle credenziali:

  1. Registro AS ↔ Tassonomia: Le entità AS dichiarano capacità di fornitura utilizzando classificazioni della tassonomia per la categorizzazione standardizzata.

  2. Registro AS ↔ Catalogo: I tipi di credenziali fanno riferimento alle capacità AS per la validazione della fonte dati.

  3. Catalogo ↔ Tassonomia: Le voci delle credenziali specificano domini e scopi dalla tassonomia per discovery e autorizzazione.

  4. Registro della Federazione ↔ Tutti i Componenti: Fornisce validazione del trust crittografico per tutte le operazioni del registro e autenticazione delle entità.