5. Infrastructure of Trust¶
Questo capitolo specifica i Trust Artifact, i profili dei certificati e il loro ciclo di vita. La decisione di trust che usa tali artifact è specificata in Trust Evaluation Process. La registrazione e la pubblicazione delle entità sono specificate in Onboarding System and Lifecycle Management.
L'ecosistema IT-Wallet opera all'interno di un'infrastruttura di trust federata in cui le entità partecipanti stabiliscono relazioni di trust crittografiche e mantengono la conformità a standard di sicurezza comuni. Questa infrastruttura fornisce il fondamento per operazioni sicure sugli Attestati Elettronici tra i partecipanti dell'ecosistema.
Nell'IT-Wallet coesistono due Trust Framework. Il Trust Framework di ciascuna interazione è selezionato come specificato in Trust Framework Selection.
Il Trust Framework EUDIW è definito dal Regolamento eIDAS2 (EU_2024_1183), dai relativi regolamenti di esecuzione e dall'ARF (EIDAS-ARF). Una Wallet Unit che implementa solo le procedure EUDIW DEVE poter richiedere, presentare e verificare un PID, una (Q)EAA o una PuB-EAA emessi da un Provider di qualunque Stato membro. Tale Wallet Unit DEVE poter autenticare una Wallet-Relying Party di qualunque Stato membro che richiede tali Credenziali. I PID Provider, i QEAA Provider e i PuB-EAA Provider DEVONO supportare il Trust Framework EUDIW.
Il Trust Framework Nazionale è un overlay nazionale basato su OpenID Federation (OID-FED) combinato con una PKI X.509 per gli Attestati Elettronici ancorati a tale framework. È fuori dall'ARF. Fornisce registrazione, onboarding e discovery per le entità che operano nel perimetro nazionale. La discovery attraverso il Trust Framework Nazionale PUÒ includere le entità ancorate al Trust Framework EUDIW. Tale discovery non sostituisce la registrazione, la notifica o il percorso di trust EUDIW.
Questa sezione fornisce innanzitutto una panoramica delle entità e dei processi coinvolti nell'infrastruttura di trust (Overview). Definisce quindi il X.509 Certificate Profile generale e i Common Trust Artifacts condivisi da entrambi i framework, seguiti dagli artifact specifici di ciascun framework (EUDIW Trust Artifacts e National Trust Artifacts). Infine, descrive il relativo ciclo di vita (Trust Management and Lifecycle).
5.1. Overview¶
Per eseguire una trust evaluation, le entità effettuano prima l'onboarding nell'ecosistema (vedere Onboarding System and Lifecycle Management). Un Fornitore di EAA non qualificato e una Relying Party dichiarano lì il Trust Framework di ciascun ruolo, come specificato in Registration Profiles.
L'onboarding e, ove applicabile, la notifica europea rilasciano o aggiornano i Trust Artifact (vedere Common Trust Artifacts, EUDIW Trust Artifacts e National Trust Artifacts). La trust evaluation usa quindi tali artifact (vedere Trust Evaluation Process).
5.2. PKI Architecture¶
I Trust Artifact di entrambi i Trust Framework sono firmati con chiavi la cui parte pubblica è certificata da un'Autorità di Certificazione. Questa sezione fornisce la vista architetturale di tali Autorità di Certificazione. Definisce quali di esse sono operate all'interno dell'IT-Wallet, quali certificati ciascuna emette, e quale Trust Anchor è derivato da ciascuna e attraverso quale canale tale Trust Anchor è distribuito.
Il contenuto dei certificati non è definito in questa sede. I requisiti comuni sono definiti in X.509 Certificate Profile e i requisiti specifici di ciascun certificato sono definiti insieme all'artifact che lo utilizza. L'emissione dei certificati è parte dell'onboarding (vedere Onboarding Processes). L'uso dei Trust Anchor a runtime è definito in EUDIW Trust Anchor Validation per il Trust Framework EUDIW e in Signing Trust Anchor Distribution, Wallet Trust Anchor Distribution e Authentication Trust Anchor Distribution per il Trust Framework Nazionale.
5.2.1. Certification Hierarchies¶
All'interno dell'IT-Wallet è operata una singola Root Certification Authority nazionale. Essa emette i certificati delle Autorità di Certificazione subordinate e non è utilizzata per alcun altro scopo. Ciascuna Autorità di Certificazione subordinata serve un servizio, e il suo certificato è il Trust Anchor pubblicato per tale servizio.
La tabella seguente elenca le Autorità di Certificazione, i certificati emessi da ciascuna di esse e il canale attraverso il quale è distribuito il Trust Anchor derivato. Le List of Trusted Entities e le Trusted List nominate nella tabella sono definite in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.
Autorità di Certificazione |
Certificati Emessi |
Distribuzione del Trust Anchor |
|---|---|---|
PID Provider Sign/Seal CA |
PID Providers LoTE. |
|
Wallet Provider Sign/Seal CA |
Wallet Providers LoTE nel Trust Framework EUDIW, e la Federation Trust Anchor Entity Configuration come canale di distribuzione del National Wallet Trust Anchor nel Trust Framework Nazionale (vedere Wallet Trust Anchor Distribution). |
|
WRPAC CA |
Certificati di accesso conformi al Wallet-Relying Party Access Certificate (WRPAC) Profile, emessi alle Wallet-Relying Party. |
Providers of WRPAC LoTE. Lo stesso Trust Anchor è inoltre pubblicato nella PID Providers LoTE, perché i trust anchor delle Access Certification Authorities per i PID Provider sono notificati all'interno della notifica del PID Provider, separatamente da quelli per le Wallet-Relying Party (vedere [EIDAS-ARF], Topic 31). |
National Authentication CA |
Certificati di autenticazione della Relying Party utilizzati nel Proximity Flow. Seguono lo stesso profilo del Wallet-Relying Party Access Certificate. |
Entity Configuration del Federation Trust Anchor, come Authentication Trust Anchor (vedere Authentication Trust Anchor Distribution). |
WRPRC Sign/Seal CA |
Il Sign/Seal Certificate del Provider of WRPRC (vedere Wallet-Relying Party Registration Certificate (WRPRC) Profile). |
Providers of WRPRC LoTE. |
Registrar Sign/Seal CA |
Registrar LoTE. |
|
National EAA Sign/Seal CA |
(Q)EAA Provider Sign/Seal Certificate, per gli Attestati Elettronici ancorati al Trust Framework Nazionale. |
Entity Configuration del Federation Trust Anchor, come Signing Trust Anchor (vedere Signing Trust Anchor Distribution). Per una EAA emessa nel Trust Framework EUDIW il Trust Anchor è referenziato nell'Attestation Rulebook, come descritto in Trust Anchor Certificate Profile. |
Qualified CA of the QEAA Provider |
(Q)EAA Provider Sign/Seal Certificate, per la QEAA. |
Member State Trusted List, pubblicata in conformità all'Articolo 22 di [EIDAS]. |
Qualified CA of the PuB-EAA Provider |
PuB-EAA Provider Sign/Seal Certificate, il certificato qualificato a supporto del sigillo elettronico qualificato dell'ente del settore pubblico (Articolo 45f(1)(b) di [EIDAS]). |
Member State Trusted List, pubblicata in conformità all'Articolo 22 di [EIDAS]. |
La Qualified CA del QEAA Provider e la PuB-EAA Provider Sign/Seal CA non sono subordinate alla Root Certification Authority nazionale. Entrambe appartengono al perimetro di un Qualified Trust Service Provider e seguono il proprio regime di vigilanza e pubblicazione. Il Sign/Seal Certificate di un PuB-EAA Provider è un sigillo elettronico qualificato emesso da un Qualified Trust Service Provider (Articolo 45f di [EIDAS]).
5.2.1.1. Revocation Trust Anchors¶
Nell'ambito di queste specifiche, si applicano le seguenti condizioni aggiuntive relative ai Trust Anchor di revoca:
Nell'ambito del Trust Framework EUDIW, i Trust Anchor utilizzati per validare i meccanismi di revoca delle catene di certificati WRPRC, PID e PuB-EAA sono i Trust Anchor notificati delle corrispondenti PKI di firma.
Nell'ambito del Trust Framework Nazionale, i Signing Trust Anchor degli EAA Provider sono anche i Trust Anchor utilizzati per validare lo stato di revoca delle catene di certificati di firma EAA.
Per le Wallet Instance Attestation e le Key Attestation, il Fornitore di Wallet DEVE utilizzare lo stesso Trust Anchor per la validazione della firma e per la validazione delle informazioni di stato o di revoca applicabili. Nel Trust Framework EUDIW, questo Trust Anchor è pubblicato nella Wallet Providers LoTE. Nel Trust Framework Nazionale, lo stesso materiale di chiave è distribuito come National Wallet Trust Anchor attraverso la Federation Trust Anchor Entity Configuration (vedere Wallet Trust Anchor Distribution).
Quando un Fornitore di Wallet opera in entrambi i Trust Framework, il suo National Wallet Trust Anchor DEVE essere lo stesso certificato del Trust Anchor notificato alla Commissione Europea. Quel Trust Anchor è pubblicato nella Wallet Providers LoTE sotto la
ServiceDigitalIdentitydel Fornitore di Wallet. La Entity Configuration nazionale è un canale di distribuzione aggiuntivo. La Entity Configuration nazionale NON DEVE introdurre un secondo Trust Anchor.
Nota
L'Autorità di Certificazione che emette i Wallet-Relying Party Access Certificate e l'Autorità di Certificazione che emette i certificati di autenticazione della Relying Party del Trust Framework Nazionale utilizzano lo stesso profilo di certificato.
Nota
Le Federation Entity Key non sono certificate dalle Autorità di Certificazione descritte in questa sezione. Il vincolo tra una Federation Entity e le sue chiavi è fornito dalla Entity Configuration e dal Subordinate Statement emesso dal suo superiore, che sono validati attraverso la Federation Trust Chain e non con una catena di certificati (vedere National Trust Artifacts). La Entity Configuration del Federation Trust Anchor è utilizzata come canale di distribuzione dei Trust Anchor delle gerarchie X.509.
5.2.2. Design Principles¶
Le gerarchie descritte sopra seguono i principi elencati di seguito.
Una Sign/Seal Certification Authority per ruolo notificato. Ciascun ruolo che firma o sigilla un artifact ha una distinta Sign/Seal Certification Authority.
Una singola WRPAC Certification Authority. All'interno dell'IT-Wallet i certificati di accesso sono emessi da una singola Autorità di Certificazione. Tale Autorità di Certificazione li emette sia alle Wallet-Relying Party sia ai PID Provider. Tali certificati seguono lo stesso profilo e la stessa certificate policy. I certificati di autenticazione della Relying Party del Trust Framework Nazionale sono emessi da una distinta Autorità di Certificazione.
Nessun Trust Anchor senza un consumatore. All'interno dell'IT-Wallet un Trust Anchor è pubblicato in un canale di distribuzione solo quando una procedura di trust evaluation definita in questa specifica lo ottiene da tale canale.
La Root Certification Authority è al di fuori della catena di certificati. Il certificato Trust Anchor è il punto di terminazione del trust della path validation (vedere Trust Anchor Certificate Profile). La Root Certification Authority non è mai valutata a runtime. Il suo certificato non è pubblicato in alcuna lista. La Root Certification Authority fornisce una governance comune alle Autorità di Certificazione subordinate e nessuna relazione di trust di per sé. Una compromissione della Root Certification Authority non è rilevata dalla path validation ordinaria e, all'interno dell'IT-Wallet, è gestita re-emettendo e ri-notificando i Trust Anchor interessati.
Solo end entity al di sotto di un Trust Anchor pubblicato. All'interno dell'IT-Wallet il Trust Anchor pubblicato è l'Autorità di Certificazione subordinata del servizio. Nessun ulteriore strato di Autorità di Certificazione è emesso al di sotto di quel Trust Anchor. Ciò è coerente con la raccomandazione
pathLenConstraintdi Trust Anchor Certificate Profile.Separazione delle chiavi per scopo. Un Trust Anchor pubblicato per uno scopo non è utilizzato per certificare gli artifact di un altro scopo. Un'entità verificatrice deve poter distinguere quali Trust Anchor sono utilizzabili per quale categoria di Attestation, come richiesto da [EIDAS-ARF].
5.3. X.509 Certificate Profile¶
Questa sezione definisce un X.509 Certificate Profile generale, ulteriormente specializzato per i seguenti artifact:
Entity Sign/Seal Certificate Profile (Trust Framework EUDIW e Nazionale).
Trust Anchor Certificate Profile (Trust Framework EUDIW e Nazionale).
Wallet-Relying Party Access Certificate (WRPAC) Profile (Trust Framework EUDIW).
Registrar Sign/Seal Certificate Profile (Trust Framework EUDIW).
Questo profilo stabilisce i requisiti di sintassi, semantica e codifica per i certificati X.509 sulla base di RFC 5280 e ETSI EN 319 412. Ciascun profilo di certificato X.509 definito da questa specifica DEVE conformarsi ai requisiti di questa sezione, salvo diversa indicazione esplicita.
Campo |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. |
Section 4.1.1.1 |
|
OBBLIGATORIO. |
Section 4.1.1.2 |
|
OBBLIGATORIO. |
Section 4.1.1.3 |
Nota
Il resto della sezione dettaglia il solo contenuto del campo tbsCertificate. Per informazioni aggiuntive sui campi signatureAlgorithm e signatureValue, fare riferimento a RFC 5280.
Il campo tbsCertificate DEVE contenere una struttura TBSCertificate. I campi TBSCertificate DEVONO conformarsi a RFC 5280#section-4.1.2.
La tabella seguente definisce i campi del certificato applicabili al profilo di certificato specificato in questo documento. Per ciascun campo, la tabella definisce il requisito di presenza, il tipo, la descrizione e il corrispondente riferimento in RFC 5280. I singoli profili di certificato POSSONO fornire note contestuali aggiuntive per tali campi. I singoli profili di certificato NON DEVONO modificare i requisiti di presenza ivi specificati.
Campo |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. DEVE essere la versione 3 (valore |
Section 4.1.2.1 |
|
OBBLIGATORIO. |
Section 4.1.2.2 |
|
OBBLIGATORIO. L'algoritmo referenziato DEVE essere tra quelli definiti in Algoritmi Crittografici. |
Section 4.1.2.3, Section 4.1.1.2 |
|
OBBLIGATORIO. DEVE conformarsi ai requisiti applicabili di [ETSI EN 319 412-2] (Clausola 4.2.3.1 per le persone giuridiche, Clausola 4.2.3.2 per le persone fisiche), come specificato dal corrispondente profilo di certificato. |
Section 4.1.2.4 |
|
OBBLIGATORIO. |
Section 4.1.2.5 |
|
OBBLIGATORIO. DEVE conformarsi ai requisiti applicabili di [ETSI EN 319 412-2] (Clausola 4.2.4) per le persone fisiche e di [ETSI EN 319 412-3] (Clausola 4.2.1) per le persone giuridiche, come specificato dal corrispondente profilo di certificato. |
Section 4.1.2.6 |
|
OBBLIGATORIO. L'algoritmo referenziato DEVE essere tra quelli definiti in Algoritmi Crittografici. |
Section 4.1.2.7 |
|
OPZIONALE. NON DOVREBBE essere presente. |
Section 4.1.2.8 |
|
OPZIONALE. NON DOVREBBE essere presente. |
Section 4.1.2.8 |
|
OBBLIGATORIO. DEVE conformarsi alla struttura definita in RFC 5280#section-4.2. Le estensioni applicabili e i relativi vincoli specifici del profilo sono definiti di seguito e nel corrispondente profilo di certificato. |
Section 4.1.2.9 |
La tabella seguente specifica le estensioni dei certificati X.509 supportate da questa specifica, inclusi i relativi Object Identifier (OID), il tipo, la criticità, la descrizione e i riferimenti normativi. I singoli profili di certificato DEVONO definire il requisito di presenza per ciascuna estensione. Il valore OBBLIGATORIO si applica quando l'estensione è sempre presente. Il valore OPZIONALE si applica quando l'estensione può essere omessa. Vietato si applica quando l'estensione è proibita. I singoli profili di certificato POSSONO ulteriormente vincolare la sintassi e i contenuti di ciascuna estensione.
I valori di criticità utilizzati in questa specifica hanno il seguente significato:
C: l'estensione DEVE essere marcata come critica.
NC: l'estensione DEVE essere marcata come non critica.
Estensione |
OID |
Criticità |
Riferimento |
|---|---|---|---|
|
|
NC |
RFC 5280#section-4.2.1.1, Clausola 4.3.1 di [ETSI EN 319 412-2] |
|
|
NC |
|
|
|
C |
RFC 5280#section-4.2.1.3, Clausola 4.3.2 di [ETSI EN 319 412-2], Clausola 4.3.1 di [ETSI EN 319 412-3] |
|
|
NC |
RFC 5280#section-4.2.1.4, Clausola 4.3.3 di [ETSI EN 319 412-2] |
|
|
NC |
RFC 5280#section-4.2.1.6, Clausola 4.3.5 di [ETSI EN 319 412-2], Clausola 6.6.1, GEN-6.6.1-07 di [ETSI TS 119 411-8] |
|
|
NC |
|
|
|
C |
|
|
|
NC |
RFC 5280#section-4.2.1.13, Clausola 4.3.11 di [ETSI EN 319 412-2] |
|
|
NC |
RFC 5280#section-4.2.2.1, Clausola 4.4.1 di [ETSI EN 319 412-2] |
|
|
NC |
Clausola 5.2.2 di [ETSI EN 319 412-1] |
|
|
NC |
|
|
|
NC |
RFC 3739#section-3.2.6, Clausola 4.2 di [ETSI EN 319 412-5] |
Avvertimento
Prevenzione delle Dipendenze Circolari negli URI
Per prevenire dipendenze circolari di validazione durante gli handshake TLS, gli URI definiti nelle estensioni cRLDistributionPoints e authorityInfoAccess DEVONO utilizzare lo schema http:// invece di https://, come suggerito da RFC 5280#section-8.
5.4. Common Trust Artifacts¶
Questa sezione dettaglia gli artifact comuni coinvolti sia nel Trust Framework EUDIW sia in quello Nazionale, inclusi:
5.4.1. Entity Sign/Seal Certificate Profile¶
Questa sezione estende il X.509 Certificate Profile generale e specifica un Certificate Profile per gli Entity Sign/Seal Certificates, che sono usati per firmare e sigillare varie Attestation. Questo profilo è originariamente definito in ETSI TS 119 412-6.
Avvertimento
I profili Entity Sign/Seal Certificate definiti in questa specifica assumono che gli Entity Sign/Seal Certificate siano emessi da una CA e non siano self-signed. Un certificato self-signed destinato ad agire come Trust Anchor PUÒ essere usato in interoperabilità. I National Sign/Seal Certificate DEVONO essere conformi ai requisiti definiti in Trust Anchor Certificate Profile e Certification Hierarchies, che richiedono che i National Trust Anchor siano vincolati a una root comune.
5.4.1.1. PID Provider Sign/Seal Certificate¶
I requisiti specifici per i PID Provider Sign/Seal Certificate sono specificati nella Clausola 4 di [ETSI TS 119 412-6].
La tabella seguente definisce l'insieme completo di estensioni applicabili al profilo di certificato. Le estensioni non elencate nella tabella NON DEVONO essere presenti.
Extension |
Descrizione |
|---|---|
|
OBBLIGATORIO. Il valore del campo |
|
OBBLIGATORIO. Il suo valore DOVREBBE essere derivato dalla chiave pubblica del subject usando i metodi definiti in RFC 5280#section-4.2.1.2. |
|
OBBLIGATORIO. DEVE contenere uno (e uno solo) dei key-usage settings Type A, Type B, Type C o Type F. Per dettagli aggiuntivi, vedi Clausola 4.4.1 [ETSI TS 119 412-6], Clausola 4.3.2 [ETSI EN 319 412-2] e Clausola 4.3.1 [ETSI EN 319 412-3]. |
|
OBBLIGATORIO. DEVE includere una struttura |
|
OBBLIGATORIO. |
|
OBBLIGATORIO SE: il certificato non include alcuna access location di un responder OCSP o l'estensione validity assured come definita in ETSI EN 319 412-1. Se presente, DEVE contenere almeno un riferimento a una CRL pubblicamente disponibile. |
|
OBBLIGATORIO. DEVE includere una struttura Se l'OCSP è supportato dalla CA emittente, l'estensione DEVE includere una struttura |
|
OBBLIGATORIO. DEVE contenere una struttura PUÒ contenere strutture |
Di seguito un esempio non normativo di PID Provider Sign/Seal Certificate per persone giuridiche.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x6F3A0B91D2...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of PID Provider",
commonName: "PID Provider Example",
organizationIdentifier: "LEIXG-5493021KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.2042.1.2", // ncpplus
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://pid.example.test/support"),
GeneralName.rfc822Name("support@pid.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222333"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
critical: false,
value: AuthorityInfoAccess [
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
accessLocation: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement {
statementId: "0.4.0.1862.1.6", // id-etsi-qcs-QcType
statementInfo: QcType [
"0.4.0.194126.1.1" // id-etsi-qct-pid
]
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.1.2. Wallet Provider Sign/Seal Certificate¶
I requisiti specifici per i Wallet Provider Sign/Seal Certificate sono specificati nella Clausola 5 di [ETSI TS 119 412-6].
La tabella seguente definisce l'insieme completo di estensioni applicabili al profilo di certificato. Le estensioni non elencate nella tabella NON DEVONO essere presenti.
Extension |
Descrizione |
|---|---|
|
OBBLIGATORIO. Il valore del |
|
OBBLIGATORIO. Il suo valore DOVREBBE essere derivato dalla chiave pubblica del subject usando i metodi definiti in RFC 5280#section-4.2.1.2. |
|
OBBLIGATORIO. DEVE contenere uno (e uno solo) dei key-usage settings Type A, Type B, Type C o Type F. Per dettagli aggiuntivi, vedi Clausola 4.4.1 [ETSI TS 119 412-6], Clausola 4.3.2 [ETSI EN 319 412-2] e Clausola 4.3.1 [ETSI EN 319 412-3]. |
|
OBBLIGATORIO. DEVE includere una struttura
|
|
OBBLIGATORIO. |
|
OBBLIGATORIO SE: il certificato non include alcuna access location di un responder OCSP o l'estensione validity assured come definita in ETSI EN 319 412-1. Se presente, DEVE contenere almeno un riferimento a una CRL pubblicamente disponibile. |
|
OBBLIGATORIO. DEVE includere una struttura Se l'OCSP è supportato dalla CA emittente, l'estensione DEVE includere una struttura |
|
OBBLIGATORIO. DEVE contenere una struttura PUÒ contenere strutture |
Di seguito un esempio non normativo di Wallet Provider Sign/Seal Certificate per persone giuridiche.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x8D73F82C13...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName {
countryName: "CZ",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of Wallet Provider",
commonName: "Wallet Provider Example",
organizationIdentifier: "LEIXG-5823001KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.2042.1.2", // ncpplus
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://wp.example.test/support"),
GeneralName.rfc822Name("support@wp.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222444"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
critical: false,
value: AuthorityInfoAccess [
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
accessLocation: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement {
statementId: "0.4.0.1862.1.6", // id-etsi-qcs-QcType
statementInfo: QcType [
"0.4.0.194126.1.2" // id-etsi-qct-wal
]
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.1.3. (Q)EAA Provider Sign/Seal Certificate¶
I requisiti specifici per i Sign/Seal Certificate di EAA Provider e QEAA Provider sono specificati rispettivamente nelle Clausole 6 e 7 di [ETSI TS 119 412-6].
La tabella seguente definisce l'insieme completo di estensioni applicabili al profilo di certificato. Le estensioni non elencate nella tabella NON DEVONO essere presenti.
Extension |
Descrizione |
|---|---|
|
OBBLIGATORIO. Il valore del campo |
|
OPZIONALE. Se presente, il suo valore DOVREBBE essere derivato dalla chiave pubblica del subject usando i metodi definiti in RFC 5280#section-4.2.1.2. |
|
OBBLIGATORIO. DEVE contenere uno (e uno solo) dei key-usage settings Type A, Type B, Type C, o Type F. Per dettagli aggiuntivi, vedi Clausola 4.3.2 [ETSI EN 319 412-2] e Clausola 4.3.1 [ETSI EN 319 412-3]. |
|
OBBLIGATORIO (solo per QEAA). Come descritto nella Clausola 6.6.1 di [ETSI EN 319 411-2]. |
|
OBBLIGATORIO. |
|
OBBLIGATORIO SE: il certificato non include alcuna access location di un responder OCSP o l'estensione validity assured come definita in ETSI EN 319 412-1. Se presente, DEVE contenere almeno un riferimento a una CRL pubblicamente disponibile. |
|
OBBLIGATORIO (solo per QEAA). DEVE includere una struttura Se l'OCSP è supportato dalla CA emittente, l'estensione DEVE includere una struttura |
|
OBBLIGATORIO (QEAA), OPZIONALE (EAA). Per QEAA: DEVE contenere una struttura Per entrambi:
|
Sia per i QEAA sia per gli EAA Provider, se gestiscono il ciclo di vita degli Attestati Elettronici che emettono e usano liste di revoca firmate come Token Status List, DEVONO usare lo stesso Sign/Seal Certificate per firmare/sigillare la lista di revoca.
Di seguito un esempio non normativo di QEAA Provider Sign/Seal Certificate per persone giuridiche.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x7364DE67A6...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of QEAA Provider",
commonName: "QEAA Provider Example",
organizationIdentifier: "LEIXG-5494001KJTIIGC8Y1R56"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194112.1.3", // qcp-legal-qscd
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://eaa.example.test/support"),
GeneralName.rfc822Name("support@eaa.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222555"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
critical: false,
value: AuthorityInfoAccess [
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
accessLocation: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement { // esi4-qcStatement-1
statementId: "0.4.0.1862.1.1", // id-etsi-qcs-QcCompliance
},
QCStatement { // esi4-qcStatement-4
statementId: "0.4.0.1862.1.4", // id-etsi-qcs-QcSSCD
},
QCStatement {
statementId: "0.4.0.1862.1.6", // id-etsi-qcs-QcType
statementInfo: QcType [
"0.4.0.1862.1.6.1" // id-etsi-qct-esign
]
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.1.4. PuB-EAA Provider Sign/Seal Certificate¶
Avvertimento
Sebbene i requisiti specifici per i PuB-EAA Provider Sign/Seal Certificate specificati nella Clausola 8 di [ETSI TS 119 412-6] non richiedano che questo profilo sia qualificato, l'Art. 45f(1)(b) di [EU_2024_1183] richiede che le Attestation di tipo PuB-EAA siano firmate con un certificato qualificato. Per soddisfare entrambi i requisiti, sebbene non dichiarato né in [EIDAS-ARF] né in [ETSI TS 119 412-6], questo profilo unisce i profili QEAA e PuB-EAA Provider Sign/Seal Certificate specificati nelle Clausole 7 e 8 di [ETSI TS 119 412-6].
La tabella seguente definisce l'insieme completo di estensioni applicabili al profilo di certificato. Le estensioni non elencate nella tabella NON DEVONO essere presenti.
Extension |
Descrizione |
|---|---|
|
OBBLIGATORIO. Il valore del campo |
|
OPZIONALE. Se presente, il suo valore DOVREBBE essere derivato dalla chiave pubblica del subject usando i metodi definiti in RFC 5280#section-4.2.1.2. |
|
OBBLIGATORIO. |
|
OBBLIGATORIO. Come descritto nella Clausola 6.6.1 di [ETSI EN 319 411-2]. |
|
OBBLIGATORIO. |
|
OBBLIGATORIO SE: il certificato non include alcuna access location di un responder OCSP o l'estensione validity assured come definita in ETSI EN 319 412-1. Se presente, DEVE contenere almeno un riferimento a una CRL pubblicamente disponibile. |
|
OBBLIGATORIO. DEVE includere una struttura Se l'OCSP è supportato dalla CA emittente, l'estensione DEVE includere una struttura |
|
OBBLIGATORIO. DEVE contenere:
PUÒ contenere strutture |
Avvertimento
L'Allegato A di [ETSI TS 119 412-6] non definisce l'OID specifico dell'identificatore di statement id-etsi-qcs-QcPSB.
Di seguito un esempio non normativo di PuB-EAA Provider Sign/Seal Certificate per persone giuridiche.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x6354A56B5D...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of PuB-EAA Provider",
commonName: "PuB-EAA Provider Example",
organizationIdentifier: "LEIXG-5494201KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194112.1.3", // qcp-legal-qscd
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://pub-eaa.example.test/support"),
GeneralName.rfc822Name("support@pub-eaa.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222777"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
critical: false,
value: AuthorityInfoAccess [
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
accessLocation: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement { // esi4-qcStatement-1
statementId: "0.4.0.1862.1.1", // id-etsi-qcs-QcCompliance
},
QCStatement { // esi4-qcStatement-4
statementId: "0.4.0.1862.1.4", // id-etsi-qcs-QcSSCD
},
QCStatement {
statementId: "TBD", // id-etsi-qcs-QcPSB (OID not yet defined)
statementInfo: QcPSB {
countryOfLegislation: "IT",
authSourceIdentification: "https://www.anpr.interno.it",
legislationIdentification: "https://www.normattiva.it/eli/id/2005/05/16/005G0106/sg"
}
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.2. Trust Anchor Certificate Profile¶
Questa sezione estende il X.509 Certificate Profile generale e specifica un Certificate Profile per i Trust Anchors. Un Trust Anchor è una chiave pubblica fidata (e i dati associati) usata come input per X509 Certificate Chain Validation Algorithm. In questo profilo, il Trust Anchor DEVE essere rappresentato e distribuito come un certificato X.509. Tale certificato PUÒ essere self-signed.
Le Relying Party, i Credential Issuer e le Wallet Unit validano un Access, Registration o Sign/Seal Certificate presentato costruendo una catena di certificati. La catena di certificati DEVE iniziare con il certificato end-entity presentato. La catena di certificati DEVE terminare con un certificato firmato dal subject di un certificato Trust Anchor.
Il certificato Trust Anchor è usato come punto di terminazione della fiducia per il processo di path validation (cioè, è il valore della variabile trust_anchor in X509 Certificate Chain Validation Algorithm).
Le implementazioni DEVONO supportare la validazione sia di certificati Trust Anchor self-signed sia non self-signed.
Nota
Trust Anchor Location
La location del Trust Anchor Certificate è determinata dal Trust Framework specifico selezionato (vedi EUDIW Trust Anchor Validation e Federation Trust Anchor Validation).
La tabella seguente definisce i requisiti specifici del profilo per i campi del certificato. I campi non elencati nella tabella restano soggetti ai requisiti definiti nel X.509 Certificate Profile comune.
Field |
Requisiti aggiuntivi |
|---|---|
|
Se il certificato è self-signed, il distinguished name dell'issuer DEVE essere identico al distinguished name del subject. Altrimenti, il distinguished name dell'issuer DEVE identificare l'entità che ha firmato ed emesso il certificato e PUÒ differire dal distinguished name del subject. |
|
Il distinguished name DEVE contenere un attributo |
Extension |
Descrizione |
|---|---|
|
OBBLIGATORIO SE: il certificato non è self-signed.
Per i certificati self-signed, è RACCOMANDATO.
Se l'estensione è presente, il valore del campo |
|
OBBLIGATORIO. Fornisce un key identifier per la chiave pubblica del Trust Anchor. Il suo valore DOVREBBE essere derivato dalla chiave pubblica del subject usando i metodi definiti in RFC 5280#section-4.2.1.2. Questa estensione DOVREBBE supportare una costruzione affidabile della catena di certificati e l'abbinamento dei certificati nei deployment basati su LoTE o TL. |
|
OBBLIGATORIO. DEVE asserire il bit |
|
OPZIONALE. PUÒ includere una struttura |
|
OBBLIGATORIO. Il campo |
|
OPZIONALE. PUÒ includere URI di CRL distribution point, quando è usata la revoca basata su CRL. |
|
OPZIONALE. Se applicabile, PUÒ includere una struttura PUÒ anche includere una struttura |
|
OPZIONALE. PUÒ contenere strutture In ogni caso, NON DEVE contenere una struttura |
Nota
Trust Anchor Signature
Un certificato Trust Anchor PUÒ essere self-signed (rappresentando una root CA) o non self-signed (rappresentando una CA intermedia designata come Trust Anchor per policy). Le Relying Party NON DEVONO richiedere un issuer aggiuntivo al di sopra di un Trust Anchor recuperato come specificato dal Trust Framework applicabile, anche se non è self-signed, perché il Trust Anchor è un input autorevole all'algoritmo di path validation designato per policy.
Nota
Come descritto nella Sezione 4.3.1 di [EUDI-TS 12], il Trust Anchor di un EAA Sign/Seal Certificate è referenziato nell'attributo trustedAuthority dell'Attestation Rulebook machine-readable per la specifica EAA.
Di seguito un esempio non normativo di Trust Anchor Certificate.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x9D846F726A8..",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes
countryName: "IT",
organizationName: "Example Root CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-127263789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("460127000000Z")
},
subject: DistinguishedName { // Subject attributes
countryName: "IT",
organizationName: "Example Root CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-127263789"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
keyCertSign: true,
cRLSign: true
// All other bits set to false
}
},
Extension {
oid: "2.5.29.19", // basicConstraints
critical: true,
value: BasicConstraints {
cA: true,
pathLenConstraint: 0
}
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.5. EUDIW Trust Artifacts¶
Questa sezione definisce i trust artifact richiesti e i loro ruoli concettuali nell'ecosistema EUDIW secondo EIDAS-ARF, inclusi:
Wallet-Relying Party Registration Certificate (WRPRC) Profile.
Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.
Il modello dati di questi Trust Artifact profila le seguenti specifiche esterne.
ETSI TS 119 602, che definisce il modello dati delle List of Trusted Entities e i profili delle list EUDIW.
ETSI TS 119 411-8, che definisce il Wallet-Relying Party Access Certificate.
ETSI TS 119 475, che definisce il Wallet-Relying Party Registration Certificate insieme alle sue entitlement.
ETSI EN 319 412-1, che definisce gli attributi del subject dei certificati.
ETSI TS 119 182-1, che definisce il formato JAdES della firma di una List of Trusted Entities.
ETSI EN 319 132-1, che definisce il formato XAdES della firma di Trusted List e List of Trusted List.
5.5.1. Register of WRPs¶
Il Register of WRPs nazionale è il sistema accessibile pubblicamente (dataset + API) che fornisce dichiarazioni di registrazione firmate/sigillate relative alle WRP, ai loro Services, e alle loro autorizzazioni/usi dichiarati.
Il dataset e l'API di lettura del Register sono EUDI-TS 5, oggetti WalletRelyingParty e WalletRelyingPartyService, e soddisfano l'Allegato II di CIR2025/848 come modificato da [CIR2026/1730].
Nota
Deviazione di profilo. L'identificatore del Relying Party Service, e l'emissione di più di un Wallet-Relying Party Access Certificate o di un Wallet-Relying Party Registration Certificate per Wallet-Relying Party ([EIDAS-ARF] Reg_10a, Reg_10d, Reg_33, Reg_34a e RPRC_07a), non sono requisiti di questa specifica finché ETSI e le Technical Specification dell'ARF non ne definiscono l'implementazione.
EUDI-TS 5 marca serviceIdentifier come [0..1].
ETSI TS 119 411-8 non definisce ancora un attributo per tale identificatore, e ETSI TS 119 475 non definisce ancora srv_id.
Fino ad allora, questa specifica non richiede serviceIdentifier, un'entità ottiene un solo WRPAC, e il Provider of WRPRC emette un solo WRPRC per quell'entità.
5.5.1.1. Register Dataset¶
Il formato dati per le informazioni disponibili attraverso l'API aperta fornita dal Register of WRPs nazionale DEVE essere conforme agli schemi dati descritti nelle Tabelle 1-11 dell'Allegato VI di [CIR2025/848] come modificato da [CIR2026/1730], codificati come JSON Schema WalletRelyingParty di EUDI-TS 5.
Di seguito alcuni esempi non normativi di oggetti WalletRelyingParty memorizzati nel Register.
Una banca registrata come Relying Party che richiede PID per procedure know-your-customer, con un Relying Party Service.
{
"legalPerson": {
"legalName": ["ExampleBank S.p.A."]
},
"identifier": [
{
"type": "http://data.europa.eu/eudi/id/EUID",
"identifier": "IT-EUID-123456789"
},
{
"type": "http://data.europa.eu/eudi/id/VATIN",
"identifier": "IT98765432101"
}
],
"postalAddress": [
"Via dei Mille, Roma, IT"
],
"country": "IT",
"email": [
"wallet-rp-registration@examplebank.eu"
],
"phone": [
"+39100000000"
],
"infoURI": [
"https://examplebank.eu"
],
"providerType": "WalletRelyingParty",
"policy": [
{
"type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
"policyURI": "https://examplebank.eu/terms"
},
{
"type": "http://data.europa.eu/eudi/policy/privacy-policy",
"policyURI": "https://examplebank.eu/privacy"
}
],
"tradeName": "ExampleBank",
"isPSB": false,
"supervisoryAuthority": {
"name": "Garante per la protezione dei dati personali",
"country": "IT",
"email": ["contact@supervisor.example.it"],
"formURI": ["https://supervisor.example.it"]
},
"registryURI": "https://registry.example.it/api",
"services": [
{
"serviceTradeName": "ExampleBank Mobile",
"supportURI": "https://examplebank.eu/support",
"email": "wallet-rp-registration@examplebank.eu",
"phone": "+39100000000",
"srvDescription": [
[
{
"lang": "en",
"content": "Retail banking services for individuals."
},
{
"lang": "it",
"content": "Servizi bancari per privati."
}
]
],
"entitlements": [
"https://uri.etsi.org/19475/Entitlement/Service_Provider"
],
"isIntermediary": false,
"intendedUses": [
{
"intendedUseIdentifier": "iu-001",
"purpose": [
{
"lang": "en",
"content": "Open a bank account remotely."
}
],
"privacyPolicy": [
{
"type": "http://data.europa.eu/eudi/policy/privacy-statement",
"policyURI": "https://examplebank.eu/privacy/wallet"
}
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["https://example.eu/schema/pid"]
},
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birth_date"] }
]
}
],
"createdAt": "2026-01-01"
}
]
}
]
}
Una banca registrata sia come Relying Party che richiede PID sia come QEAA Provider (che emette attestation di conto bancario al Wallet).
Registra due Service: un Service con intendedUses e un Service con providesAttestations.
{
"legalPerson": {
"legalName": ["ExampleBank S.p.A."]
},
"identifier": [
{
"type": "http://data.europa.eu/eudi/id/EUID",
"identifier": "IT-EUID-123456789"
},
{
"type": "http://data.europa.eu/eudi/id/VATIN",
"identifier": "IT98765432101"
}
],
"postalAddress": [
"Via dei Mille, Roma, IT"
],
"country": "IT",
"email": [
"wallet-rp-registration@examplebank.eu"
],
"phone": [
"+39100000000"
],
"infoURI": [
"https://examplebank.eu"
],
"providerType": "WalletRelyingParty",
"policy": [
{
"type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
"policyURI": "https://examplebank.eu/terms"
},
{
"type": "http://data.europa.eu/eudi/policy/privacy-policy",
"policyURI": "https://examplebank.eu/privacy"
}
],
"tradeName": "ExampleBank",
"isPSB": false,
"supervisoryAuthority": {
"name": "Garante per la protezione dei dati personali",
"country": "IT",
"email": ["contact@supervisor.example.it"],
"formURI": ["https://supervisor.example.it"]
},
"registryURI": "https://registry.example.it/api",
"services": [
{
"serviceTradeName": "ExampleBank Mobile",
"supportURI": "https://examplebank.eu/support",
"srvDescription": [
[
{
"lang": "en",
"content": "Retail banking services for individuals."
},
{
"lang": "it",
"content": "Servizi bancari per privati."
}
]
],
"entitlements": [
"https://uri.etsi.org/19475/Entitlement/Service_Provider"
],
"isIntermediary": false,
"intendedUses": [
{
"intendedUseIdentifier": "iu-account-opening",
"purpose": [
{
"lang": "en",
"content": "Open a bank account remotely."
},
{
"lang": "it",
"content": "Aprire un conto corrente da remoto."
}
],
"privacyPolicy": [
{
"type": "http://data.europa.eu/eudi/policy/privacy-statement",
"policyURI": "https://examplebank.eu/privacy/wallet/account-opening"
}
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": { "vct_values": ["https://example.eu/schema/pid"] },
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birth_date"] },
{ "path": ["nationalities"] }
]
}
],
"createdAt": "2026-01-01"
}
]
},
{
"serviceTradeName": "ExampleBank Account Attestations",
"supportURI": "https://examplebank.eu/support",
"srvDescription": [
[
{
"lang": "en",
"content": "Issuance of qualified bank account attestations."
},
{
"lang": "it",
"content": "Rilascio di attestati qualificati relativi a conti bancari."
}
]
],
"entitlements": [
"https://uri.etsi.org/19475/Entitlement/QEAA_Provider"
],
"isIntermediary": false,
"providesAttestations": [
{
"format": "dc+sd-jwt",
"type": "https://examplebank.eu/schema/bank-account"
}
],
"intendedUses": [
{
"intendedUseIdentifier": "iu-bank-account-attestation-issuance",
"purpose": [
{
"lang": "en",
"content": "Verify wallet holder identity to issue a bank account attestation."
}
],
"privacyPolicy": [
{
"type": "http://data.europa.eu/eudi/policy/privacy-statement",
"policyURI": "https://examplebank.eu/privacy/wallet/attestation-issuance"
}
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": { "vct_values": ["https://example.eu/schema/pid"] },
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birth_date"] }
]
}
],
"createdAt": "2026-01-01"
}
]
}
]
}
Un'entità registrata come Intermediary designato che agisce per conto di WRP durante le interazioni con il Wallet.
Ciascun suo elemento services[] ha isIntermediary: true, non dichiara intendedUses o entitlement, e elenca i Service serviti in servedWRPServices.
{
"legalPerson": {
"legalName": ["TrustBridge Services B.V."]
},
"identifier": [
{
"type": "http://data.europa.eu/eudi/id/EUID",
"identifier": "IT-EUID-112233445"
},
{
"type": "http://data.europa.eu/eudi/id/VATIN",
"identifier": "IT112233445B01"
}
],
"postalAddress": [
"Corso Venezia, Milano, IT"
],
"country": "IT",
"email": ["wallet-intermediary@trustbridge.example"],
"phone": ["+39200000000"],
"infoURI": ["https://trustbridge.example"],
"providerType": "WalletRelyingParty",
"policy": [
{
"type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
"policyURI": "https://trustbridge.example/terms"
},
{
"type": "http://data.europa.eu/eudi/policy/privacy-policy",
"policyURI": "https://trustbridge.example/privacy"
}
],
"tradeName": "TrustBridge",
"isPSB": false,
"supervisoryAuthority": {
"name": "Garante per la protezione dei dati personali",
"country": "IT",
"email": ["contact@supervisor.example.it"],
"formURI": ["https://supervisor.example.it"]
},
"registryURI": "https://registry.example.it/api",
"services": [
{
"serviceTradeName": "TrustBridge Wallet Intermediation",
"supportURI": "https://trustbridge.example/support",
"email": "wallet-intermediary@trustbridge.example",
"phone": "+39200000000",
"srvDescription": [
[
{
"lang": "en",
"content": "Intermediary for wallet-relying parties operating in Italy."
},
{
"lang": "it",
"content": "Intermediario per WRP che operano in Italia."
}
]
],
"isIntermediary": true,
"servedWRPServices": []
}
]
}
5.5.1.2. Register Open APIs¶
I metodi di lettura sono la Sezione 3 di EUDI-TS 5.
Metodi, parametri di filtro, codici di risposta e la riduzione di services quando si usa serviceidentifier sono definiti lì.
Nota
La vista API pubblicata esclude solo postalAddress ([CIR2025/848] come modificato da [CIR2026/1730], Allegato I, punto 4).
Tutti gli altri campi, inclusi i claim di Credenziale dell'uso previsto, sono pubblicati come registrati.
Le Register Open APIs restano per pubblicazione e trasparenza ([EIDAS-ARF] Reg_03, Reg_06).
La Wallet Unit NON DEVE usarle come sostituto di un Wallet-Relying Party Registration Certificate mancante o non valido durante la Presentazione di Credenziali o l'Emissione di Credenziali, come specificato in EUDIW Authorization.
Il file YAML della specifica OpenAPI descritta nella Sezione 3 di EUDI-TS 5 è disponibile come EUDI-TS 5 OpenAPI.
Lo JSON Schema dell'oggetto WalletRelyingParty, incluso l'array services di WalletRelyingPartyService, è disponibile come EUDI-TS 5 JSON Schema.
L'API nazionale del Register fornisce solo i metodi di lettura di EUDI-TS 5 OpenAPI.
5.5.2. Wallet-Relying Party Access Certificate (WRPAC) Profile¶
Questa sezione estende il X.509 Certificate Profile generale e specifica un Certificate Profile per i Wallet-Relying Party Access Certificates (WRPACs).
Il WRPAC è il certificato definito nell'Articolo 2 e nell'Allegato IV di [CIR2025/848]. Il suo profilo è ETSI TS 119 411-8. Le estensioni non specificate da quel documento NON DEVONO essere presenti. Gli attributi del subject sono [EIDAS-ARF] Reg_31, Reg_32 e Reg_34, e ETSI TS 119 411-8. L'autenticazione è specificata in EUDIW Authentication. La revoca in caso di sospensione o cancellazione dei servizi della WRP è specificata in Trust Management and Lifecycle. L'identificatore del Relying Party Service e un WRPAC per Service sono rinviati come specificato in Register of WRPs.
Nota
Gli attributi del WRPAC DEVONO essere derivati dal Register come specificato nella clausola 5.1.2 di ETSI TS 119 475.
Deviazione di profilo. La Certificate Transparency ([EIDAS-ARF] CT_01 a CT_06) non è un requisito di questa specifica finché le Technical Specification dell'ARF non la rendono pienamente disponibile e chiara per le implementazioni. Il profilo del WRPAC non include un Signed Certificate Timestamp, il Provider of WRPAC non è tenuto a registrare i WRPAC emessi, e la Wallet Unit non è tenuta a verificare la Certificate Transparency durante l'Autenticazione.
Di seguito un esempio di WRPAC per persone giuridiche secondo la NCP.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x6F3A0B91D2...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of Relying Party",
commonName: "ExampleBank Mobile", // serviceTradeName (Reg_34)
organizationIdentifier: "LEIXG-5493001KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)"
}
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194118.1.2", // NCP-l-eudiwrp
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://rp.example.test/support"),
GeneralName.rfc822Name("support@rp.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222333"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
critical: false,
value: AuthorityInfoAccess [
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
accessLocation: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.5.3. Registrar Sign/Seal Certificate Profile¶
Questa sezione estende il X.509 Certificate Profile generale e specifica un Certificate Profile per i Registrar Sign/Seal Certificates.
La tabella seguente definisce l'insieme completo di estensioni applicabili al profilo di certificato. Le estensioni non elencate nella tabella NON DEVONO essere presenti.
Extension |
Descrizione |
|---|---|
|
OBBLIGATORIO. Il valore DOVREBBE essere derivato dalla chiave pubblica usando i metodi definiti in RFC 5280#section-4.2.1.1. |
|
OPZIONALE. Se presente, il campo |
|
OBBLIGATORIO. DEVE contenere uno (e uno solo) dei key-usage settings Type A, Type B, o Type F. Type A DOVREBBE essere usato secondo LEG-4.3.1-4 nella Clausola 4.3.1 [ETSI EN 319 412-3]. Per dettagli aggiuntivi, vedi Clausola 4.3.2 [ETSI EN 319 412-2] e Clausola 4.3.1 [ETSI EN 319 412-3]. |
|
OBBLIGATORIO. DEVE includere una struttura |
|
OBBLIGATORIO. |
|
OBBLIGATORIO SE: il certificato non include alcuna access location di un responder OCSP o l'estensione validity assured come definita in ETSI EN 319 412-1. |
|
OBBLIGATORIO. DEVE includere una struttura Se l'OCSP è supportato dalla CA emittente, l'estensione DEVE includere una struttura |
Di seguito un esempio non normativo di Registrar Sign/Seal Certificate per persone giuridiche (non self-signed).
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x6F3A0B91D2...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of PID Provider",
commonName: "PID Provider Example",
organizationIdentifier: "LEIXG-5493001KJAWIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194112.1.3", // qcp-legal-qscd
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://registrar.example.test/support"),
GeneralName.rfc822Name("support@registrar.example.test"),
GeneralName.otherName(
typeId: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222333"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
}
Extension {
oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
critical: false,
value: AuthorityInfoAccess [
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
accessLocation: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // Must match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.5.4. Wallet-Relying Party Registration Certificate (WRPRC) Profile¶
Questa sezione profila il Wallet-Relying Party Registration Certificate (WRPRC) definito in EIDAS-ARF e in ETSI TS 119 475. I suoi contenuti sono la clausola 5.1, la clausola 5.2.4 e l'Allegato A.2 di ETSI TS 119 475, e l'Allegato V paragrafo 3 di [CIR2025/848]. È un JWT firmato o un CWT (RFC 8392), firmato con la chiave privata del Provider of Wallet-Relying Party Registration Certificates. La firma JWT è una firma JAdES con il profilo B-B (ETSI TS 119 182-1). La firma CWT segue RFC 9052 e RFC 9360.
Il Provider of WRPRC emette un solo WRPRC per l'entità, automaticamente, come definito in Wallet-Relying Party Registration Certificate Issuance. Il vincolo di tale certificato a un identificatore di Relying Party Service, e l'emissione di più di un WRPRC per entità, sono rinviati come specificato in Register of WRPs.
L'oggetto intermediary è la clausola 5.2.4 di ETSI TS 119 475 e [EIDAS-ARF] RPRC_04.
La Wallet Unit valuta la presentazione intermediata come specificato in EUDIW Authorization.
Di seguito un esempio non normativo di header e payload WRPRC per una Relying Party.
{
"typ": "rc-wrp+jwt",
"alg": "ES256",
"x5c": ["<base64-encoded-certificate-chain>"]
}
{
"name": "Online Shop",
"sub_ln": "Online Shop",
"sub": "LEIXG-529900T8BM49AURSDO55",
"country": "IT",
"registry_uri": "https://wrp-register.it/api/v1/relying-parties/IT-WRP-00789",
"srv_description": [
{ "lang": "it", "value": "Servizio di shopping online" },
{ "lang": "en", "value": "Online shopping platform" }
],
"entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
"purpose": [
{ "lang": "it", "value": "Verifica dell'età per i prodotti soggetti a restrizioni di età" },
{ "lang": "en", "value": "Age verification for age-restricted products" }
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": { "vct_values": ["https://credentials.example.eu/pid"] },
"claim": [{ "path": ["age_over_18"] }]
}
],
"privacy_policy": "https://shop.example.it/privacy",
"info_uri": "https://shop.example.it",
"support_uri": "https://shop.example.it/support",
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"public_body": false,
"policy_id": ["0.4.0.19475.3.1"],
"certificate_policy": "https://wrp-register.it/policies/service-provider",
"iat": 1704067200,
"exp": 1735689600,
"status": { "status_list": { "idx": 156, "uri": "https://status.wrp-register.it/statuslist/1" } }
}
Di seguito un esempio non normativo di payload WRPRC per una Relying Party intermediata.
{
"name": "Small Business Verification",
"sub_ln": "Small Business S.p.A.",
"sub": "IT123456789",
"country": "IT",
"entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": { "vct_values": ["https://credentials.example.eu/pid"] },
"claim": [{ "path": ["age_over_18"] }]
}
],
"intermediary": {
"sub": {
"id": "LEIXG-529900INTERMEDIARY01",
"sname": "Verification Service"
}
},
"policy_id": ["0.4.0.19475.3.1"],
"iat": 1704067200,
"status": { "status_list": { "idx": 567, "uri": "https://status.wrp-register.it/statuslist/2" } }
}
Avvertimento
ETSI TS 119 475, Tabella 10 definisce il subfield del nome dell'intermediario come sname.
L'esempio nell'Allegato C dello stesso standard usa invece name.
Questa specifica segue la Tabella 10 normativa e usa sname.
5.5.5. Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities¶
Questa sezione descrive il formato e i contenuti di tre tipi di Trust Artifact, ciascuno dei quali convoglia un elenco di Trust Anchor correnti e storici (contenitori di materiali crittografici e identificatori appartenenti a Entità fidate).
Le Entità dell'ecosistema utilizzano queste list per:
Validare l'affidabilità a runtime: Verificare un Trust Anchor (vedi Trust Anchor Certificate Profile) per autenticare, autorizzare o validare un'entità o un artifact durante le operazioni live.
Eseguire la validazione storica: Validare le informazioni contenute nella list per scopi di audit storico.
La tabella seguente mappa ciascuna list alla sua base giuridica, allo standard di governo, al formato e alla pubblicazione.
Lo schema XML delle Trusted List e della List of Trusted Lists è pubblicato all'indirizzo https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.4.1/19612_xsd.xsd.
La List of Trusted Lists machine-readable e le Trusted List nazionali sono pubblicate in EUMS-LOTL.
Gli schemi JSON e XML normativi delle List of Trusted Entities sono pubblicati in ETSI-LOTE-SCHEMAS.
List Type |
Base giuridica |
Standard di governo e Formato |
Signature Profile |
Scope e Firmatario |
Meccanismo di pubblicazione e aggiornamento |
|---|---|---|---|---|---|
Trusted Lists (TL) |
CID2015/1505 (Allegato I, Capitolo II), modificato da CID2025/2164. |
ETSI TS 119 612; formato |
Firma digitale XAdES, baseline B (ETSI EN 319 132-1). |
Scope di Stato membro; una list per Stato membro, firmata da tale Stato membro. |
Endpoint machine-readable specificato all'interno della LOTL. |
List of Trusted Lists (LOTL) |
CID2015/1505 (Allegato I, Capitolo II), modificato da CID2025/2164. |
ETSI TS 119 612; formato |
Firma digitale XAdES, baseline B (ETSI EN 319 132-1). |
Scope dell'Unione europea; una singola list globale firmata dalla Commissione europea (CE) che ancora le National Trusted List. |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
LoTE: PID Provider Lists |
Articoli 4 e 5 di CIR2024/2980. |
ETSI TS 119 602 Allegato D; formato |
Firma digitale AdES, baseline B (ETSI TS 119 182-1). |
Scope dell'Unione europea; una list per tipo specifico di entità dell'ecosistema. |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
LoTE: Wallet Provider (WP) Lists |
Articoli 4 e 5 di CIR2024/2980. |
ETSI TS 119 602 Allegato E; formato |
Firma digitale AdES, baseline B (ETSI TS 119 182-1). |
Scope dell'Unione europea; una list per tipo specifico di entità dell'ecosistema. |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
LoTE: Provider of WRPAC Lists |
Articoli 4 e 5 di CIR2024/2980. |
ETSI TS 119 602 Allegato F; formato |
Firma digitale AdES, baseline B (ETSI TS 119 182-1). |
Scope dell'Unione europea; una list per tipo specifico di entità dell'ecosistema (Wallet Relying Party Access Certificate). |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
LoTE: Provider of WRPRC Lists |
Articoli 4 e 5 di CIR2024/2980. |
ETSI TS 119 602 Allegato G; formato |
Firma digitale AdES, baseline B (ETSI TS 119 182-1). |
Scope dell'Unione europea; una list per tipo specifico di entità dell'ecosistema (Wallet Relying Party Registration Certificate). |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
LoTE: PuB-EAA Provider Lists |
Articoli 4 e 5 di CIR2024/2980. |
ETSI TS 119 602 Allegato H; formato |
Firma digitale AdES, baseline B (ETSI TS 119 182-1). |
Scope dell'Unione europea; le list notificano i PuB-EAA Provider e i loro Sign/Seal Trust Anchor. |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
LoTE: Registrar and Register Provider Lists |
Articoli 4 e 5 di CIR2024/2980. |
ETSI TS 119 602 Allegato I; formato |
Firma digitale AdES, baseline B (ETSI TS 119 182-1). |
Scope dell'Unione europea; una list per tipo specifico di entità dell'ecosistema. |
Endpoint machine-readable specificato all'interno della OJEU. Implementa un pivoting mechanism per gestire gli aggiornamenti continui. |
Nota
Come suggerito in EIDAS-ARF, per efficienza, le implementazioni POSSONO controllare periodicamente i Trust Anchor nelle List of Trusted Entities o nelle Trusted List e memorizzarli localmente. Questo consente, per esempio, alle Relying Party Instance in esecuzione su app mobili di facilitare le presentazioni offline.
L'esempio seguente mostra un esempio non normativo di payload di una List of Trusted Entities per PID Provider.
{
"ListAndSchemeInformation": {
"LoTEVersionIdentifier": 1,
"LoTESequenceNumber": 1,
"LoTEType": "http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList",
"SchemeOperatorName": [
{
"lang": "it",
"value": "Agenzia per l'Italia Digitale"
},
{
"lang": "en",
"value": "Agency for Digital Italy"
}
],
"SchemeOperatorAddress": {
"SchemeOperatorPostalAddress": [
{
"lang": "it",
"StreetAddress": "Via Liszt 21",
"Locality": "Roma",
"StateOrProvince": "RM",
"PostalCode": "00144",
"Country": "IT"
}
],
"SchemeOperatorElectronicAddress": [
{
"lang": "it",
"uriValue": "mailto:protocollo@pec.agid.gov.it"
}
]
},
"SchemeName": [
{
"lang": "it",
"value": "Elenco di Fiducia Italiano dei Fornitori di PID"
},
{
"lang": "en",
"value": "Italian Trusted List of PID Providers"
}
],
"SchemeInformationURI": [
{
"lang": "it",
"uriValue": "https://www.agid.gov.it/it/piattaforme/eidas-wallet/pid-providers-list"
},
{
"lang": "it",
"uriValue": "https://www.agid.gov.it/it/piattaforme/eidas-wallet/pid-providers-list/history"
}
],
"StatusDeterminationApproach": "http://uri.etsi.org/19602/PIDProvidersList/StatusDetn/EU",
"SchemeTypeCommunityRules": [
{
"lang": "en",
"uriValue": "http://uri.etsi.org/19602/PIDProvidersList/schemerules/EU"
}
],
"SchemeTerritory": "EU",
"PolicyOrLegalNotice": [
{
"LoTEPolicy": {
"lang": "en",
"uriValue": "https://www.agid.gov.it/legal-notice"
}
}
],
"PointersToOtherLoTE": [
{
"LoTELocation": "https://www.agid.gov.it/lote/pid-providers.json",
"ServiceDigitalIdentities": [
{
"X509SubjectNames": [
"CN=Italian Wallet LoTE Signer, O=AgID, C=IT"
]
}
],
"LoTEQualifiers": [
{
"LoTEType": "http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList",
"SchemeOperatorName": [
{
"lang": "it",
"value": "Agenzia per l'Italia Digitale"
}
],
"SchemeTypeCommunityRules": [
{
"lang": "en",
"uriValue": "http://uri.etsi.org/19602/PIDProvidersList/schemerules/EU"
}
],
"SchemeTerritory": "EU",
"MimeType": "application/json"
}
]
}
],
"ListIssueDateTime": "2026-06-27T12:00:00Z",
"NextUpdate": "2026-12-27T12:00:00Z",
"DistributionPoints": [
"https://www.agid.gov.it/lote/pid-providers.json"
],
"SchemeExtensions": [
{
"extensionMetadata": "exampleValue"
}
]
},
"TrustedEntitiesList": [
{
"TrustedEntityInformation": {
"TEName": [
{
"lang": "it",
"value": "Fornitore Nazionale di Identità Digitale S.p.A."
},
{
"lang": "en",
"value": "National Digital Identity Provider S.p.A."
}
],
"TETradeName": [
{
"lang": "it",
"value": "NTRIT-12345678901"
}
],
"TEAddress": {
"TEPostalAddress": [
{
"lang": "it",
"StreetAddress": "Corso Vittorio Emanuele II, 101",
"Locality": "Torino",
"StateOrProvince": "TO",
"PostalCode": "10121",
"Country": "IT"
}
],
"TEElectronicAddress": [
{
"lang": "it",
"uriValue": "mailto:compliance@fornitorepid.it"
},
{
"lang": "it",
"uriValue": "tel:+39011555555"
}
]
},
"TEInformationURI": [
{
"lang": "it",
"uriValue": "https://www.fornitorepid.it/policies"
},
{
"lang": "it",
"uriValue": "https://www.fornitorepid.it/info"
},
{
"lang": "en",
"uriValue": "http://uri.etsi.org/19602/ListOfTrustedEntities/PIDProvider/IT"
}
],
"TEInformationExtensions": [
{
"providerStatus": "fully-compliant"
}
]
},
"TrustedEntityServices": [
{
"ServiceInformation": {
"ServiceName": [
{
"lang": "it",
"value": "Servizio di Rilascio e Gestione del Person Identification Data (PID)"
},
{
"lang": "en",
"value": "Person Identification Data (PID) Issuance and Management Service"
}
],
"ServiceDigitalIdentity": {
"X509Certificates": [
{
"encoding": "http://uri.etsi.org/19602/pkiOb/der",
"specRef": "RFC 5280",
"val": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0y...[BASE64_CERTIFICATE_DATA]..."
}
],
"X509SubjectNames": [
"CN=National PID Provider Issuing CA, O=National Digital Identity Provider S.p.A., C=IT"
]
},
"ServiceTypeIdentifier": "http://uri.etsi.org/19602/SvcType/PID/Issuance",
"SchemeServiceDefinitionURI": [
{
"lang": "en",
"uriValue": "https://www.agid.gov.it/schemes/pid-service-definition"
}
],
"ServiceSupplyPoints": [
{
"ServiceType": "http://uri.etsi.org/19602/SupplyPoint/API",
"uriValue": "https://api.fornitorepid.it/v1/pid"
}
],
"ServiceDefinitionURI": [
{
"lang": "it",
"uriValue": "https://www.fornitorepid.it/pid-service-documentation"
}
],
"ServiceInformationExtensions": [
{
"supportedAlgorithms": [
"ES256",
"Ed25519"
]
}
]
}
}
]
}
]
}
5.5.6. Embedded Disclosure Policy (EDP)¶
Un'Embedded Disclosure Policy (EDP) è definita nell'Articolo 2(9) di [CIR2024/2979]. Applicabilità e i tre tipi comuni di policy sono l'Articolo 10 e l'Allegato III di [CIR2024/2979], codificati nella Sezione 4.2.5.2 di ETSI TS 119 472-3 (ISS-MDATA-EBD-4.2.5.2-06, ISS-MDATA-EBD-4.2.5.2-07, ISS-MDATA-EBD-4.2.5.2-08 e ISS-MDATA-EBD-4.2.5.2-09). Un'EDP NON DEVE essere applicata a un PID. La Wallet Unit valuta i tipi comuni come specificato in EUDIW Authorization. La non divulgazione verso la Relying Party è la Sezione 4.2.5.1 di ETSI TS 119 472-3.
L'Attestation Provider DEVE includere l'EDP, se presente, come membro embedded_disclosure_policy di credential_metadata all'interno di credential_configurations_supported, in conformità con OpenID4VCI o l'estensione di esso specificata in ETSI TS 119 472-3.
Il membro DEVE contenere un policy_uri.
Il membro PUÒ contenere i dati completi della policy in policy_data.
La Wallet Unit PUÒ ricevere solo policy_uri quando la policy esatta identificata da tale URI è già precaricata.
Altrimenti l'URI e i dati della policy DEVONO essere forniti insieme.
Un URI non risolto DEVE far fallire l'associazione e la divulgazione interessata.
La Wallet Unit NON DEVE recuperare il contenuto della policy da policy_uri.
Nota
L'HLR EDP_02 di EIDAS-ARF richiede una coppia di identificatori presa dal WRPRC nella richiesta (sub e un identificatore di Service), non dal WRPAC, anche in una presentazione diretta.
L'identificatore di Service è rinviato come specificato in Register of WRPs.
Fino ad allora, la Wallet Unit confronta l'identificatore univoco a livello UE (sub) e, ove presente, l'URI di entitlement.
ETSI TS 119 472-3 (ISS-MDATA-EBD-4.2.5.2-07) codifica inoltre le parti autorizzate per subject DN o per URI di entitlement.
Il parametro subject_dn è quella codifica ETSI. Il parametro subject_dn non è un input di valutazione rispetto al WRPAC.
Il parametro entitlement_uri è abbinato rispetto alle entitlement detenute nel WRPRC.
L'Allegato A.3 di ETSI TS 119 475 definisce sub-entitlement per i Service Provider, attualmente per i Payment Service Provider (ad es. https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai).
Per una presentazione intermediata il WRPRC nella richiesta è quello della Relying Party intermediata ([EIDAS-ARF] RPRC_19).
5.5.6.1. Embedded Disclosure Policy Data Model¶
La tabella seguente fornisce una panoramica completa del modello dati dell'Embedded Disclosure Policy, inclusi i nomi dei parametri, i tipi di dati, le descrizioni e le clausole specifiche in ETSI TS 119 472-3 in cui ciascun parametro è definito.
Avvertimento
I nomi dei parametri sono definiti in questa sezione e non si basano su una specifica ETSI normativa. La Sezione 4.2.5.2 di ETSI TS 119 472-3 definisce i requisiti di alto livello per il modello dati, ma lo schema JSON finale sarà pubblicato separatamente da ETSI. La struttura definita qui è un profilo di implementazione basato sui requisiti del modello dati ETSI, e i nomi dei parametri POSSONO cambiare quando lo schema ETSI è pubblicato.
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. string (URI). Identificatore univoco dell'Embedded Disclosure Policy (EDP). L'associazione dell'EDP con una EAA DEVE essere stabilita includendo questo URI univoco. La risoluzione dell'URI, inclusa la proibizione di recuperare il contenuto della policy da esso, è specificata sopra in Embedded Disclosure Policy (EDP). |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-01, ISS-MDATA-EBD-4.2.5.2-02, ISS-MDATA-EBD-4.2.5.2-03) |
|
OBBLIGATORIO. string. Classificazione del tipo di policy. Valori validi:
|
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-06, ISS-MDATA-EBD-4.2.5.2-07, ISS-MDATA-EBD-4.2.5.2-08) |
|
OPZIONALE. string. Descrizione dell'applicabilità della policy a una particolare comunità e/o classe di applicazione che condivide requisiti di sicurezza comuni. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-04) |
|
OPZIONALE. string. Identificatore dell'autorità o dell'entità responsabile della policy. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-05) |
|
OPZIONALE. string (URL). Collegamento a un sito web dell'Attestation Provider (AP) che spiega le linee guida della disclosure policy in termini comprensibili. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-13, EDP_05) |
|
OBBLIGATORIO. array of objects. se |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) |
|
OBBLIGATORIO. string.
Identificatore univoco a livello UE della Relying Party autorizzata, come specificato in [EIDAS-ARF] Reg_32.
DEVE corrispondere al |
[EIDAS-ARF] EDP_02 |
|
OPZIONALE. string. Subject Distinguished Name (DN) della Relying Party, formattato come stringa LDAP conforme a RFC 4514. Questa è la codifica ETSI di ISS-MDATA-EBD-4.2.5.2-07. Non è un input di valutazione: la Wallet Unit NON DEVE abbinarlo rispetto al WRPAC, e la valutazione EDP_02 usa l'identificatore univoco a livello UE dal WRPRC, come specificato in EUDIW Authorization. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) |
|
OPZIONALE. string (URI). Entitlement o sub-entitlement codificata come URI come specificato nell'Allegato A di [ETSI TS 119 475], detenuta all'interno del Wallet-Relying Party Registration Certificate (WRPRC). Tale URI DEVE essere confrontato in modo esatto. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) |
|
OBBLIGATORIO. array of objects. se |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-08) |
|
OBBLIGATORIO. string. Issuer Distinguished Name (DN) in forma di stringa LDAP conforme a RFC 4514. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-09) |
|
OBBLIGATORIO. string. Serial number del certificato corrispondente all'issuer definito. |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-09) |
|
OPZIONALE. array of objects. Contenitore per strutture di estensione EDP supplementari. Queste strutture POSSONO essere ignorate dalla Wallet Unit.
La Wallet Unit DEVE elaborare con successo le regole riconosciute anche se sono presenti estensioni non riconosciute.
L'estensione IT-Wallet è un oggetto con un identificatore di estensione, un claim |
Clausola 4.2.5.2 di [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-10, ISS-MDATA-EBD-4.2.5.2-11, ISS-MDATA-EBD-4.2.5.2-12) |
Di seguito esempi non normativi di EDP con i tipi di policy Authorized Relying Parties Only e Specific Root of Trust.
{
"policy_uri": "https://example-ap.eu/policies/edp/v1/medical-records-access",
"policy_type": "authorized_rp_only",
"description": "Access is strictly restricted to authorized healthcare institutions and designated medical service providers.",
"policy_authority": "National Health and e-ID Authority",
"policy_info_url": "https://example-ap.eu/policies/edp/medical-laymans.html",
"authorized_parties": [
{
"subject_dn": "CN=Central University Hospital Pharmacy,O=Central Hospital Group,ORGID=VATES-12345678,C=FI"
},
{
"entitlement_uri": "https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai"
}
],
"extensions": [
{
"id": "it-wallet-attribute-rule",
"path": ["medical_record_number"],
"rule": {
"policy_type": "authorized_rp_only",
"authorized_parties": [
{
"entitlement_uri": "https://uri.etsi.org/19475/SubEntitlement/healthcare/clinical"
}
]
}
}
]
}
{
"policy_uri": "https://example-ap.eu/policies/edp/v1/financial-sector-trust",
"policy_type": "specific_root_of_trust",
"description": "Access is restricted to Relying Parties whose WRPAC path contains an approved banking oversight root or intermediate certificate.",
"policy_authority": "European Banking Coordination Committee",
"policy_info_url": "https://example-ap.eu/policies/edp/finance-roots-laymans.html",
"trusted_roots": [
{
"issuer_dn": "CN=EU Financial Sector WRPAC Root CA G3,O=European Banking Authority,C=BE",
"serial_number": "550e8400e29b41d4a716446655440000"
},
{
"issuer_dn": "CN=National WRPAC Intermediate CA,O=Ministry of Finance,C=DE",
"serial_number": "109384729384729384"
}
]
}
5.5.6.2. Embedded Disclosure Policy Lifecycle¶
L'EDP memorizzata localmente DEVE restare valida finché l'Attestation a cui è associata è valida e non revocata. L'EDP NON DEVE avere uno status di validità indipendente o un meccanismo di revoca separato dall'Attestation.
Se un Attestation Provider aggiunge, modifica o cancella un'EDP per un Attestato Elettronico che emette, l'Attestation Provider DEVE revocare tale Attestato Elettronico. La Wallet Unit rileva il cambiamento di EDP indirettamente attraverso il normale meccanismo di controllo dello status dell'Attestation (Status List), che riporterà l'Attestato Elettronico come revocato. L'EDP memorizzata localmente è quindi implicitamente invalidata insieme all'Attestato Elettronico. L'Utente deve richiedere una nuova emissione per ottenere l'Attestato Elettronico con l'EDP aggiornata.
Anche una modifica minore della policy (ad es., l'aggiunta di una singola RP all'elenco autorizzato) richiede la revoca e la riemissione. Il momento del rilevamento dipende da quando la Wallet Unit controlla lo status dell'Attestato Elettronico: se la Wallet Unit controlla solo al momento della presentazione, un cambiamento di policy non sarà rilevato fino al successivo tentativo di presentazione.
Avvertimento
Proactive refresh.
Questa specifica non usa il refresh proattivo di un'Embedded Disclosure Policy.
La proibizione di recuperare il contenuto della policy da policy_uri, e la revoca dell'Attestato Elettronico quando un'EDP cambia, sono specificate sopra in questa sezione.
Il refresh proattivo è escluso perché consentirebbe a un Attestation Provider di modificare unilateralmente un'EDP, con le conseguenze di privacy e di gestione descritte nel Discussion Topic D, e perché i suoi dettagli tecnici non sono definiti nello standard ETSI.
5.6. National Trust Artifacts¶
Questa sezione definisce il Trust Framework Nazionale basato su OpenID Federation (OID-FED) combinato con una PKI X.509 dedicata alla firma degli Attestati Elettronici che richiede X.509. Il profilo X.509 è dettagliato in Common Trust Artifacts, mentre le sezioni seguenti definiscono i Trust Artifact richiesti e i loro ruoli concettuali definiti nelle seguenti specifiche della famiglia OpenID Federation, ciascuna nel proprio scope:
OpenID Federation 1.0 (OID-FED), il framework core. Definisce gli artifact principali inclusi gli Entity Statement, gli endpoint di federazione e i Trust Mark.
OpenID Federation for Wallet Architectures (OID-FED-WALLET) il profilo di implementazione Wallet per OpenID Federation 1.0. Definisce gli Entity Type Identifier delle Entità usate in questa sezione.
OpenID Federation Subordinate Events (OID-FED-SUBORDINATE-EVENTS), che definisce l'endpoint Subordinate Events, usato per ottenere lo storico di registrazione di un Immediate Subordinate.
La figura OID-FED Roles mappa ciascuna entità dell'ecosistema wallet sul ruolo OpenID Federation che svolge. Le Wallet-Relying Party e i Wallet Provider sono Federation Entity che DEVONO essere registrate da una Federation Authority, cioè un Federation TA o Intermediate.
Fig. 5.2 OID-FED Roles¶
Nota
Le Wallet Unit non sono Federation Entity, sono i dispositivi personali dell'End-User autenticati dal loro Wallet Provider.
5.6.1. Federation API Endpoints¶
OpenID Federation 1.0 usa servizi web RESTful protetti su HTTPS.
Tutte le Federation Entity DEVONO pubblicare la propria Entity Configuration all'endpoint .well-known/openid-federation secondo OID-FED Sezione 9.
Il Federation TA e gli Intermediate espongono inoltre gli endpoint di federazione usati per costruire e validare le Trust Chain e per supportare i Trust Mark.
Le proprietà della Federation Entity supportate nel profilo delle specifiche IT-Wallet sono definite in OID-FED Sezione 5.1.1. La tabella seguente elenca gli endpoint di federazione e gli Entity Type che DEVONO esporre ciascuno di essi. Per ciascun endpoint la tabella indica i parametri di richiesta usati all'interno di IT-Wallet e se ciascun parametro è richiesto. La tabella indica anche la risposta restituita da ciascun endpoint. I parametri di richiesta seguono OID-FED Sezione 8: sono inviati come query parameter per le richieste GET e nel body per le richieste POST. Le risposte seguono i formati di risposta OID-FED referenziati nella tabella.
Endpoint |
Parametri di richiesta |
Risposta |
|---|---|---|
fetch ( |
GET.
|
Il Subordinate Statement richiesto, come JWT firmato ( |
list ( |
GET.
|
Un array JSON degli Entity Identifier degli Immediate Subordinate ( |
resolve ( |
GET.
|
La Resolve Response con i Resolved Metadata, la Trust Chain e i Trust Mark verificati, come JWT firmato ( |
trust mark status ( |
POST.
|
La Trust Mark Status Response, cioè la validità del Trust Mark, come JWT firmato ( |
trust mark list ( |
GET.
|
Un array JSON degli Entity Identifier per i quali il Trust Mark è emesso e ancora valido ( |
trust mark ( |
GET.
|
Il Trust Mark richiesto, come JWT firmato ( |
historical keys ( |
GET. Nessun parametro di richiesta. |
Un JWK Set firmato con le chiavi storiche, come JWT firmato ( |
subordinate events ( |
GET.
|
Un JWT firmato con lo storico degli eventi di registrazione. Vedi la specifica Subordinate Events Sezione 2.3. |
L'endpoint Subordinate Events (/subordinate_events) è definito in OID-FED-SUBORDINATE-EVENTS.
Il suo scopo è fornire una traccia storica verificabile degli eventi di registrazione concernenti un Immediate Subordinate, come la sua registrazione, l'aggiornamento delle sue Federation Entity Keys e la sua revoca.
Per il formato della richiesta, il formato della risposta e i tipi di evento si fa riferimento alle Sezioni 2.2 e 2.3 di [OID-FED-SUBORDINATE-EVENTS].
Nota
All'interno di IT-Wallet l'endpoint resolve (/resolve) DEVE rispondere alle richieste non autenticate solo con informazioni in cache sulle Entità, se disponibili, e la raccolta e la valutazione di una Trust Chain NON DEVE essere l'azione predefinita dell'endpoint resolve, come descritto in OID-FED Sezione 18.1.
5.6.2. Entity Statements¶
Un Entity Statement è un JWT firmato emesso da un'entità (se stessa o un superiore) per condividere i metadata di federazione. Contiene le chiavi, le policy e i dettagli di configurazione richiesti affinché l'entità subject partecipi alla federazione.
L'Entity Configuration è l'Entity Statement che ciascuna Federation Entity emette su se stessa e pubblica al path .well-known/openid-federation (OID-FED Sezione 3).
I suoi iss e sub sono il Federation Entity Identifier dell'Entità stessa, ed è firmata con una Federation Entity Key.
La risposta HTTP imposta il media type a application/entity-statement+jwt.
L'Entity Configuration PUÒ anche contenere uno o più Trust Mark.
Un Subordinate Statement è l'Entity Statement che un Trust Anchor o un Federation Intermediate emette sul proprio Immediate Subordinate (OID-FED Sezione 3).
Il suo iss è l'issuer, il suo sub è il Subordinate, e reca le Federation Entity Keys del Subordinate, quindi è la dichiarazione che vincola le chiavi del Subordinate sotto il suo superiore.
PUÒ anche recare una metadata policy e i Trust Mark relativi al Subordinate.
5.6.2.1. Entity Configuration¶
Nell'ecosistema IT-Wallet l'Entity Configuration è pubblicata durante l'onboarding dell'Entità (vedi Onboarding Processes) ed è recuperata e validata durante la trust evaluation, come definito in Federation Entity Authentication e Metadata Retrieval and Validation.
I dettagli tecnici sull'Entity Configuration di Wallet Provider, Credential Issuer e Relying Party sono forniti nella Sezione Entity Configuration del Fornitore di Wallet, Entity Configuration del Fornitore di Attestati Elettronici e Entity Configuration Relying Party rispettivamente.
Nota
Tutti i controlli di firma sulle Entity Configuration, sui Subordinate Statement e sui Trust Mark sono eseguiti con le Federation Entity Keys. Per gli algoritmi supportati si fa riferimento alla Sezione Algoritmi Crittografici.
5.6.2.2. Subordinate Statements¶
I Trust Anchor e i Federation Intermediate servono i propri Subordinate Statement attraverso l'endpoint fetch (/fetch) (OID-FED Sezione 8.1), dove un Trust Evaluator li recupera per validare la firma dell'Entity Configuration del Subordinate e per costruire la Trust Chain.
La metadata policy, quando presente, modifica i metadata finali della Foglia.
I metadata finali sono derivati dall'intera Trust Chain, dall'Entity Configuration fino al Subordinate Statement emesso dal Trust Anchor, come definito in Metadata Retrieval and Validation.
La revoca di un Subordinate è espressa dall'assenza di un Subordinate Statement valido a esso relativo, come definito in Federation Trust Chain.
All'interno di IT-Wallet i Subordinate Statement sono emessi durante l'onboarding del Subordinate (vedi Onboarding Processes).
5.6.2.3. Entity Statement Parameters¶
In aggiunta ai parametri comuni OBBLIGATORIO iss, sub, iat, exp e jwks come definiti in OID-FED Sezione 3.1.1, all'interno del profilo delle specifiche IT-Wallet si applicano i seguenti parametri.
Nell'Entity Configuration (OID-FED Sezione 3.1.2):
metadata (
metadata): Oggetto JSON OBBLIGATORIO in cui ciascuna chiave è un identificatore di tipo di metadata e il suo valore è il metadata di tale tipo (vedi OID-FED Sezione 3.1.1). Tutte le Entità DEVONO includere almeno un metadata perfederation_entitynelle proprie Entity Configuration. Un'Entità PUÒ includere più di una dichiarazione di metadata, con una sola dichiarazione per ciascun tipo di metadata. I tipi di metadata sono definiti in Entity Type Identifiers and Metadata.trust_marks (
trust_marks): OBBLIGATORIO per Foglie e Federation Intermediate. Array JSON dei Trust Mark del subject. Il Trust Mark di registrazione è definito in Trust Mark registration-entity.trust_mark_issuers (
trust_mark_issuers): OBBLIGATORIO per il Federation TA. Oggetto JSON che dichiara, per ciascun tipo di Trust Mark, le Federation Authority fidate a emetterlo, indicate dai loro Federation Entity Identifier. All'interno di IT-Wallet il Trust Mark di registrazione è emesso solo dal Federation Trust Anchor, quindi l'Entity Configuration del Federation TA DEVE contenere almeno l'identificatore del Federation TA.
Nel Subordinate Statement (OID-FED Sezione 3.1.3):
metadata_policy (
metadata_policy): OPZIONALE in OID-FED. Metadata policy vincolata a un tipo di metadata specifico e applicata al sottoalbero, risolta combinando i Claimmetadata_policylungo la Trust Chain, come definito in OID-FED Sezione 6.1.4. All'interno di IT-Wallet il Subordinate Statement relativo a una Foglia DEVE recare unametadata_policyche vincola i metadata di protocollo della Foglia ai valori approvati in onboarding. Il Subordinate Statement DEVE fissare l'organization_namedei metadatafederation_entitye le chiavi di firma di protocollo (jwks). Il Subordinate Statement usa gli operatori di metadata policy di OID-FED Sezione 6.1.3. Quando tali parametri sono presenti nel tipo di metadata, il Subordinate Statement DEVE fissare anche gli endpoint di servizio e gli URI di request, response e redirect. Esempi sono irequest_uris,response_uriseredirect_urisdiopenid_credential_verifier. Questo Subordinate Statement è emesso dal superiore immediato che ha registrato la Foglia, cioè il Federation TA per le Foglie che registra direttamente e un Federation Intermediate per le sue Relying Party affiliate. Il Subordinate Statement relativo a un Federation Intermediate non reca unametadata_policy, perché l'Intermediate non ha metadata di protocollo e le sue Relying Party affiliate sono vincolate dall'Intermediate stesso. Un superiore PUÒ restringere ulteriormente la metadata policy impostata dai propri superiori. Un superiore NON DEVE allentare quella metadata policy, come definito in OID-FED Sezione 6.1.1.constraints (
constraints): OBBLIGATORIO solo per Federation TA. Reca i vincoli applicati al sottoalbero al di sotto dell'issuer. DEVE contenereallowed_entity_types, che restringe i metadata Entity Type che i Subordinate nel sottoalbero sono autorizzati a pubblicare, emax_path_length, che limita il numero di Intermediate tra l'issuer e il subject della Trust Chain. L'Entity Typefederation_entityè sempre consentito e NON DEVE essere elencato inallowed_entity_types. Vedi OID-FED Sezione 6.2.
Tutti gli altri parametri opzionali definiti in OID-FED Sezione 3 che non sono riconosciuti all'interno del profilo delle specifiche IT-Wallet DEVONO essere ignorati durante la valutazione di un Entity Statement.
Nota
All'interno di IT-Wallet le Federation Entity Keys recate nel jwks di un'Entity Configuration o di un Subordinate Statement sono usate per firmare le dichiarazioni di federazione e sono validate attraverso la Federation Trust Chain, non attraverso X.509.
La PKI di firma X.509, i cui certificati sono usati per firmare le Attestation, è una relazione di fiducia separata.
I Signing Trust Anchor di questa PKI sono distribuiti nell'Entity Configuration del Federation Trust Anchor.
Ciascuno è fornito nel parametro x5c (RFC 7517 Sezione 4.7) di una JWK dedicata all'interno del jwks, distinta dalle Federation Entity Keys, che non recano x5c, come definito in Signing Trust Anchor Distribution.
I certificati Document Signer dei Credential Issuer non sono recati nel jwks degli Entity Statement: sono inclusi nelle Attestation firmate, nell'header x5chain per il formato mdoc e nell'header x5c per il formato JOSE, e sono validati come definito in X.509 Certificate Chain Validation.
L'emissione di questi Certificati X.509 e l'operazione della PKI di firma sono definite nell'onboarding (vedi Onboarding Processes).
5.6.2.4. Entity Type Identifiers and Metadata¶
Gli Entity Type Identifier dei ruoli dell'ecosistema sono definiti in OpenID Federation for Wallet Architectures, sezione Wallet Architecture Entity Types, che è il profilo wallet di OpenID Federation. Ciascun ruolo dichiara nella propria Entity Configuration uno o più tipi di metadata, i cui parametri seguono la specifica di protocollo di tale tipo di metadata. La tabella seguente mappa i ruoli dell'ecosistema sui loro Entity Type Identifier e fornisce il riferimento del protocollo di metadata per ciascuno di essi.
Il tipo di metadata del Wallet Provider DEVE essere openid_wallet_provider, l'Entity Type Identifier definito da OpenID Federation for Wallet Architectures (OID-FED-WALLET).
Entità |
Metadata Type |
|---|---|
Trust Anchor |
|
Wallet Provider |
|
Credential Issuer |
|
Relying Party |
|
Relying Party Intermediary |
|
Nota
Un Relying Party Intermediary è un Federation Intermediate.
In qualità di intermediario non è coinvolto nei flussi di protocollo, quindi non pubblica un metadata di protocollo proprio, solo i metadata federation_entity.
Pubblica i Subordinate Statement delle sue Relying Party affiliate, e ciascuna Relying Party affiliata imposta i propri authority_hints sull'Intermediary.
Il suo Trust Mark di registrazione usa l'Entity Type Identifier intermediate nel tipo di Trust Mark, come definito in Trust Mark Types and Schema.
Nota
Quando un PID o EAA Provider implementa sia il Credential Issuer sia l'Authorization Server all'interno della stessa Entità, DEVE includere sia openid_credential_issuer sia oauth_authorization_server nei suoi tipi di metadata.
Quando l'Authorization Server è un'Entità separata, i metadata del Credential Issuer DEVONO contenere il parametro authorization_servers con l'identificatore dell'Authorization Server.
Secondo OPENID4VCI l'Authorization Server PUÒ essere esterno all'Entità che implementa il Credential Endpoint, pertanto l'uso di oauth_authorization_server è OPZIONALE.
Inoltre, qualora sia necessaria l'Autenticazione dell'Utente da parte del Credential Issuer, potrebbe essere necessario includere il tipo di metadata rilevante openid_credential_verifier.
I metadata federation_entity recano i parametri informativi seguenti insieme ai parametri degli endpoint di federazione.
I parametri degli endpoint di federazione (federation_fetch_endpoint, federation_list_endpoint, federation_resolve_endpoint e gli altri) sono pubblicati solo dal Federation TA e dagli Intermediate, secondo i loro obblighi definiti nella sezione Federation API Endpoints sopra, e una Foglia non li espone.
I parametri informativi seguenti sono OPZIONALE in OID-FED. Il profilo delle specifiche IT-Wallet supporta i claim nella tabella seguente.
Claim |
Descrizione |
|---|---|
organization_name |
OBBLIGATORIO. Vedi OID-FED Sezione 5.2.2 |
organization_uri |
OBBLIGATORIO. URL della pagina web dell'organizzazione che possiede l'entità. Vedi OID-FED Sezione 5.2.2 |
policy_uri |
OBBLIGATORIO. Vedi OID-FED Sezione 5.2.2 |
logo_uri |
OBBLIGATORIO. URL del logo dell'entità, in formato SVG. Vedi OID-FED Sezione 5.2.2 |
contacts |
OBBLIGATORIO. All'interno di IT-Wallet è l'indirizzo email verificato istituzionale (PEC) dell'entità. Vedi OID-FED Sezione 5.2.2 |
tos_uri |
OPZIONALE. URL dei termini di servizio dell'entità. Vedi OID-FED Sezione 5.2.2 |
I metadata relativi a Wallet Provider, Credential Issuer e Relying Party sono forniti nella Sezione Metadati della Soluzione Wallet, Metadata del Fornitore di Attestati Elettronici e Metadati della Relying Party rispettivamente.
5.6.3. Entity Statement Examples¶
Le sezioni seguenti forniscono esempi non normativi di Entity Statement, sia per l'onboarding diretto sotto il Federation TA sia per l'onboarding intermediato sotto un Federation Intermediate.
Tutte le dichiarazioni sono JWT firmati con l'header JOSE alg, kid e typ impostato a entity-statement+jwt, e sono mostrati solo i payload.
I metadata di protocollo e i key set della copia locale nota sono troncati ({ ... }) poiché la loro definizione completa è fornita nelle sezioni di metadata referenziate sopra.
5.6.3.1. Entity Configuration of a Federation TA¶
Il Federation TA è la root della Trust Chain.
La sua Entity Configuration non ha authority_hints, e il suo jwks fornisce, in aggiunta alle Federation Entity Keys, i Signing Trust Anchor della PKI di firma X.509 e gli Authentication Trust Anchor della PKI di autenticazione X.509, come JWK dedicate con x5c.
Un Signing Trust Anchor è la root della PKI che emette i certificati Document Signer. Un Authentication Trust Anchor è la root della PKI che emette i certificati di autenticazione della Relying Party usati per l'mdoc reader authentication nel Proximity Flow.
Ciascuna tale JWK è identificata dal suo kid e dalle proprietà del certificato fornito nel suo x5c.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://trust-anchor.eid-wallet.example.it",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "yRnq6oEvrxcZ1zYStADzTLX-qSw3Pb7E6mqJGNqnygA",
"x": "xrk5H1nEWrNYRb7FBamuSRHHf-XWjv1k-uZCSVCSAnc",
"y": "FM5YI7GvkTB8xxTiMTTSycDL0nguRowbibgfyqKjB0k"
},
{
"kty": "EC",
"crv": "P-256",
"use": "sig",
"kid": "signing-trust-anchor-01",
"x": "B0sj_kZRT4A-oP9Y57dinEiDFTG-tjuPu7MiiQHHQ_g",
"y": "iMDCuatE53HiX2VTDJ_q7LbQ-A7fgjXZpJsW-eZzge0",
"x5c": [
"<Signing Trust Anchor X.509 certificate>"
]
},
{
"kty": "EC",
"crv": "P-256",
"use": "sig",
"kid": "authentication-trust-anchor-01",
"x": "Zm3kQp9rB1xYtA5nF2wEsRHHf-XWjv1k-uZCSVCSAn8",
"y": "Km9ZI7GvkTB8xxTiMTTSycDL0nguRowbibgfyqKjB2m",
"x5c": [
"<Authentication Trust Anchor X.509 certificate>"
]
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "IT-Wallet Federation Trust Anchor",
"organization_uri": "https://trust-anchor.eid-wallet.example.it",
"policy_uri": "https://trust-anchor.eid-wallet.example.it/policy",
"logo_uri": "https://trust-anchor.eid-wallet.example.it/logo.svg",
"contacts": [
"trust-anchor@pec.example.it"
],
"federation_fetch_endpoint": "https://trust-anchor.eid-wallet.example.it/fetch",
"federation_list_endpoint": "https://trust-anchor.eid-wallet.example.it/list",
"federation_resolve_endpoint": "https://trust-anchor.eid-wallet.example.it/resolve",
"federation_trust_mark_status_endpoint": "https://trust-anchor.eid-wallet.example.it/trust_mark_status",
"federation_trust_mark_list_endpoint": "https://trust-anchor.eid-wallet.example.it/trust_marked_list",
"federation_trust_mark_endpoint": "https://trust-anchor.eid-wallet.example.it/trust_mark",
"federation_historical_keys_endpoint": "https://trust-anchor.eid-wallet.example.it/historical_keys",
"federation_subordinate_events_endpoint": "https://trust-anchor.eid-wallet.example.it/subordinate_events"
}
},
"trust_mark_issuers": {
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_wallet_provider": [
"https://trust-anchor.eid-wallet.example.it"
],
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_issuer": [
"https://trust-anchor.eid-wallet.example.it"
],
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_verifier": [
"https://trust-anchor.eid-wallet.example.it"
],
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/intermediate": [
"https://trust-anchor.eid-wallet.example.it"
]
}
}
5.6.3.2. Subordinate Statement of Leaf issued by the Federation TA¶
Il Federation TA emette un Subordinate Statement su ciascuna Foglia che registra direttamente.
La dichiarazione reca le Federation Entity Keys della Foglia, la metadata_policy che fissa le chiavi di protocollo e, quando presenti, gli endpoint di servizio e gli URI della Foglia ai valori approvati in onboarding, e i constraints del sottoalbero.
L'esempio non normativo seguente è il Subordinate Statement che il Federation TA emette su una Foglia Wallet Provider.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://wallet-provider.example.it",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "LqZSJoAEybT9V3jUQfZYUjVV-U5jV34sgbhIsIXltSY",
"x": "38k73K5mw7Ev34lMwJhMBy5L2PnP9ayGfnMMtk4UZAw",
"y": "4ohTh7joeKLhRfPRSXQvnu-OMqUIn9lzoJAp_ztuv1A"
}
]
},
"metadata_policy": {
"openid_wallet_provider": {
"jwks": {
"value": { "... the Wallet Provider protocol keys registered at onboarding ..." }
}
}
},
"constraints": {
"allowed_entity_types": [
"openid_wallet_provider"
],
"max_path_length": 0
}
}
L'esempio non normativo seguente è il Subordinate Statement che il Federation TA emette su una Foglia Relying Party.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://access.privatecompany.example.com",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "cwdtstHkIOqwWD8UeXjY_NdKfB-d1bzIx7XKBQNVbsg",
"x": "y8ahuTA-G4oLpTFYp7YrTd99kLPSlNoLPmwGJcXvWY8",
"y": "HNRLc-1ennbeBtF3LbtBdq_0c7EX4samlHnwXilH_i0"
}
]
},
"metadata_policy": {
"openid_credential_verifier": {
"jwks": {
"value": { "... the Relying Party protocol keys registered at onboarding ..." }
},
"request_uris": {
"value": [
"https://access.privatecompany.example.com/openid4vp/request"
]
},
"response_uris": {
"value": [
"https://access.privatecompany.example.com/openid4vp/response"
]
},
"redirect_uris": {
"value": [
"https://access.privatecompany.example.com/openid4vp/callback"
]
}
}
},
"constraints": {
"allowed_entity_types": [
"openid_credential_verifier"
],
"max_path_length": 0
}
}
L'esempio non normativo seguente è il Subordinate Statement che il Federation TA emette su una Foglia Credential Issuer.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://badge-issuer.example.it",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "r6KG1Jbgcv0iNW1y0ERO_X2Jw926V2UHRJH8d-GcDEI",
"x": "26w7G_Myczl2-S8n0m1lMIjo3IzgZky-yNVdwaKOmhQ",
"y": "2WMnoyCXqS4FUdv9e4JEAJKyhRIODi5xGfFdnA6cnVM"
}
]
},
"metadata_policy": {
"openid_credential_issuer": {
"jwks": {
"value": { "... the Credential Issuer protocol keys registered at onboarding ..." }
},
"credential_endpoint": {
"value": "https://badge-issuer.example.it/credential"
}
}
},
"constraints": {
"allowed_entity_types": [
"openid_credential_issuer",
"oauth_authorization_server"
],
"max_path_length": 0
}
}
5.6.3.3. Subordinate Statement of an Intermediate¶
Il Federation TA emette un Subordinate Statement sul Federation Intermediate.
I constraints restringono il sottoalbero dell'Intermediate alle Relying Party che può intermediare, e max_path_length è impostato a 1 per consentire il singolo livello di intermediazione tra il Federation TA e le Relying Party affiliate.
Non reca metadata_policy: le Relying Party affiliate sono vincolate dall'Intermediate nei Subordinate Statement che emette su di esse.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://intermediary.example.com",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "EycKTxHbR_s_aZB46j_1ObHG3n2QEQ0sU0-gRGdBWv0",
"x": "4sAmMPyNl21DjQ_i6C4y0erHz3IVsVETYpH4kOoKFb8",
"y": "B5nPVnBVBss55KGCJG8_EyT72PJKU8n_k8SMZdPUIaE"
}
]
},
"constraints": {
"allowed_entity_types": [
"openid_credential_verifier"
],
"max_path_length": 1
}
}
5.6.3.4. Subordinate Statement about a Leaf issued by a Federation Intermediate¶
Il Federation Intermediate emette un Subordinate Statement su ciascuna Relying Party affiliata.
Reca la metadata_policy che vincola i metadata di protocollo della Relying Party affiliata ai valori approvati in onboarding, esattamente come fa il Federation TA per le Foglie che registra direttamente.
I constraints del sottoalbero sono impostati dal Federation TA nella dichiarazione relativa all'Intermediate.
Nel Trust Framework Nazionale un Intermediary intermedia solo Relying Party.
{
"iss": "https://intermediary.example.com",
"sub": "https://rp.affiliated.example.com",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "n47zfejmk3V14aKUQCEcA7sTKi-SXMw7E1MFnpQCL-0",
"x": "H3_bMVOWJoDSBenUzelAbAj4vanmXNJ3KT2Vk_OaehI",
"y": "aMoXkKSssBtMHwSCR-hY8mmFQFs3Hf5iQ0zFWMHAQfc"
}
]
},
"metadata_policy": {
"openid_credential_verifier": {
"jwks": {
"value": { "... the affiliated Relying Party protocol keys registered at onboarding ..." }
},
"request_uris": {
"value": [
"https://rp.affiliated.example.com/openid4vp/request"
]
},
"response_uris": {
"value": [
"https://rp.affiliated.example.com/openid4vp/response"
]
},
"redirect_uris": {
"value": [
"https://rp.affiliated.example.com/openid4vp/callback"
]
}
}
}
}
5.6.3.5. Entity Configuration of a Federation Intermediate¶
Il Federation Intermediate è solo una federation_entity.
La sua Entity Configuration punta al Federation TA attraverso authority_hints e reca il suo Trust Mark di registrazione con l'Entity Type Identifier intermediate.
Espone gli endpoint fetch e list usati per servire i Subordinate Statement delle sue Relying Party affiliate.
{
"iss": "https://intermediary.example.com",
"sub": "https://intermediary.example.com",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "EycKTxHbR_s_aZB46j_1ObHG3n2QEQ0sU0-gRGdBWv0",
"x": "4sAmMPyNl21DjQ_i6C4y0erHz3IVsVETYpH4kOoKFb8",
"y": "B5nPVnBVBss55KGCJG8_EyT72PJKU8n_k8SMZdPUIaE"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Intermediary S.r.l.",
"organization_uri": "https://intermediary.example.com",
"policy_uri": "https://intermediary.example.com/policy",
"logo_uri": "https://intermediary.example.com/logo.svg",
"contacts": [
"intermediary@pec.example.com"
],
"federation_fetch_endpoint": "https://intermediary.example.com/fetch",
"federation_list_endpoint": "https://intermediary.example.com/list"
}
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/intermediate",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
5.6.3.6. Entity Configuration of a Leaf¶
Ciascuna Foglia pubblica la propria Entity Configuration, puntando al proprio superiore immediato attraverso authority_hints e recando il proprio Trust Mark di registrazione.
Gli esempi seguenti riportano i claim principali. I metadata di protocollo sono referenziati alla relativa sezione di metadata.
L'esempio non normativo seguente è l'Entity Configuration di una Foglia Wallet Provider.
{
"iss": "https://wallet-provider.example.it",
"sub": "https://wallet-provider.example.it",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "LqZSJoAEybT9V3jUQfZYUjVV-U5jV34sgbhIsIXltSY",
"x": "38k73K5mw7Ev34lMwJhMBy5L2PnP9ayGfnMMtk4UZAw",
"y": "4ohTh7joeKLhRfPRSXQvnu-OMqUIn9lzoJAp_ztuv1A"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Example Wallet Provider",
"organization_uri": "https://wallet-provider.example.it",
"policy_uri": "https://wallet-provider.example.it/policy",
"logo_uri": "https://wallet-provider.example.it/logo.svg",
"contacts": [
"wallet-provider@pec.example.it"
]
},
"openid_wallet_provider": { ".. as defined in the Wallet Solution Metadata section ..." }
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_wallet_provider",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
L'esempio non normativo seguente è l'Entity Configuration di una Foglia Relying Party.
{
"iss": "https://access.privatecompany.example.com",
"sub": "https://access.privatecompany.example.com",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "cwdtstHkIOqwWD8UeXjY_NdKfB-d1bzIx7XKBQNVbsg",
"x": "y8ahuTA-G4oLpTFYp7YrTd99kLPSlNoLPmwGJcXvWY8",
"y": "HNRLc-1ennbeBtF3LbtBdq_0c7EX4samlHnwXilH_i0"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Private Company S.p.A.",
"organization_uri": "https://access.privatecompany.example.com",
"policy_uri": "https://access.privatecompany.example.com/policy",
"logo_uri": "https://access.privatecompany.example.com/logo.svg",
"contacts": [
"compliance@pec.privatecompany.example.com"
]
},
"openid_credential_verifier": { "... as defined in the Relying Party Metadata section ..." }
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_verifier",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
L'esempio non normativo seguente è l'Entity Configuration di una Foglia Credential Issuer.
{
"iss": "https://badge-issuer.example.it",
"sub": "https://badge-issuer.example.it",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "r6KG1Jbgcv0iNW1y0ERO_X2Jw926V2UHRJH8d-GcDEI",
"x": "26w7G_Myczl2-S8n0m1lMIjo3IzgZky-yNVdwaKOmhQ",
"y": "2WMnoyCXqS4FUdv9e4JEAJKyhRIODi5xGfFdnA6cnVM"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Comune di Example",
"organization_uri": "https://badge-issuer.example.it",
"policy_uri": "https://badge-issuer.example.it/policy",
"logo_uri": "https://badge-issuer.example.it/logo.svg",
"contacts": [
"protocollo@pec.comune.example.it"
]
},
"openid_credential_issuer": { "... as defined in the Credential Issuer Metadata section ..." }
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_issuer",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
5.6.4. Trust Marks¶
A seguito del completamento con successo dell'onboarding, le entità ricevono i Trust Mark della Federazione IT-Wallet. I Trust Mark sono emessi dalla Federation Authority attraverso il Federation Trust Mark Endpoint. Per l'onboarding diretto l'issuer è il Trust Anchor. Per l'onboarding mediato l'issuer è l'Intermediate. Un Trust Mark attesta la conformità ai profili tecnici IT-Wallet, alle policy di autorizzazione, o a entrambi.
5.6.4.1. Trust Mark Types and Schema¶
Gli identificatori dei Trust Mark DEVONO seguire uno schema gerarchico che riflette lo scope di autorizzazione:
https://<federation_authority_domain>/trust_marks/<purpose>/<entity_type>
Dove:
<federation_authority_domain>: Il dominio della Federation Authority emittente.
<purpose>: Lo scopo del Trust Mark. Lo scoporegistration-entityè OBBLIGATORIO per tutte le entità a seguito del processo di onboarding. Scopi aggiuntivi di Trust Mark POSSONO essere definiti per esigenze future, ma non sono richiesti per i processi di autorizzazione definiti in Authorization.
<entity_type>: L'Entity Type Identifier del subject, tra quelli definiti in Entity Type Identifiers and Metadata (per esempioopenid_credential_issueroopenid_credential_verifier), eintermediateper un Relying Party Intermediary.
Nota
Il Federation TA nazionale è l'issuer di Trust Mark riconosciuto all'interno della federazione.
Scopi aggiuntivi di Trust Mark, quando definiti, POSSONO quindi essere emessi da altre Entità autorizzate attraverso trust_mark_issuers.
5.6.4.2. Trust Mark registration-entity¶
All'interno di IT-Wallet il Trust Mark registration-entity è il Trust Mark di registrazione di un'entità.
L'unico issuer di Trust Mark per il Trust Mark di registrazione DEVE essere il Federation TA.
Attesta la registrazione e reca i dati di autorizzazione dell'entità, cioè le sue entitlement e, ove applicabile, le Credenziali e gli attributi che è autorizzata a emettere o a richiedere.
Questo Trust Mark di registrazione è l'analogo funzionale del Wallet-Relying Party Registration Certificate (WRPRC) del Trust Framework EUDIW.
Un'entità riceve un Trust Mark di registrazione per ciascun ruolo che detiene, con il componente <entity_type> dell'identificatore impostato di conseguenza.
Un Relying Party Intermediary riceve il proprio Trust Mark di registrazione con l'<entity_type> intermediate nell'identificatore.
Nel Trust Framework EUDIW la relazione di intermediario è espressa nei dati di registrazione della Relying Party intermediata.
Nel Trust Framework Nazionale, invece, è espressa attraverso la gerarchia di federazione: l'Intermediary è un Federation Intermediate che pubblica i Subordinate Statement delle sue Relying Party affiliate, e ciascuna Relying Party affiliata imposta i propri authority_hints sull'Intermediary.
Il Trust Mark di registrazione di ciascuna Relying Party affiliata è altresì emesso dal Federation Trust Anchor.
Per questo motivo nessun campo dedicato all'intermediario è presente nel Trust Mark.
L'onboarding dell'Intermediary è definito in Relying Party Intermediary.
5.6.4.2.1. Trust Mark Types and Schema: Trust Mark Structure¶
I Trust Mark nell'Entity Configuration DEVONO essere rappresentati come oggetti JSON contenenti i seguenti claim:
Claim |
Descrizione |
|---|---|
trust_mark_type |
OBBLIGATORIO.
Identificatore per il tipo di Trust Mark che segue lo schema: |
trust_mark |
OBBLIGATORIO. Un JSON Web Token firmato che rappresenta il Trust Mark emesso dalla Federation Authority. |
Il Trust Mark JWT (contenuto nel claim trust_mark sopra) DEVE essere un JWT firmato che include sia un header JOSE sia un payload, come definito in OID-FED Sezione 7.
5.6.4.2.2. Trust Mark Types and Schema: Trust Mark JWT Header¶
L'header JOSE del Trust Mark JWT DEVE includere i seguenti parametri:
Parameter |
Descrizione |
|---|---|
alg |
OBBLIGATORIO. L'algoritmo crittografico usato per firmare il Trust Mark JWT. DEVE essere uno degli algoritmi supportati per le Federation Entity Keys (vedi Algoritmi Crittografici). |
kid |
OBBLIGATORIO. Key ID della Federation Entity Key usata per firmare il Trust Mark, come definito in OID-FED Sezione 7. |
typ |
OBBLIGATORIO.
Media type del Trust Mark JWT.
DEVE essere impostato a |
Un esempio non normativo di un header JWT di Trust Mark:
{
"alg": "ES256",
"kid": "ta-federation-key-1",
"typ": "trust-mark+jwt"
}
5.6.4.2.3. Trust Mark Types and Schema: Trust Mark JWT Payload¶
Il payload del Trust Mark JWT include i seguenti claim:
Claim |
Descrizione |
|---|---|
iss |
OBBLIGATORIO. Il Federation Trust Anchor che emette il Trust Mark. |
sub |
OBBLIGATORIO. Federation Entity Identifier del subject. |
trust_mark_type |
OBBLIGATORIO.
Identificatore univoco del Trust Mark.
DEVE corrispondere al claim |
iat |
OBBLIGATORIO. Timestamp di emissione del Trust Mark. |
exp |
OBBLIGATORIO. Timestamp di scadenza del Trust Mark. |
public_body |
OBBLIGATORIO. Booleano che indica se l'entità è un organismo del settore pubblico. |
vat_number |
OBBLIGATORIO quando |
legal_identifier |
RACCOMANDATO. Numero o identificatore di registrazione legale dell'entità (ad es., numero di registrazione dell'impresa, codice fiscale). |
ipa_code |
OBBLIGATORIO quando |
organization_name |
OBBLIGATORIO. Denominazione completa dell'Entità Organizzativa. |
OBBLIGATORIO. Email istituzionale o PEC dell'organizzazione. |
|
support_uri |
OBBLIGATORIO. Contatto di supporto dell'entità. Una richiesta di cancellazione dei dati usa questo valore, come specificato in EUDI-TS 7, per la cancellazione dei dati personali precedentemente forniti tramite l'Istanza del Wallet. Il valore DEVE essere un URL HTTPS, un indirizzo email o un numero di telefono. |
srv_description |
OBBLIGATORIO.
Descrizione multilingue del servizio fornito dall'entità.
Ciascuna entry contiene |
entitlements |
OBBLIGATORIO.
Array di URI di entitlement che identificano il ruolo del subject, come definito in ETSI TS 119 475 Allegato A.2 (ad es. |
provides_attestations |
OBBLIGATORIO per un Credential Issuer, NON DEVE essere presente altrimenti.
Array dei tipi di Credenziale che il subject è autorizzato a emettere.
Ciascuna entry contiene |
credentials |
OBBLIGATORIO per una Relying Party che richiede Credenziali, NON DEVE essere presente altrimenti.
Array delle query di Credenziale che il subject è autorizzato a richiedere, usato per l'Overasking Check.
Ciascuna entry contiene |
purpose |
OBBLIGATORIO per una Relying Party che richiede Credenziali, NON DEVE essere presente altrimenti.
Elenco multilingue che descrive il trattamento dei dati associato all'uso previsto.
Ciascuna entry contiene |
privacy_policy |
OBBLIGATORIO per una Relying Party che richiede Credenziali, NON DEVE essere presente altrimenti. URL della privacy policy del subject. |
supervisory_authority |
OBBLIGATORIO.
Informazioni sull'Autorità di protezione dei dati, con |
logo_uri |
OBBLIGATORIO. URL che punta al Trust Mark per scopi UI/UX. |
ref |
OPZIONALE. URL con informazioni web aggiuntive sul Trust Mark. |
Nota
I claim che recano i dati di autorizzazione (entitlements, provides_attestations, credentials, purpose, privacy_policy, supervisory_authority) e i claim di identità e trasparenza allineati al WRPRC (public_body, support_uri, srv_description) sono definiti in analogia con il Wallet-Relying Party Registration Certificate EUDIW (ETSI TS 119 475), in modo che un Trust Evaluator possa riutilizzare la stessa logica di autorizzazione per entrambi gli artifact.
Nota
Lo status di revoca di un Trust Mark è verificato attraverso l'endpoint trust mark status (/trust_mark_status) (OID-FED Sezione 8.4), non attraverso una status list recata nel token.
Questa è la differenza rispetto al WRPRC, il cui claim status punta a una status list: il Trust Mark si affida al meccanismo di revoca nativo della federazione.
Il consumo di questi claim da parte del Trust Evaluator è definito in Authorization.
Gli esempi non normativi seguenti illustrano il contenuto del Trust Mark JWT di registrazione per un Credential Issuer, un EAA Provider pubblico non qualificato che emette un Employee Badge, per una Relying Party che richiede tale Employee Badge, e per un Relying Party Intermediary.
Credential Issuer, un EAA Provider pubblico non qualificato che emette l'Employee Badge:
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://badge-issuer.example.it",
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_issuer",
"iat": 1718207217,
"exp": 1749743216,
"public_body": true,
"ipa_code": "c_h501",
"legal_identifier": "80012345678",
"organization_name": "Comune di Example",
"email": "protocollo@comune.example.it",
"support_uri": "https://badge-issuer.example.it/support",
"srv_description": [
{"lang": "it", "value": "Servizio di emissione del badge dipendente"},
{"lang": "en", "value": "Employee Badge issuance service"}
],
"entitlements": ["Non_Q_EAA_Provider"],
"provides_attestations": [
{
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:it-wallet:badge:1"]
},
"claim": [
{"path": ["document_number"]},
{"path": ["works_for"]},
{"path": ["given_name"]},
{"path": ["family_name"]},
{"path": ["job_title"]}
]
}
],
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"logo_uri": "https://badge-issuer.example.it/logo.svg"
}
Relying Party, un'organizzazione privata che richiede l'Employee Badge per il controllo degli accessi fisici:
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://access.privatecompany.example.com",
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_verifier",
"iat": 1718207217,
"exp": 1749743216,
"public_body": false,
"vat_number": "IT12345678901",
"legal_identifier": "12345678901",
"organization_name": "Private Company S.p.A.",
"email": "compliance@privatecompany.example.com",
"support_uri": "https://access.privatecompany.example.com/support",
"srv_description": [
{"lang": "it", "value": "Servizio di controllo dell'accesso fisico"},
{"lang": "en", "value": "Physical access control service"}
],
"entitlements": ["Service_Provider"],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:it-wallet:badge:1"]
},
"claim": [
{"path": ["given_name"]},
{"path": ["family_name"]},
{"path": ["works_for"]},
{"path": ["job_title"]}
]
}
],
"purpose": [
{"lang": "en", "value": "Employee verification for physical access control"},
{"lang": "it", "value": "Verifica del dipendente per il controllo dell'accesso fisico"}
],
"privacy_policy": "https://access.privatecompany.example.com/privacy",
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"logo_uri": "https://access.privatecompany.example.com/logo.svg"
}
Relying Party Intermediary.
Non dichiara un uso previsto proprio, quindi il suo Trust Mark di registrazione non reca credentials né purpose.
È un Federation Intermediate, e le sue Relying Party affiliate impostano i propri authority_hints su di esso.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://intermediary.example.com",
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/intermediate",
"iat": 1718207217,
"exp": 1749743216,
"public_body": false,
"vat_number": "IT98765432109",
"legal_identifier": "98765432109",
"organization_name": "Intermediary S.r.l.",
"email": "info@intermediary.example.com",
"support_uri": "https://intermediary.example.com/support",
"srv_description": [
{"lang": "it", "value": "Servizio di intermediazione per Relying Party"},
{"lang": "en", "value": "Intermediation service for Relying Parties"}
],
"entitlements": ["Service_Provider"],
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"logo_uri": "https://intermediary.example.com/logo.svg"
}
5.7. Trust Management and Lifecycle¶
Questa sezione descrive il ciclo di vita dei Trust Artifact (Trust Artifacts Lifecycle State Machine) e i meccanismi usati per gestirne lo status (Revocation Mechanisms). Il ciclo di vita delle Entità, gli eventi che modificano la loro registrazione e gli effetti che tali eventi producono sui Trust Artifact sono descritti in Lifecycle Management.
5.7.1. Trust Artifacts Lifecycle State Machine¶
Le State Machine per i Trust Artifact sono descritte di seguito:
Per WRPAC, WRPRC e Sign/Seal Certificate, gli stati del ciclo di vita sono
VALIDeREVOKED. La transizione daVALIDaREVOKEDè innescata dalla revoca del Trust Artifact, che può essere avviata dal corrispondente Trust Artifact provider per varie ragioni quali compromissione di chiave, cambiamenti organizzativi, o non conformità alle policy del framework. Una volta che un Trust Artifact è nello statoREVOKED, quel Trust Artifact NON DEVE essere considerato fidato per qualsiasi uso operativo all'interno dell'ecosistema. Qualsiasi Entità che fa affidamento su quel Trust Artifact DEVE rifiutarlo per autenticazione, autorizzazione o qualsiasi altra operazione relativa alla fiducia.Un WRPAC nello stato
VALIDNON DEVE essere presente nella CRL designata. In alternativa, un WRPAC nello statoVALIDDEVE restituire uno statusgoodnella risposta OCSP. Un WRPAC nello statoREVOKEDDEVE essere presente nella CRL designata. In alternativa, un WRPAC nello statoREVOKEDDEVE restituire uno statusrevokednella risposta OCSP.Un WRPRC nello stato
VALIDDEVE restituire uno status0x00nel corrispondente Status List Token. Un WRPRC nello statoREVOKEDDEVE avere valore di status0x01all'interno del corrispondente Status List Token.
Per le Trust List (LoTE, LOTL, EUMS TL), gli stati del ciclo di vita sono
CURRENTeHISTORICAL. La transizione daCURRENTaHISTORICALè innescata dalla pubblicazione di una nuova versione della Trust List che sostituisce la versione precedente. Una volta che una Trust List è nello statoHISTORICAL, NON DEVE essere usata per qualsiasi uso operativo all'interno dell'ecosistema. Si applicano due eccezioni: la validazione dell'affidabilità della Trust List tramite il pivoting mechanism, e la validazione di operazioni storiche tramite il componenteServiceHistorydella Trust List.Trust Mark: gli status di un Trust Mark sono
ACTIVE,EXPIRED,REVOKED. Lo status può essere controllato usando l'endpoint Trust Mark Status (vedi Sezione 8.4 di OID-FED).
Nota
Register, Entity Configuration e Subordinate Statement sono semplicemente pubblicati o non pubblicati. Durante la loro pubblicazione possono essere aggiornati.
Il diagramma Fig. 5.3 evidenzia la state machine dei Trust Artifact sopra menzionati:
Fig. 5.3 Trust Artifacts States.¶
5.7.2. Federation Entity Key Rotation¶
La Federation Entity Key di un'Entità è attestata dal Subordinate Statement che il suo superiore immediato pubblica su di essa, e l'Entity Configuration dell'Entità DEVE essere firmata con una chiave che il Subordinate Statement attesta. Una nuova Federation Entity Key diventa fidata solo quando il superiore la attesta nel Subordinate Statement.
La rotazione della Federation Entity Key DEVE essere eseguita come definito nei passi seguenti.
L'Entità aggiunge la nuova chiave al
jwksdella propria Entity Configuration. L'Entità DEVE continuare a firmare l'Entity Configuration con la chiave precedente, che è ancora attestata.Nel processo di Entity Update (vedi Entity Update) il superiore DEVE leggere il
jwksdall'Entity Configuration. Il superiore DEVE verificare che l'Entity Configuration sia firmata con una chiave attestata. Il superiore DEVE riemettere il Subordinate Statement attestando la nuova chiave.La chiave precedente e la nuova chiave coesistono fino a quando le Trust Chain costruite con il Subordinate Statement precedente sono scadute. Durante la coesistenza l'Entità continua a firmare con la chiave precedente, in modo che sia il Subordinate Statement precedente sia quello nuovo validino la sua Entity Configuration.
Una volta che la finestra di validità della Trust Chain è scaduta, l'Entità PUÒ firmare la propria Entity Configuration con la nuova chiave.
Quando l'Entità vuole rimuovere la chiave precedente, l'Entità PUÒ rimuoverla dal
jwkse notificare questo cambiamento al superiore attraverso il processo di Entity Update (vedi Entity Update). Il superiore DEVE rimuovere quella chiave dal Subordinate Statement.Il superiore DEVE registrare l'evento come un
jwks_updatepubblicato sul Federation Subordinate Events Endpoint.
5.7.3. Revocation Mechanisms¶
Questa sezione descrive gli artifact impiegati in Trust Artifacts Lifecycle State Machine per gestire lo status di certificati ed entità, dettagliando i rispettivi formati e parametri. La distinzione principale è la seguente:
Per gestire i Wallet-Relying Party Access Certificate e i Sign/Seal Certificate, le entità che agiscono come Trust Anchor per questi certificati DEVONO:
rendere disponibile almeno un meccanismo di revoca tra Certificate Revocation List (CRL) e Online Certificate Status Protocol (OCSP).
emettere WRPAC e Sign/Seal Certificate con almeno un'estensione corrispondente al meccanismo di revoca fornito.
Per gestire i Wallet-Relying Party Registration Certificate, ciascun Provider of Wallet Relying Party Registration Certificates DEVE:
rendere disponibile un endpoint per richiedere Token Status List (WRPRC Profile).
emettere WRPRC con il parametro appropriato
statuscome descritto in Wallet-Relying Party Registration Certificate (WRPRC) Profile.
Nota
ETSI EN 319 411-1 raccomanda il supporto di OCSP, vedi clausola CSS-6.3.10-06 e Nota 2.
5.7.3.1. Certificate Revocation List (CRL)¶
Le Certificate Revocation Lists (CRLs) sono usate per controllare lo status di revoca di un certificato X509. Una CRL è un elenco firmato digitalmente di certificati revocati che sono stati emessi da una CA. La CRL è pubblicata e resa disponibile a qualsiasi entità tramite un URI accessibile pubblicamente. La CRL DEVE essere firmata digitalmente dal CRL issuer.
Le CRL POSSONO essere usate per i seguenti tipi di certificati:
Wallet Relying Party Access Certificate includendo l'estensione
cRLDistributionPointsnel certificato, come descritto in Wallet-Relying Party Access Certificate (WRPAC) Profile.Sign/Seal Certificate includendo l'estensione
cRLDistributionPointsnel certificato, come descritto in Entity Sign/Seal Certificate Profile.
Se una CRL è usata per gestire lo status dei certificati, il CRL issuer DEVE essere l'entità referenziata nel campo subject del certificato Trust Anchor.
Il CRL issuer PUÒ anche generare delta CRL. Una delta CRL elenca solo quei certificati, all'interno del proprio scope, il cui status di revoca è cambiato dall'emissione di una CRL completa referenziata. La CRL completa referenziata è indicata come base CRL. Lo scope di una delta CRL DEVE essere lo stesso della base CRL che referenzia.
Se supportata dalla CA, la CRL DEVE essere disponibile all'URI specificato nella struttura cRLDistributionPoints.distributionPoint [0] CHOICE all'interno del Wallet Relying Party Access Certificate (WRPAC).
Una CRL X.509 v2 è rappresentata come la codifica ASN.1 DER della SEQUENCE CertificateList.
La codifica ASN.1 DER è un sistema di encoding tag, length e value strettamente definito per ciascun elemento.
I byte finali trasmessi rappresentano la codifica DER della SEQUENCE di livello superiore contenente i campi nella tabella seguente:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. SEQUENCE. Contiene le informazioni core della CRL inclusi il nome dell'issuer, la data di emissione, la data del prossimo aggiornamento, l'elenco opzionale dei certificati revocati, e le estensioni CRL opzionali. |
RFC 5280, clausola 5.1.1.1 |
|
OBBLIGATORIO. SEQUENCE. Contiene l'identificatore di algoritmo per l'algoritmo usato dal CRL issuer per firmare la |
RFC 5280, clausola 5.1.1.2 |
|
OBBLIGATORIO. OBJECT IDENTIFIER. L'OID dell'algoritmo di firma. |
[RFC 5280, clausola 4.1.1.2] |
|
OPZIONALE. ANY. Parametri specifici dell'algoritmo, dipendenti dall'algoritmo di firma usato. |
[RFC 5280, clausola 4.1.1.2] |
|
OBBLIGATORIO. BIT STRING. Contiene la firma digitale calcolata sulla |
[RFC 5280, clausola 5.1.1.3] |
5.7.3.1.1. Certificate List Content¶
La tbsCertList (To Be Signed Certificate List) è una SEQUENCE ASN.1 contenente diversi campi ed estensioni.
La tabella seguente elenca tutti tali campi ed estensioni che sono richiesti in una CRL o condizionalmente richiesti.
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OPZIONALE. INTEGER. Descrive la versione della CRL codificata.
Quando sono usate le estensioni (come è prassi standard), questo campo DEVE essere presente e DEVE specificare la versione 2 (il valore intero è |
[RFC 5280, clausola 5.1.2.1] |
|
OBBLIGATORIO. SEQUENCE. L'identificatore di algoritmo per l'algoritmo usato per firmare la CRL. |
[RFC 5280, clausola 5.1.2.2] |
|
OBBLIGATORIO. OBJECT IDENTIFIER. L'OID dell'algoritmo di firma.
DEVE corrispondere al campo |
[RFC 5280, clausola 4.1.1.2] |
|
OPZIONALE. ANY. Parametri specifici dell'algoritmo, dipendenti dall'algoritmo usato. |
[RFC 5280, clausola 4.1.1.2] |
|
OBBLIGATORIO. Name. Identifica l'entità che ha firmato ed emesso la CRL.
DEVE contenere un distinguished name (DN) X.500 non vuoto composto da sequence |
[RFC 5280, clausola 5.1.2.3] |
|
OBBLIGATORIO. UTCTime o GeneralizedTime. Indica la data di emissione di questa CRL.
Le date fino al 2049 DEVONO usare |
[RFC 5280, clausola 5.1.2.4] |
|
OBBLIGATORIO. UTCTime o GeneralizedTime. Indica la data entro cui sarà emessa la successiva CRL.
Le date fino al 2049 DEVONO usare |
[RFC 5280, clausola 5.1.2.5] |
|
OPZIONALE. SEQUENCE OF. Una sequence di certificati revocati. Quando non vi sono certificati revocati, questo campo DEVE essere assente. |
[RFC 5280, clausola 5.1.2.6] |
|
OBBLIGATORIO. INTEGER. Il |
[RFC 5280, clausola 5.1.2.6] |
|
OBBLIGATORIO. UTCTime o GeneralizedTime. La data in cui è avvenuta la revoca. |
[RFC 5280, clausola 5.1.2.6] |
|
OPZIONALE. SEQUENCE OF. Estensioni specifiche per questa entry di certificato revocato.
Se presente, la |
[RFC 5280, clausola 5.1.2.6] |
|
OPZIONALE. [0] EXPLICIT SEQUENCE OF. Una sequence di una o più estensioni CRL.
Se presente, la |
[RFC 5280, clausola 5.1.2.7] |
Il campo crlExtensions PUÒ contenere varie estensioni.
Le estensioni standard notevoli includono:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. SEQUENCE. Fornisce un mezzo per identificare la chiave pubblica corrispondente alla chiave privata usata per firmare la CRL.
Contiene |
RFC 5280, clausola 5.2.1 |
|
OBBLIGATORIO. INTEGER. Un'estensione non critica che convoglia un numero di sequence monotonicamente crescente per un dato scope e issuer di CRL. Sia le base CRL sia le delta CRL condividono la stessa sequence monotonicamente crescente. Il numero della delta CRL DEVE essere maggiore del numero della base CRL che referenzia. |
RFC 5280, clausola 5.2.3 |
|
OBBLIGATORIO per le delta CRL.
NON DEVE comparire nelle base CRL.
INTEGER ( |
RFC 5280, clausola 5.2.4 |
|
OPZIONALE; RACCOMANDATO sulle base CRL nei deployment che emettono delta CRL. SEQUENCE OF DistributionPointName. Un'estensione non critica che indica dove può essere recuperata la delta CRL più recentemente emessa per lo stesso scope.
Ciascun |
RFC 5280, clausola 5.2.6 |
|
OPZIONALE; OBBLIGATORIO quando lo scope della CRL è ristretto (ad es., only-CA, only-end-entity, only-some-reasons) o quando la CRL è indiretta. SEQUENCE ( |
RFC 5280, clausola 5.2.5 |
5.7.3.2. Online Certificate Status Protocol (OCSP)¶
L'Online Certificate Status Protocol (OCSP) (RFC 6960) consente alle applicazioni di determinare lo stato esatto di revoca di certificati identificati. Fornisce informazioni di revoca più tempestive di quanto tipicamente possibile con le CRL e PUÒ anche essere usato per ottenere informazioni di status aggiuntive.
Un client OCSP emette una richiesta di status a un responder OCSP e DEVE sospendere l'accettazione dei certificati in questione fino a quando il responder fornisce una risposta valida.
Se supportato dalla Certificate Authority, l'URI a cui il Responder OCSP può essere invocato DEVE essere presente nell'estensione authorityInfoAccess.accessLocation del Wallet Relying Party Access Certificate (WRPAC).
Questo protocollo specifica i dati che DEVONO essere scambiati tra il client OCSP (che controlla lo status di uno o più certificati) e il server OCSP (che fornisce lo status corrispondente).
La tabella seguente sintetizza i ruoli del client e del server OCSP nell'ecosistema EUDIW.
OCSP Client |
OCSP Server |
Use case |
|---|---|---|
Wallet Unit |
WRPAC Provider |
Controllo Status WRPAC |
Wallet Unit o Relying Party |
PID Provider Trust Anchor |
Controllo Status del PID Sign/Seal Certificate |
Wallet Unit o Relying Party |
PuB-EAA Provider Trust Anchor |
Controllo Status del PuB-EAA Sign/Seal Certificate |
Wallet Unit o Relying Party |
(Q)EAA Provider Trust Anchor |
Controllo Status del (Q)EAA Sign/Seal Certificate |
Nota
Il controllo di Status sui Sign/Seal Certificate è necessario solo nel caso in cui il Sign/Seal Certificate non sia referenziato direttamente come Trust Anchor Certificate, nel qual caso è fidato a priori e non necessita di un controllo di status separato.
5.7.3.2.1. Online Certificate Status Protocol Request Format¶
La richiesta OCSP DEVE essere la codifica ASN.1 DER della SEQUENCE OCSPRequest, che contiene la tbsRequest (To-Be-Signed Request) e una firma opzionale.
La tabella seguente elenca i parametri trovati all'interno della struttura tbsRequest.
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OPZIONALE. [0] EXPLICIT INTEGER. Indica la versione del protocollo.
Se omesso, il valore predefinito è |
[RFC 6960, clausola 4.1.1] |
|
OBBLIGATORIO. SEQUENCE OF. Contiene una o più richieste di status di singolo certificato. |
[RFC 6960, clausola 4.1.1] |
|
OBBLIGATORIO. SEQUENCE. La struttura |
[RFC 6960, clausola 4.1.1] |
|
OPZIONALE. [0] EXPLICIT SEQUENCE. Include estensioni applicabili a questa richiesta di status di singolo certificato. |
[RFC 6960, clausola 4.1.1] |
|
OPZIONALE. [2] EXPLICIT SEQUENCE. Include estensioni applicabili alle richieste complessive trovate all'interno della |
[RFC 6960, clausola 4.1.1] |
Il parametro reqCert utilizza la struttura CertID, DEVE essere una SEQUENCE ASN.1 contenente i seguenti parametri:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. SEQUENCE. Identifica l'algoritmo di hash usato per generare gli hash del nome e della chiave dell'issuer. |
[RFC 6960, clausola 4.1.1] |
|
OBBLIGATORIO. OBJECT IDENTIFIER. L'OID della funzione di hash (ad es., SHA-256, a seconda del profilo). |
[RFC 6960, clausola 4.1.1] |
|
OPZIONALE. ANY. Parametri specifici dell'algoritmo, dipendenti dall'algoritmo di hash usato. |
[RFC 6960, clausola 4.1.1] |
|
OBBLIGATORIO. OCTET STRING. L'hash del distinguished name (DN) dell'issuer, calcolato sulla codifica DER del campo name dell'issuer. |
[RFC 6960, clausola 4.1.1] |
|
OBBLIGATORIO. OCTET STRING. L'hash della chiave pubblica dell'issuer, calcolato sul valore (esclusi tag e length) del campo subject public key. |
[RFC 6960, clausola 4.1.1] |
|
OBBLIGATORIO. INTEGER. Il serial number del certificato target per cui è richiesto lo status. |
[RFC 6960, clausola 4.1.1] |
Le strutture requestExtensions e singleRequestExtensions POSSONO contenere varie estensioni.
La tabella seguente elenca quelle richieste:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. OCTET STRING. Valore crittograficamente fresco usato per vincolare una richiesta e una risposta al fine di prevenire attacchi di replay.
L'identificatore OID è |
[RFC 6960, clausola 4.4.1] |
Quando è inviato su HTTP usando POST, il body di questa richiesta DEVE contenere la codifica DER raw di questa SEQUENCE OCSPRequest. Il body di questa richiesta DEVE avere MIME type application/ocsp-request.
Di seguito un esempio non normativo di una richiesta OCSP:
OCSPRequest request = {
tbsRequest: {
version: 0, // integer value 0 for v1 (RFC 6960 default)
requestList: [
Request {
reqCert: CertID {
hashAlgorithm: AlgorithmIdentifier {
oid: "2.16.840.1.101.3.4.2.1", // sha256
params: NULL
},
issuerNameHash: "HEX(SHA256(DER(IssuerName)))",
issuerKeyHash: "HEX(SHA256(Issuer SubjectPublicKey BIT STRING))",
serialNumber: "0x01A2B3C4D5"
}
}
],
requestExtensions: [
Extension {
oid: "1.3.6.1.5.5.7.48.1.2", // id-pkix-ocsp-nonce
critical: false,
value: OCTET STRING("BASE64(RANDOM_NONCE_BYTES)")
}
]
}
}
5.7.3.2.2. Online Certificate Status Protocol Response Format¶
Una risposta OCSP DEVE essere la codifica ASN.1 DER della SEQUENCE OCSPResponse.
Quando trasportata su HTTP, il body della risposta HTTP DEVE contenere la codifica DER raw di questa OCSPResponse, con il MIME type application/ocsp-response.
La SEQUENCE OCSPResponse contiene i seguenti parametri:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. ENUMERATED. Indica lo status di elaborazione della richiesta precedente.
I valori supportati sono: |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [0] EXPLICIT SEQUENCE. Presente solo quando il |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. OBJECT IDENTIFIER. Identificatore per il tipo di risposta.
Per un responder OCSP basic, questo valore DEVE essere |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. OCTET STRING. Contiene la codifica DER della sintassi di risposta identificata da |
[RFC 6960, clausola 4.2.1] |
Nota
I responder OCSP DEVONO essere in grado di produrre risposte del tipo di risposta id-pkix-ocsp-basic.
Corrispondentemente, i client OCSP DEVONO essere in grado di ricevere ed elaborare risposte del tipo di risposta id-pkix-ocsp-basic.
BasicOCSPResponse è una SEQUENCE ASN.1 contenente i seguenti parametri:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. SEQUENCE. Contiene i dati core della risposta da firmare da parte del responder. |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [0] EXPLICIT INTEGER. La versione della sintassi di risposta.
Se omesso, il valore predefinito è |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. CHOICE. Identifica il responder OCSP.
DEVE contenere o |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [1] EXPLICIT Name. Il |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [2] EXPLICIT OCTET STRING. L'hash SHA-1 del |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. GeneralizedTime. L'ora in cui la risposta OCSP è stata generata. |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. SEQUENCE OF. Una sequence di strutture |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [1] EXPLICIT SEQUENCE OF. Contiene estensioni applicabili alla risposta OCSP complessiva. |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. SEQUENCE. Identifica l'algoritmo crittografico usato per firmare la risposta. |
[RFC 5280, clausola 4.1.1.2] |
|
OBBLIGATORIO. OBJECT IDENTIFIER. L'OID dell'algoritmo di firma. La selezione DOVREBBE allinearsi agli standard rilevanti (ad es., [ETSI TS 119 312]). |
[RFC 5280, clausola 4.1.1.2] |
|
OPZIONALE. ANY. Parametri specifici dell'algoritmo, dipendenti dall'OID definito in |
[RFC 5280, clausola 4.1.1.2] |
|
OBBLIGATORIO. BIT STRING. La firma digitale calcolata sull'hash della |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [0] EXPLICIT SEQUENCE OF. Catena di certificati per aiutare il client a verificare la firma del responder. Se non sono inclusi certificati, questo campo DOVREBBE essere assente. |
[RFC 6960, clausola 4.2.1] |
La struttura responseExtensions PUÒ contenere varie estensioni.
La tabella seguente elenca quelle richieste:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. OCTET STRING. Valore crittograficamente fresco usato per vincolare una richiesta e una risposta al fine di prevenire attacchi di replay.
Se incluso nella richiesta, i responder DOVREBBERO includerlo nella risposta.
L'identificatore OID è |
[RFC 6960, clausola 4.4.1] |
Nella Risposta OCSP DEVE esserci almeno una SingleResponse per ciascun CertID nella richiesta.
Ciascuna SingleResponse è una SEQUENCE ASN.1 che reca i seguenti parametri:
Parameter |
Descrizione |
Riferimento |
|---|---|---|
|
OBBLIGATORIO. SEQUENCE. Identificatore del certificato il cui status è determinato in |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. CHOICE. Il valore dello status del certificato.
DEVE essere esattamente uno tra: |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [0] IMPLICIT NULL. Indica che il certificato è valido. |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [1] IMPLICIT SEQUENCE. Indica che il certificato è stato revocato.
Contiene la struttura |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. GeneralizedTime. L'ora in cui il certificato è stato revocato. |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [0] EXPLICIT ENUMERATED. Contiene il |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [2] IMPLICIT NULL. Indica che il responder non conosce lo status del certificato. |
[RFC 6960, clausola 4.2.1] |
|
OBBLIGATORIO. GeneralizedTime. Indica la data e l'ora di emissione di questa Risposta OCSP. |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [0] EXPLICIT GeneralizedTime. Indica la data e l'ora entro cui il successivo aggiornamento al database del Responder OCSP sarà in vigore. |
[RFC 6960, clausola 4.2.1] |
|
OPZIONALE. [1] EXPLICIT SEQUENCE. Include estensioni applicabili a questa risposta di status di singolo certificato. |
[RFC 6960, clausola 4.2.1] |
Di seguito un esempio non normativo di una risposta OCSP con un singolo status good.
OCSPResponse response = {
responseStatus: "successful", // 0 = successful
responseBytes: ResponseBytes {
responseType: "1.3.6.1.5.5.7.48.1.1", // id-pkix-ocsp-basic
response: BasicOCSPResponse {
tbsResponseData: ResponseData {
version: 0, // integer value 0 for v1 (RFC 6960 default)
responderID: ResponderID {
byName: DistinguishedName {
commonName: "Example OCSP Responder",
organizationName: "Example CA",
countryName: "IT"
}
},
producedAt: "2025-01-01T00:00:00Z",
responses: [
SingleResponse {
certID: CertID {
hashAlgorithm: AlgorithmIdentifier {
oid: "1.3.14.3.2.26", // sha1
params: NULL
},
issuerNameHash: "HEX(SHA256(DER(IssuerName)))",
issuerKeyHash: "HEX(SHA256(Issuer SubjectPublicKey BIT STRING))",
serialNumber: "0x01A2B3C4D5"
},
certStatus: "good",
thisUpdate: "2025-01-01T00:00:00Z",
nextUpdate: "2025-01-02T00:00:00Z",
singleExtensions: [] // absent
}
],
responseExtensions: [
Extension {
oid: "1.3.6.1.5.5.7.48.1.2", // id-pkix-ocsp-nonce
critical: false,
value: OCTET STRING("BASE64(RANDOM_NONCE_BYTES)")
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
signatureValue: "BASE64(SIGN(responderPrivateKey, DER(tbsResponseData)))",
certs: [
"BASE64(RESPONDER_CERT_DER)",
"BASE64(RESPONDER_ISSUING_CA_CERT_DER)"
]
}
}
}
5.7.3.3. Token Status List (WRPRC Profile)¶
Questa sezione profila il meccanismo Token Status List (TSL) di TOKEN-STATUS-LIST per i Wallet-Relying Party Registration Certificate (WRPRC). Una TSL convoglia lo status corrente di molti WRPRC in un Status List Token (SLT) compatto e firmato.
Lo SLT Provider PUÒ essere il Provider of WRPRC o un'entità designata.
5.7.3.3.1. Token Status List (WRPRC Profile): Status List¶
Una Status List contiene un array di byte compresso le cui entry rappresentano gli status di molti WRPRC. Il Provider of WRPRC DEVE assegnare un valore idx distinto, non negativo a ciascun WRPRC emesso e includerlo, insieme all'uri della SLT, nel membro status.status_list del WRPRC. Per un WRPRC codificato JWT, idx è un intero JSON e uri è una stringa JSON.
Per un WRPRC codificato CWT, idx è un intero non firmato CBOR e uri è una text string CBOR. In entrambi i casi, uri DEVE essere un URI conforme a RFC 3986.
Secondo l'ARF e [ETSI TS 119 475], lo status del WRPRC è VALID o INVALID.
Il Provider of WRPRC DEVE impostare il parametro bits nell'oggetto status_list della SLT a 1. Il valore 0x00 rappresenta VALID, e 0x01 rappresenta INVALID.
L'impacchettamento delle entry, la compressione DEFLATE, il formato dati ZLIB e la pubblicazione della Status List sono specificati in Token Status List (Profilo degli Attestati Elettronici).
5.7.3.3.2. Token Status List (WRPRC Profile): Status List Token¶
Lo SLT Provider DEVE agire sia come Status Issuer sia come Status Provider.
Lo SLT Provider DEVE pubblicare ciascuna SLT tramite HTTP GET all'URI nel membro status.status_list.uri del WRPRC.
I media type, il formato JWT o CWT e la protezione mediante firma sono specificati in Token Status List (Profilo degli Attestati Elettronici).
Indipendentemente dal formato, lo SLT Provider per i WRPRC DEVE firmare ciascuna SLT usando un certificato X.509 valido la cui catena di fiducia termina al Trust Anchor pubblicato nella LoTE dei Provider of WRPRC.
Per una SLT JWT, la catena del certificato di firma DEVE essere recata nell'header JOSE x5c.
Per una SLT CWT, essa DEVE essere recata nell'header COSE x5chain (label 33).