12.1. Endpoint del Fornitore di Wallet¶

Il Fornitore di Wallet, responsabile della fornitura di una Soluzione Wallet, DEVE esporre gli endpoint per supportare l'instaurazione della fiducia e le funzionalità essenziali dell'Istanza di Wallet. Questi includono l'endpoint di Federazione /.well-known/openid-federation che DEVE aderire alla specifica OpenID Federation 1.0 per stabilire in modo affidabile la fiducia con il Fornitore di Wallet, nonché endpoint per la registrazione dell'Istanza di Wallet, la generazione di nonce (richiesta per la registrazione), l'emissione di attestati e la revoca. A parte l'endpoint di Federazione, i dettagli di implementazione degli altri sono lasciati alla discrezione del Fornitore di Wallet.

Nota

I test relativi all'uso degli endpoint del Wallet Provider sono definiti in Matrice di Test per Wallet Provider, in particolare in Casi di Test per Backend del Fornitore del Wallet, Casi di Test per Istanza del Wallet e Casi di Test Opzionali per Istanza del Wallet.

12.1.1. Endpoint di Federazione¶

L'endpoint /.well-known/openid-federation serve come meccanismo di discovery per l'instaurazione della fiducia recuperando la Entity Configuration del Fornitore di Wallet.

Vedere la Sezione Entity Configuration del Fornitore di Wallet per i dettagli tecnici (WP_001–004).

12.1.2. Endpoint Nonce della Soluzione Wallet¶

Questo è un endpoint API RESTful che consente all'Istanza di Wallet di richiedere un nonce crittografico dal Fornitore di Wallet. Il nonce serve come sfida imprevedibile, monouso per garantire la freschezza e prevenire attacchi di replay.

Vedere Richiesta di Nonce dell'Applicazione Mobile e Risposta di Nonce dell'Applicazione Mobile per i dettagli sulla Richiesta di Nonce e sulla Risposta di Nonce (WP_131).

12.1.3. Endpoint di Gestione dell'Istanza di Wallet¶

Questi endpoint API RESTful sono forniti dal Fornitore di Wallet e consentono la gestione dell'Istanza di Wallet, inclusa la registrazione, il recupero dello stato, la revoca su richiesta (ad esempio, da parte dell'Utente) e l'eliminazione. Le seguenti sezioni descrivono le richieste di registrazione, recupero dello stato e revoca, insieme alle relative risposte, gestite da questo endpoint, che sono necessarie per le funzionalità di base dell'Funzionalità dell'Istanza del Wallet.

12.1.3.1. Richiesta di Registrazione dell'Istanza di Wallet¶

Per registrare un'Istanza di Wallet, la richiesta al Fornitore di Wallet DEVE utilizzare il metodo HTTP POST con Content-Type impostato su application/json. Il corpo della richiesta DEVE contenere i claim descritti in Richiesta di Inizializzazione dell'Istanza dell'Applicazione Mobile (WP_131–134).

12.1.3.2. Risposta alla Registrazione dell'Istanza di Wallet¶

Se una Richiesta di Registrazione dell'Istanza di Wallet viene convalidata con successo, il Fornitore di Wallet fornisce una Risposta HTTP con codice di stato 204 (No Content). Per i dettagli vedere Risposta di Inizializzazione dell'Istanza dell'Applicazione Mobile (WP_135–137).

12.1.3.3. Richiesta di Recupero dell'Istanza di Wallet¶

Per recuperare tutte le Istanze di Wallet associate a un Utente, una richiesta DEVE essere inviata utilizzando il metodo HTTP GET al Fornitore di Wallet (WP_145).

Nota

Per recuperare una specifica Istanza di Wallet, la richiesta DEVE includere l'ID dell'Istanza di Wallet come parametro di percorso.

12.1.3.4. Risposta al Recupero dell'Istanza di Wallet¶

Se una Richiesta di Recupero dell'Istanza di Wallet viene elaborata con successo, il Fornitore di Wallet DEVE restituire una Risposta HTTP con un codice di stato 200 (OK). Il corpo della risposta DEVE essere in formato JSON e includere le informazioni rilevanti dell'Istanza di Wallet, come il suo ID univoco, lo stato e la data di emissione. Quando si recuperano tutte le Istanze di Wallet, la risposta DEVE restituire un array contenente i dettagli di tutte le istanze associate (WP_146).

Se si verificano errori durante il processo di recupero, DEVE essere restituita una risposta di errore. Fare riferimento a Gestione degli Errori per la Gestione dell'Istanza di Wallet per i dettagli sui codici di errore e le descrizioni.

Di seguito è riportato un esempio non normativo di una risposta di errore:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{
  "error": "forbidden",
  "error_description": "User is not authorized to retrieve Wallet Instances."
}

12.1.3.5. Richiesta di Revoca dell'Istanza di Wallet¶

Per revocare un'Istanza di Wallet attiva, una richiesta di revoca DEVE essere inviata utilizzando il metodo HTTP PATCH con Content-Type impostato su application/json. Il corpo della richiesta DEVE contenere un parametro status impostato su REVOKED (WP_147).

Nota

Mentre PATCH è il metodo consigliato, la richiesta di revoca PUÒ anche essere inviata utilizzando il metodo POST, a seconda delle preferenze di implementazione.

12.1.3.6. Risposta alla Revoca dell'Istanza di Wallet¶

Se una Richiesta di Revoca dell'Istanza di Wallet viene elaborata con successo, il Fornitore di Wallet fornisce una Risposta HTTP con un codice di stato 204 (No Content) come specificato in WP_148.

Se si verificano errori durante la Revoca dell'Istanza di Wallet, DEVE essere restituita una risposta di errore. Fare riferimento a Gestione degli Errori per la Gestione dell'Istanza di Wallet per i dettagli sui codici di errore e le descrizioni (WP_035–039, WP_043–044).

Di seguito è riportato un esempio non normativo di una risposta di errore:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "bad_request",
  "error_description": "The request is missing status parameter."
}

12.1.3.7. Gestione degli Errori per la Gestione dell'Istanza di Wallet¶

Per garantire robustezza e sicurezza, il Fornitore di Wallet DEVE gestire gli errori in modo coerente in tutte le richieste di Gestione dell'Istanza di Wallet, incluse Registrazione, Recupero e Revoca (WP_035–044, e WP_150–155).

In caso di errore, il Fornitore di Wallet DEVE restituire una risposta di errore come definito in RFC 7231, con ulteriori dettagli disponibili in RFC 7807. La risposta DEVE utilizzare il Content-Type impostato su application/json e DEVE includere i seguenti parametri:

error. Il codice di errore.
error_description. Testo in forma leggibile dall'uomo che fornisce ulteriori dettagli per chiarire la natura dell'errore riscontrato.

Le seguenti sezioni classificano gli errori in errori comuni, che si applicano a tutte le richieste, ed errori specifici della richiesta, che sono rilevanti per operazioni particolari.

12.1.3.8. Risposte di Errore Comuni¶

I seguenti errori si applicano a tutte le operazioni di Gestione dell'Istanza di Wallet (Registrazione, Recupero e Revoca) e DEVONO essere supportati per la risposta di errore, se non diversamente specificato (WP_035–039):

Codice di Stato HTTP	Codice di Errore	Descrizione
`400 Bad Request`	`bad_request`	La richiesta è malformata, mancano parametri richiesti o include parametri non validi e sconosciuti.
`422 Unprocessable Content` [OPZIONALE]	`validation_error`	La richiesta non aderisce al formato richiesto.
`500 Internal Server Error`	`server_error`	Si è verificato un errore interno durante l'elaborazione della richiesta.
`503 Service Unavailable`	`temporarily_unavailable`	Il servizio non è disponibile. Si prega di riprovare più tardi.

12.1.3.9. Risposte di Errore Specifiche della Richiesta¶

Gli errori in Risposta di Errore di Inizializzazione dell'Istanza dell'Applicazione Mobile DEVONO essere supportati per le risposte di errore relative alla Registrazione dell'Istanza di Wallet.

I seguenti errori DEVONO essere supportati per le risposte di errore relative al Recupero dell'Istanza di Wallet (WP_041–042):

Codice di Stato HTTP	Codice di Errore	Descrizione
`403 Forbidden`	`forbidden`	L'Utente non ha il permesso di recuperare questa Istanza di Wallet.
`401 Unauthorized`	`unauthorized`	La richiesta manca di Credenziali di autenticazione valide.

I seguenti errori DEVONO essere supportati per le risposte di errore relative alla Revoca dell'Istanza di Wallet (WP_043–044):

Codice di Stato HTTP	Codice di Errore	Descrizione
`403 Forbidden`	`invalid_request`	L'Utente non ha il permesso di revocare questa Istanza di Wallet.
`401 Unauthorized`	`unauthorized`	La richiesta non può essere autenticata o autorizzata.

12.1.4. Endpoint di Emissione della Wallet Instance Attestation¶

Questo è un endpoint API RESTful fornito dal Fornitore di Wallet che consente all'Istanza di Wallet di ottenere una Wallet Instance Attestation, inviando una Richiesta di Emissione della Wallet Instance Attestation.

12.1.4.1. Richiesta di Emissione della Wallet Instance Attestation¶

La richiesta di emissione della Wallet Instance Attestation utilizza il metodo HTTP POST con il Content-Type impostato su application/json (WP_026 e WP_140–142).

L'intestazione typ del JWT della richiesta di emissione della Wallet Instance Attestation assume il valore wia-request+jwt.

Il body della richiesta di emissione della Wallet Instance Attestation contiene un parametro assertion il cui valore è un JWT firmato che include tutti i parametri di intestazione e le claim descritti di seguito.

Di seguito è riportato un esempio non normativo di una richiesta di emissione della Wallet Instance Attestation.

POST /wallet-instance-attestation HTTP/1.1
Host: application-provider.example.org
Content-Type: application/json

{
  "assertion": "eyJpc3MiOiJPbnNpYW5kcklqcDdJbU55ZGlJNklsQ..."
}

In particolare, il JWT della richiesta di emissione della Wallet Instance Attestation include i seguenti parametri di intestazione HTTP:

Parametro	Descrizione	Riferimento
alg	Identificatore dell'algoritmo di firma digitale, come definito nel registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati elencati in Algoritmi Crittografici e non DEVE essere impostato su `none` né su alcun identificatore di algoritmo simmetrico (MAC).	[RFC 7516#section-4.1.1]
kid	thumbprint della JWK dell'Istanza del Wallet contenuta nella dichiarazione `cnf`.	[RFC 7638#section_3]
typ	Il tipo del JWT, che DEVE essere impostato su `wia-request+jwt`.

Il JWT della richiesta include le seguenti claim nel body:

Claim	Descrizione	Riferimento
iss	Stringa contenente l'identificativo univoco della Wallet Instance.	[RFC 9126], [RFC 7519].
exp	UNIX timestamp che rappresenta il tempo di scadenza del JWT.	[RFC 9126], [RFC 7519].
iat	UNIX timestamp che rappresenta il tempo di emissione del JWT.	[RFC 9126], [RFC 7519].
nonce	Il `nonce` ottenuto dal Nonce Endpoint.
hardware_signature	la firma di `client_data_hash` ottenuta utilizzando la Chiave Crittografica Hardware, codificata nel formato `base64url`.
integrity_assertion	L'Integrity Assertion per la Wallet Instance Attestation ottenuta dalle Device Integrity Service APIs con il binding di `client_data_hash`.
hardware_key_tag	Il valore del Tag della Chiave Crittografica Hardware.
intended_issuer	Identificatore URL HTTPS del PID Provider o dell'Attestation Provider a cui l'Istanza del Wallet presenterà la Wallet Instance Attestation.	Sezione 2.5.1 di EUDI-TS 3.
status_list_idx	Intero non negativo. Presente solo quando l'Istanza del Wallet richiede il riutilizzo della voce di status list già assegnata per `intended_issuer`. Vedi Riutilizzo della Voce di Stato per Emittente.	Sezione 2.5.1 di EUDI-TS 3.
cnf	Oggetto JSON contenente la parte pubblica di una coppia di chiavi asimmetriche posseduta dall'istanza del Wallet.	RFC 7800.
platform	Stringa contenente il valore del sistema operativo del dispositivo.
wallet_solution_id	Stringa contenente l'identificatore della Wallet Solution.
wallet_solution_version	Stringa contenente la versione della Wallet Solution.

Di seguito è riportato un esempio non normativo dell'intestazione e del payload del JWT della Wallet Instance Attestation Request.

{
  "alg": "ES256",
  "kid": "OnsiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiL",
  "typ": "wia-request+jwt"
}

{
  "iss": "OnsiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiL",
  "nonce": "f3b29a81-45c7-4d12-b8b5-e1f6c9327aef",
  "hardware_signature": "KoZIhvcNAQcCoIAwgAIB...",
  "integrity_assertion": "o2NmbXRvYXBwbGUtYXBwYXNzZXJ0aW9uLXBheWxvYWQtYXBw...",
  "hardware_key_tag": "QW12DylRTmF89iGkpydNDWW7m8bVpa2Fn9KBeXGYtfX",
  "intended_issuer": "https://credential-issuer.example.org",
  "cnf": {
    "jwk": {
      "crv": "P-256",
      "kty": "EC",
      "x": "8FJtI-yr3pjyRKGMnz4WmdnQD_uJSq4R95Nj98b44",
      "y": "MKZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
    }
  },
  "platform": "iOS",
  "wallet_solution_id": "Wallet-mobile",
  "wallet_solution_version": "1.1.0"
}

12.1.4.2. Risposta all'Emissione della Wallet Instance Attestation¶

Se la Richiesta di Emissione della Wallet Instance Attestation viene convalidata con successo, il Fornitore di Wallet restituisce una risposta HTTP con un codice di stato 200 OK e Content-Type application/json. L'Oggetto JSON restituito DEVE possedere il parametro wallet_instance-attestations (vedi Emissione della Wallet Instance Attestation). wallet_insatnce_attestation sono oggetti JSON che contengono rispettivamente la Wallet Instance Attestation. Entrambe le attestazioni sono firmate dal Fornitore di Wallet (WP_027–029 e WP_143–144). La Wallet Instance Attestation JWT deve essere utilizzato per la fase di Emissione di un Attestato Elettronico, come OAuth Client Attestation, e sarà inviato al Fornitore di Attestati Elettronici come discusso in Emissione di Attestati Elettronici.

L'Oggetto JSON restituito nella risposta ha il seguente claim:

Parametro	Descrizione	Riferimento
wallet_instance-attestation	OBBLIGATORIO. Una stringa contenente una Wallet Instance Attestation.	Questa specifica.

I valori di wallet_instance_attestation sono stringha che contenente rispettivamento la Wallet Instance Attestation in formato JWT.

Se si verifica un errore durante il processo, viene restituita una risposta di errore. La risposta utilizza application/json come Content-Type e include i seguenti parametri:

error: il codice di errore.

error_description: testo in formato leggibile dall'uomo che fornisce ulteriori dettagli per chiarire la natura dell'errore riscontrato (WP_035).

Di seguito è riportato un esempio non normativo di una Wallet Instance Attestation Issuance Response.

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "invalid_request",
  "error_description": "The provided challenge is invalid, expired, or already used."
}

La seguente tabella elenca i codici di stato HTTP e i relativi codici di errore supportati per la risposta di errore, salvo diversa indicazione (WP_036–039 e WP_150–155):

HTTP Status Code	Error Code	Descrizione
`400 Bad Request`	`bad_request`	La richiesta è malformata, mancano parametri obbligatori (ad esempio parametri di intestazione, o Integrity Assertion), oppure include parametri non validi o sconosciuti.
`403 Forbidden`	`invalid_request`	L'istanza del Wallet è stata revocata.
`403 Forbidden`	`integrity_check_error`	Il dispositivo non soddisfa i requisiti minimi di sicurezza del Fornitore di Wallet.
`403 Forbidden`	`invalid_request`	La firma della Wallet Instance Attestation Request non è valida oppure non corrisponde alla chiave pubblica (JWK) associata.
`403 Forbidden`	`invalid_request`	La validazione della Integrity Assertion non è riuscita; la Integrity Assertion è stata manomessa o firmata in modo non corretto.
`403 Forbidden`	`invalid_request`	Il `nonce` fornito non è valido, è scaduto oppure è già stato utilizzato.
`403 Forbidden`	`invalid_request`	La Proof of Possession (`hardware_signature`) non è valida.
`403 Forbidden`	`invalid_request`	Il parametro `iss` non corrisponde all'identificatore URL previsto dal Fornitore di Wallet.
`403 Forbidden`	`invalid_request`	L'Istanza del Wallet non è autorizzata a riutilizzare `status_list_idx` per `intended_issuer`.
`404 Not Found`	`not_found`	L'istanza del Wallet non è stata trovata.
`422 Unprocessable Content` [OPZIONALE]	`validation_error`	La richiesta non rispetta il formato richiesto.
`500 Internal Server Error`	`server_error`	Si è verificato un errore interno del server durante l'elaborazione della richiesta.
`503 Service Unavailable`	`temporarily_unavailable`	Il servizio non è disponibile. Si prega di riprovare più tardi.

12.1.4.3. JWT della Wallet Instance Attestation¶

L'header JOSE del JWT della Wallet Instance Attestation contiene i seguenti parametri:

Header JOSE	Descrizione	Riferimento
alg	OBBLIGATORIO. Un identificatore di algoritmo di firma digitale come da registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati elencati nella Sezione Algoritmi Crittografici e NON DEVE essere impostato su `none` o qualsiasi identificatore di algoritmo simmetrico (MAC).	RFC 7516#section-4.1.1.
kid	OBBLIGATORIO. Identificatore univoco della chiave pubblica associata alla chiave privata che il Fornitore di Wallet ha utilizzato per firmare la Wallet Instance Attestation.	RFC 7638#section_3.
typ	OBBLIGATORIO. DEVE essere impostato su `oauth-client-attestation+jwt`	OPENID4VC-HAIP.
trust_chain	OPZIONALE. Sequenza di Entity Statement che compone la Catena di Fiducia relativa al Fornitore di Wallet.	OID-FED Sezione 4.3 Trust Chain Header Parameter.
x5c	OBBLIGATORIO. Contiene il certificato di chiave pubblica X.509 o la catena di certificati (RFC 5280) corrispondente alla chiave utilizzata per firmare digitalmente il JWT.	RFC 7515 Sezione 4.1.8, SD-JWT-VC Sezione 3.5 e OPENID4VC-HAIP.

Il corpo del JWT della Wallet Instance Attestation contiene i seguenti claim:

Claim	Descrizione	Riferimento
exp	OBBLIGATORIO. Timestamp UNIX con il tempo di scadenza del JWT. La durata è specificata in la durata della Wallet Instance Attestation.	RFC 9126 e RFC 7519 e EUDI-TS 3.
nbf	OPZIONALE. Timestamp UNIX con data e orario prima del quale il JWT NON DEVE essere accettato.	RFC 9126 e RFC 7519.
cnf	OBBLIGATORIO. Oggetto JSON, contenente la parte pubblica di una coppia di chiavi asimmetriche posseduta dall'Istanza di Wallet.	RFC 7800.
wallet_link	OBBLIGATORIO. Stringa contenente un URL per ottenere ulteriori informazioni sul Wallet e sul Fornitore di Wallet.	OpenID4VCI.
wallet_name	OBBLIGATORIO. Stringa contenente un nome leggibile dall'uomo del Wallet.	OpenID4VCI.
wallet_version	OBBLIGATORIO. Valore stringa della versione della Wallet Solution.	OpenID4VCI e EUDI-TS 3.
wallet_solution_certification_information	OPZIONALE. Valore stringa che contiene un URL che rimanda alla certificazione della Wallet Solution.	EUDI-TS 3.
client_status	OBBLIGATORIO. Meccanismo di stato per la Wallet Attestation. status: OBBLIGATORIO. un riferimento alla lista di stato, come specificato nell’Appendice E di OpenID4VCI. Il valore rappresenta lo stato di revoca dell’istanza del Wallet. exp: OBBLIGATORIO. Timestamp UNIX che specifica il momento fino al quale il Wallet Provider si impegna a mantenere lo stato di revoca nell’indice della lista di stato referenziato in `status`.	EUDI-TS 3.
sub	OBBLIGATORIO. Identificatore dell’istanza del Wallet, che è l’identificatore univoco della Wallet Solution in formato URL.	EUDI-TS 3.

Di seguito è riportato un esempio non normativo dell'header e del payload della Wallet Instance Attestation JWT senza codifica e firma applicata:

{
    "typ": "oauth-client-attestation+jwt",
    "x5c": [
      "MIICrDCCAlKgAwIBAgIUCQ5zD8eGxAN6c5isgQk0jkp3qzwwCgYIKoZIzj0EAwIwgZIxCzAJBgNVBAYTAklUMQ4wDAYDVQQIDAVMYXppbzENMAsGA1UEBwwEUm9tYTEWMBQGA1UECgwNUGFnb1BBIFMucC5BLjEkMCIGA1UEAwwbZm9vMTEuYmxvYi5jb3JlLndpbmRvd3MubmV0MSYwJAYJKoZIhvcNAQkBFhdwYWdvcGFzcGFAcGVjLnBhZ29wYS5pdDAeFw0yNTA3MDMxNTE2NTlaFw0yNjA3MDMxNTE2NTlaMIGSMQswCQYDVQQGEwJJVDEOMAwGA1UECAwFTGF6aW8xDTALBgNVBAcMBFJvbWExFjAUBgNVBAoMDVBhZ29QQSBTLnAuQS4xJDAiBgNVBAMMG2ZvbzExLmJsb2IuY29yZS53aW5kb3dzLm5ldDEmMCQGCSqGSIb3DQEJARYXcGFnb3Bhc3BhQHBlYy5wYWdvcGEuaXQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARtdnuBd5hAg3cPyz7/o8vBFyL4sp45HikFogMZse7f9/iL4gn6YM/ehP1CQI0dFnT3c/RdxFyRukKWXscopwXso4GDMIGAMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMCYGA1UdEQQfMB2CG2ZvbzExLmJsb2IuY29yZS53aW5kb3dzLm5ldDAdBgNVHQ4EFgQUOd7M/0bo1+saPT/H9M+G96sKnYIwHwYDVR0jBBgwFoAUkKHxQLaudIm0WfwZeN5HMTG8SCMwCgYIKoZIzj0EAwIDSAAwRQIgSXKs9Gx2bXVG9nxap1I/KqwHdh6SQDKI85J9n7FqrI8CIQCqltHTw6sci1R4RSOFySEvzEohQTbNTke+X2lD9iQd5A==",
      "MIIDqjCCA1GgAwIBAgIGAZc6/V9qMAoGCCqGSM49BAMCMIGzMQswCQYDVQQGEwJJVDEOMAwGA1UECAwFTGF6aW8xDTALBgNVBAcMBFJvbWExMTAvBgNVBAoMKElzdGl0dXRvIFBvbGlncmFmaWNvIGUgWmVjY2EgZGVsbG8gU3RhdG8xCzAJBgNVBAsMAklUMR4wHAYDVQQDDBVwcmUudGEud2FsbGV0LmlwenMuaXQxJTAjBgkqhkiG9w0BCQEWFnByb3RvY29sbG9AcGVjLmlwenMuaXQwHhcNMjUwNjA0MTI0OTMzWhcNMjcwNjA0MTI0OTMzWjCBkjELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUxhemlvMQ0wCwYDVQQHDARSb21hMRYwFAYDVQQKDA1QYWdvUEEgUy5wLkEuMSQwIgYDVQQDDBtmb28xMS5ibG9iLmNvcmUud2luZG93cy5uZXQxJjAkBgkqhkiG9w0BCQEWF3BhZ29wYXNwYUBwZWMucGFnb3BhLml0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgXY4FApFJCj91Gpb1K9GEIouTq2X3L0K64Iq0ob4l/iX7p1ysisVV2vOhj1xEm/3M24U5HcywPPpNIOEHTESjqOCAW4wggFqMB0GA1UdDgQWBBSQofFAtq50ibRZ/Bl43kcxMbxIIzCB5QYDVR0jBIHdMIHagBTzUINxjECpXem0zyIpsnTqv3DEGaGBuaSBtjCBszELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUxhemlvMQ0wCwYDVQQHDARSb21hMTEwLwYDVQQKDChJc3RpdHV0byBQb2xpZ3JhZmljbyBlIFplY2NhIGRlbGxvIFN0YXRvMQswCQYDVQQLDAJJVDEeMBwGA1UEAwwVcHJlLnRhLndhbGxldC5pcHpzLml0MSUwIwYJKoZIhvcNAQkBFhZwcm90b2NvbGxvQHBlYy5pcHpzLml0ggYBlzr5eUMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAAcwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cHM6Ly9wcmUudGEud2FsbGV0LmlwenMuaXQvcGtpL3RhLXN1Yi5jcmwwCgYIKoZIzj0EAwIDRwAwRAIgBSyH++oPDP8ipRxHcJ8u2HkN7wL44XpJFxSIBV9RFHMCIBixpcT43NSsk0EvhJb4g68c1d9OrBnXOXVuyCtWWE6a",
      "MIIDQzCCAuigAwIBAgIGAZc6+XlDMAoGCCqGSM49BAMCMIGzMQswCQYDVQQGEwJJVDEOMAwGA1UECAwFTGF6aW8xDTALBgNVBAcMBFJvbWExMTAvBgNVBAoMKElzdGl0dXRvIFBvbGlncmFmaWNvIGUgWmVjY2EgZGVsbG8gU3RhdG8xCzAJBgNVBAsMAklUMR4wHAYDVQQDDBVwcmUudGEud2FsbGV0LmlwenMuaXQxJTAjBgkqhkiG9w0BCQEWFnByb3RvY29sbG9AcGVjLmlwenMuaXQwHhcNMjUwNjA0MTI0NTE3WhcNMzAwNjAzMTI0NTE3WjCBszELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUxhemlvMQ0wCwYDVQQHDARSb21hMTEwLwYDVQQKDChJc3RpdHV0byBQb2xpZ3JhZmljbyBlIFplY2NhIGRlbGxvIFN0YXRvMQswCQYDVQQLDAJJVDEeMBwGA1UEAwwVcHJlLnRhLndhbGxldC5pcHpzLml0MSUwIwYJKoZIhvcNAQkBFhZwcm90b2NvbGxvQHBlYy5pcHpzLml0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaE0xyhd3e9LDT7uwHOclL5H3389gwiCwFhI3KOvidn0glBIHYxqH+4Z9VTMYWG5L8cwC9AaJUCNGu2dp5ZiiTKOB5TCB4jAdBgNVHQ4EFgQU81CDcYxAqV3ptM8iKbJ06r9wxBkwHwYDVR0jBBgwFoAU81CDcYxAqV3ptM8iKbJ06r9wxBkwDwYDVR0TAQH/BAUwAwEB/zBEBggrBgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAKGKGh0dHBzOi8vcHJlLnRhLndhbGxldC5pcHpzLml0L3BraS90YS5jZXIwDgYDVR0PAQH/BAQDAgEGMDkGA1UdHwQyMDAwLqAsoCqGKGh0dHBzOi8vcHJlLnRhLndhbGxldC5pcHpzLml0L3BraS90YS5jcmwwCgYIKoZIzj0EAwIDSQAwRgIhAOsQYzR+eGf4je63VGHqkpmkBbfyOre+mfIdHHowWWR/AiEA58xBNb5UW5uMB+tQur8fq24RD5MmRHLYS6bDgIYmluw="
    ],
    "alg": "ES256",
    "kid": "8UkfrvttLkpAQOOp"
  }

{
  
    "cnf": {
      "jwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "8g9qKk3tRCBHsu57pNy3oMPc-jeJW8zU1LvfG9H5__M",
        "y": "KD0MNCPtJqUd1RGiTdAxEL6OCw5trfzqSrU6BHKOy2g",
        "kid": "dd762e6f8b613193",
        "alg":"ES256"
      }
    },
    "client_status": {
      "status": {
        "status_list": {
          "idx": 1337,
          "uri": "https://revocation_url/wia-statuslists/42"
        }
      },
      "exp": 1772447918
    },
    "wallet_name": "ExampleOrg",
    "wallet_version": "1.0.0",
    "wallet_link": "https://example.org/wallets/ExampleOrg/info",
    "wallet_solution_certification_information": "https://example.org/wallets/ExampleOrg/certification",
    "sub": "https://wallet-solution.example.org/dd762e6f8b613193",
    "exp": 1772447918
  
}

Nota

Poiché lo schema di certificazione non è ancora stato definito, il contenuto esatto di wallet_solution_certification_information è indefinito. Questo contenuto sarà definito in un aggiornamento futuro.

Nota

Le regole di riutilizzo per emittente di client_status.status sono definite in Riutilizzo della Voce di Stato per Emittente.

Nota

Il claim iss non è più necessario nel corpo della WIA, poiché l’identità del Wallet Provider viene ora dedotta dal certificato di firma nel parametro di intestazione JOSE x5c.

12.1.5. Endpoint di Emissione della Key Attestation¶

Questo è un endpoint API RESTful fornito dal Wallet Provider che consente alla Wallet Instance di ottenere una Key Attestation, inviando una Richiesta di Emissione della Key Attestation. L'uso delle Key Attestation APIs (OEM) è definito in Uso delle API di Key Attestation (OEM).

12.1.5.1. Richiesta di Emissione della Key Attestation¶

La richiesta di emissione della Key Attestation utilizza il metodo HTTP POST con Content-Type impostato a application/json. (WP_026 e WP_140–142).

L'header typ del JWT della richiesta di emissione Key Attestation Issuance assume il valore ka-request+jwt.

Il body della richiesta di emissione Key Attestation contiene un parametro assertion il cui valore è un JWT firmato che include tutti i parametri di header e i claim del body descritti di seguito.

Di seguito è riportato un esempio non normativo di una Key Attestation Request.

POST /key-attestation HTTP/1.1
Host: application-provider.example.org
Content-Type: application/json

{
  "assertion": "eyJpc3MiOiJPbnNpYW5kcklqcDdJbU55ZGlJNklsQ..."
}

In particolare, il JWT della Key Attestation Issuance include i seguenti parametri di header HTTP:

Parameter	Description	Reference
alg	Identificatore di algoritmo di firma digitale, come definito dal registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati elencati in Algoritmi Crittografici e NON DEVE essere impostato a `none` né a un identificatore di algoritmo simmetrico (MAC).	[RFC 7516#section-4.1.1]
kid	Thumbprint della JWK della Wallet Instance contenuta nel claim `cnf`.	[RFC 7638#section_3]
typ	Il tipo del JWT; DEVE essere impostato a `ka-request+jwt`.

Il JWT della Key Attestation Request include i seguenti claim nel body:

Claim	Description	Reference
iss	Stringa contenente l'identificativo univoco della Wallet Instance.	[RFC 9126], [RFC 7519].
exp	Timestamp UNIX che rappresenta il tempo di scadenza del JWT.	[RFC 9126], [RFC 7519].
iat	Timestamp UNIX che rappresenta il tempo di emissione del JWT.	[RFC 9126], [RFC 7519].
nonce	Il `nonce` ottenuto dal Nonce Endpoint.
keys_to_attest	Array JSON di stringhe JWT. Ciascun JWT è un elemento di Key Attestation come definito in Elemento di Key Attestation. L'inclusione di materiale delle API di Key Attestation (OEM) è soggetta a Uso delle API di Key Attestation (OEM).
hardware_signature	La firma di `client_data_hash` ottenuta utilizzando la Cryptographic Hardware Key, codificata nel formato `base64url`.
hardware_key_tag	Il valore del Cryptographic Hardware Key Tag.
cnf	Oggetto JSON contenente la parte pubblica della prima coppia di chiavi asimmetriche (primo elemento di `keys_to_attest`) posseduta dalla Wallet Instance.	RFC 7800.
platform	Stringa contenente il valore del sistema operativo del dispositivo.
wallet_solution_id	Stringa contenente l'identificatore della Wallet Solution.
wallet_solution_version	Stringa contenente la versione della Wallet Solution.

12.1.5.1.1. Elemento di Key Attestation¶

Ciascun elemento di keys_to_attest è un JWT firmato con la chiave privata corrispondente al proprio claim cnf.

L'header JOSE contiene i seguenti parametri:

Parameter	Description	Reference
alg	Identificatore di algoritmo di firma digitale, come definito dal registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati elencati in Algoritmi Crittografici e NON DEVE essere impostato a `none` né a un identificatore di algoritmo simmetrico (MAC).	[RFC 7516#section-4.1.1]
kid	Thumbprint della JWK contenuta nel claim `cnf` di questo JWT.	[RFC 7638#section_3]
typ	Il tipo del JWT. DEVE essere impostato a `key-attestation-request+jwt`.

Il body del JWT contiene i seguenti claim:

Claim	Description	Reference
iat	OBBLIGATORIO. Timestamp UNIX che rappresenta il tempo di emissione del JWT.	[RFC 7519]
exp	OBBLIGATORIO. Timestamp UNIX che rappresenta il tempo di scadenza del JWT.	[RFC 7519]
cnf	OBBLIGATORIO. Oggetto JSON contenente la chiave pubblica attestata da questo elemento.	RFC 7800.
wscd_key_attestation	OBBLIGATORIO. Oggetto JSON che descrive l'archivio della chiave e, dove applicabile, l'attestazione di piattaforma di questa chiave. storage_type: OBBLIGATORIO. Stringa che identifica l'archivio della chiave. Il valore `LOCAL_NATIVE` identifica il Keystore locale. attestation: Su Android, quando sono usate le API di Key Attestation (OEM), la key attestation OEM prodotta alla generazione della chiave. L'Istanza del Wallet DEVE omettere questo membro per le chiavi del PID e su iOS. Vedi Emissione della Key Attestation e Uso delle API di Key Attestation (OEM). integrity_assertion: OBBLIGATORIO su iOS. L'asserzione del Servizio di Integrità del Dispositivo per questa chiave, vincolata a `client_data_hash`. L'Istanza del Wallet DEVE omettere questo membro su Android.	Questa specifica.

Di seguito è riportato un esempio non normativo di un payload keys_to_attest decodificato su Android, quando è incluso materiale OEM.

{
  "wscd_key_attestation": {
    "storage_type": "LOCAL_NATIVE",
    "attestation": "MIICszCCA..."
  },
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "xAH9SNfaq9J5dmkzXYQLek5YfpPc8i_PpMRT315hjMk",
      "y": "PE2XLcpW6eXH4FlYGNP9BhwQQdEiZE1tAdT-EihACC8"
    }
  },
  "iat": 1773053861,
  "exp": 1773057461
}

Di seguito è riportato un esempio non normativo di un payload keys_to_attest decodificato su iOS.

{
  "wscd_key_attestation": {
    "storage_type": "LOCAL_NATIVE",
    "integrity_assertion": "o2NmbXRvYXBwbGUtYXBwYXNzZXJ0aW9uLXBheWxvYWQtYXBw..."
  },
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "DUQVLhK1KQRd-gx7QNcaSaXCg9x4KtzBk-5b1Y3dye4",
      "y": "FqV94MekVn_CNf521vmo-QHqfNnMvxgHGsEx9BNW8hQ"
    }
  },
  "iat": 1773053861,
  "exp": 1773057461
}

Di seguito è riportato un esempio non normativo dell'header e del payload JWT di una Key Attestation Request.

{
  "alg": "ES256",
  "kid": "OnsiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiL",
  "typ": "ka-request+jwt"
}

{
  "iss": "OnsiandrIjp7ImNydiI6IlAtMjU2Iiwia3R5IjoiRUMiL",
  "nonce": "f3b29a81-45c7-4d12-b8b5-e1f6c9327aef",
  "hardware_signature": "KoZIhvcNAQcCoIAwgAIB...",
  "hardware_key_tag": "QW12DylRTmF89iGkpydNDWW7m8bVpa2Fn9KBeXGYtfX",
  "cnf": {
    "jwk": {
      "crv": "P-256",
      "kty": "EC",
      "x": "8FJtI-yr3pjyRKGMnz4WmdnQD_uJSq4R95Nj98b44",
      "y": "MKZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg"
    }
  },
  "keys_to_attest": [
    "eyJ0eXAiOiJrZXktYXR0ZXN0YXRpb24tcmVxdWVzdCtqd3QiLCJhbGciOiJFUzI1NiJ9.eyJ3c2NkX2tleV9hdHRlc3RhdGlvbiI6e30sImNuZiI6e319.c2lnbmF0dXJl"
  ],
  "platform": "iOS",
  "wallet_solution_id": "Wallet-mobile",
  "wallet_solution_version": "1.1.0"
}

12.1.5.2. Risposta all'Emissione della Key Attestation¶

Se la Key Attestation Issuance Request viene validata con successo, il Wallet Provider restituisce una risposta HTTP con codice di stato 200 OK e Content-Type application/json. L'oggetto JSON restituito include key_attestation (si veda Emissione della Key Attestation). key_attestation è firmata dal Wallet Provider (WP_027–029 e WP_143–144). La Key Attestation JWT deve essere utilizzata nella fase di Emissione di un Attestato Elettronico, come intestazione JOSE key_attestation nel JWT di tipo proof, e verrà inviata al Fornitore di Attestati Elettronici come discusso in Emissione di Attestati Elettronici.

L'oggetto JSON restituito nella risposta contiene il seguente parametro:

Parameter	Description	Reference
key_attestation	OBBLIGATORIO. Una stringa che rappresenta la Key Attestation rilasciata.	Questa specifica.

Il valore del parametro key_attestation è una stringa che rappresenta la Key Attestation in formato JWT.

Se durante il processo si verificano errori, viene restituita una risposta di errore come definito nella sezione precedente.

La tabella seguente elenca i codici di stato HTTP e i relativi codici di errore per i casi che differiscono da quanto già riportato:

HTTP Status Code	Error Code	Description
`400 Bad Request`	`bad_request`	La richiesta è malformata, mancano parametri obbligatori (ad esempio parametri di header o `keys_to_attest`), oppure include parametri non validi o sconosciuti.
`403 Forbidden`	`invalid_request`	La validazione di `keys_to_attest` non è riuscita. La key attestation OEM o l'asserzione di integrità iOS è stata manomessa oppure firmata in modo non corretto.
`403 Forbidden`	`invalid_request`	La firma della key Attestation Request non è valida oppure non corrisponde alla chiave pubblica associata (JWK).

12.1.5.3. Key Attestation JWT¶

L'intestazione JOSE del Key Attestation JWT contiene i seguenti parametri:

JOSE header	Descrizione	Riferimento
alg	OBBLIGATORIO. Un identificatore di algoritmo di firma digitale come da registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati elencati in Algoritmi Crittografici e NON DEVE essere impostato su `none` o qualsiasi identificatore di algoritmo simmetrico (MAC).	RFC 7516#section-4.1.1.
kid	OBBLIGATORIO. Identificatore univoco della chiave pubblica associata alla chiave privata che il Fornitore di Wallet ha utilizzato per firmare la Key Attestation.	RFC 7638#section_3.
typ	OBBLIGATORIO. DEVE essere impostato su `key-attestation+jwt`	OPENID4VC-HAIP.
trust_chain	OPZIONALE. Sequenza di Entity Statement che compone la Catena di Fiducia relativa al Fornitore di Wallet.	OID-FED Sezione 4.3 Trust Chain Header Parameter.
x5c	OBBLIGATORIO. Contiene il certificato di chiave pubblica X.509 o la catena di certificati (RFC 5280) corrispondente alla chiave utilizzata per firmare digitalmente il JWT.	RFC 7515 Sezione 4.1.8 e SD-JWT-VC Sezione 3.5.

Il corpo del Key Attestation JWT contiene le seguenti dichiarazioni (claims):

Claim	Descrizione	Riferimento
exp	OBBLIGATORIO. Timestamp UNIX con il tempo di scadenza del JWT.	RFC 9126 e RFC 7519.
iat	OBBLIGATORIO. Timestamp UNIX con il tempo di emissione del JWT.	RFC 9126 e RFC 7519.
attested_keys	OBBLIGATORIO. Un array non vuoto di chiavi attestate provenienti dallo stesso componente di archiviazione delle chiavi, utilizzando la sintassi JWK, contenente la parte pubblica di una coppia di chiavi asimmetriche posseduta dall'istanza del Wallet.	RFC 7517.
key_storage	OBBLIGATORIO. Un array non vuoto di stringhe sensibili alle maiuscole che dichiarano la resistenza al potenziale di attacco del componente di archiviazione delle chiavi e delle chiavi attestate nel parametro `attested_keys`. I seguenti valori sono definiti come possibili valori per questa dichiarazione claim: `iso_18045_high`: DEVE essere utilizzato quando l'archiviazione delle chiavi è resistente ad attacchi con potenziale di attacco `High`. `iso_18045_moderate`: DEVE essere utilizzato quando l'archiviazione delle chiavi è resistente ad attacchi con potenziale di attacco `Moderate`. `iso_18045_enhanced-basic`: DEVE essere utilizzato quando l'archiviazione delle chiavi è resistente ad attacchi con potenziale di attacco `Enhanced-Basic`. `iso_18045_basic`: DEVE essere utilizzato quando l'archiviazione delle chiavi è resistente ad attacchi con potenziale di attacco `Basic`.	OpenID4VCI.
user_authentication	OBBLIGATORIO. Un array non vuoto di stringhe sensibili alle maiuscole che dichiarano la resistenza al potenziale di attacco dei metodi di autenticazione utente autorizzati ad accedere alle chiavi private dal parametro attested_keys. I seguenti valori sono definiti come possibili valori per questa dichiarazione claim: `iso_18045_high`: DEVE essere utilizzato quando l'autenticazione dell'utente è resistente ad attacchi con potenziale di attacco `High`. `iso_18045_moderate`: DEVE essere utilizzato quando l'autenticazione dell'utente è resistente ad attacchi con potenziale di attacco `Moderate`. `iso_18045_enhanced-basic`: DEVE essere utilizzato quando l'autenticazione dell'utente è resistente ad attacchi con potenziale di attacco `Enhanced-Basic`. `iso_18045_basic`: DEVE essere utilizzato quando l'autenticazione dell'utente è resistente ad attacchi con potenziale di attacco `Basic`.	OpenID4VCI.
key_storage_status	OBBLIGATORIO. Meccanismo di stato per la Key Attestation. status: OBBLIGATORIO. un riferimento alla lista di stato, come specificato nell’Appendice D di OpenID4VCI. Il valore rappresenta lo stato di revoca del WSCD o del Keystore. exp: OBBLIGATORIO. Timestamp UNIX che specifica il momento fino al quale il Wallet Provider si impegna a mantenere lo stato di revoca nell’indice della lista di stato referenziato in `status`.	EUDI-TS 3.
certification	OPZIONALE. Una stringa che contiene un URL che rimanda alla certificazione del componente di archiviazione delle chiavi.	OpenID4VCI.

Il Fornitore di Wallet DEVE impostare key_storage e user_authentication su valori ISO 18045 che corrispondono alla resistenza al potenziale di attacco del Keystore o WSCD effettivo e del metodo di autenticazione dell'Utente. Il Fornitore di Wallet DEVE documentare il mapping usato per TEE, StrongBox e Secure Enclave. Un Keystore Interno Locale NON DEVE essere attestato con iso_18045_high. Un WSCD certificato come resistente ad attaccanti con potenziale di attacco elevato (ad esempio Common Criteria EAL4+ AVA_VAN.5) PUÒ essere attestato con iso_18045_high (WP_022a).

Di seguito è riportato un esempio non normativo dell'intestazione e del payload del Key Attestation JWT, senza codifica né firma applicata:

{
    "typ": "key-attestation+jwt",
    "x5c": [
      "MIICrDCCAlKgAwIBAgIUCQ5zD8eGxAN6c5isgQk0jkp3qzwwCgYIKoZIzj0EAwIwgZIxCzAJBgNVBAYTAklUMQ4wDAYDVQQIDAVMYXppbzENMAsGA1UEBwwEUm9tYTEWMBQGA1UECgwNUGFnb1BBIFMucC5BLjEkMCIGA1UEAwwbZm9vMTEuYmxvYi5jb3JlLndpbmRvd3MubmV0MSYwJAYJKoZIhvcNAQkBFhdwYWdvcGFzcGFAcGVjLnBhZ29wYS5pdDAeFw0yNTA3MDMxNTE2NTlaFw0yNjA3MDMxNTE2NTlaMIGSMQswCQYDVQQGEwJJVDEOMAwGA1UECAwFTGF6aW8xDTALBgNVBAcMBFJvbWExFjAUBgNVBAoMDVBhZ29QQSBTLnAuQS4xJDAiBgNVBAMMG2ZvbzExLmJsb2IuY29yZS53aW5kb3dzLm5ldDEmMCQGCSqGSIb3DQEJARYXcGFnb3Bhc3BhQHBlYy5wYWdvcGEuaXQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARtdnuBd5hAg3cPyz7/o8vBFyL4sp45HikFogMZse7f9/iL4gn6YM/ehP1CQI0dFnT3c/RdxFyRukKWXscopwXso4GDMIGAMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMCYGA1UdEQQfMB2CG2ZvbzExLmJsb2IuY29yZS53aW5kb3dzLm5ldDAdBgNVHQ4EFgQUOd7M/0bo1+saPT/H9M+G96sKnYIwHwYDVR0jBBgwFoAUkKHxQLaudIm0WfwZeN5HMTG8SCMwCgYIKoZIzj0EAwIDSAAwRQIgSXKs9Gx2bXVG9nxap1I/KqwHdh6SQDKI85J9n7FqrI8CIQCqltHTw6sci1R4RSOFySEvzEohQTbNTke+X2lD9iQd5A==",
      "MIIDqjCCA1GgAwIBAgIGAZc6/V9qMAoGCCqGSM49BAMCMIGzMQswCQYDVQQGEwJJVDEOMAwGA1UECAwFTGF6aW8xDTALBgNVBAcMBFJvbWExMTAvBgNVBAoMKElzdGl0dXRvIFBvbGlncmFmaWNvIGUgWmVjY2EgZGVsbG8gU3RhdG8xCzAJBgNVBAsMAklUMR4wHAYDVQQDDBVwcmUudGEud2FsbGV0LmlwenMuaXQxJTAjBgkqhkiG9w0BCQEWFnByb3RvY29sbG9AcGVjLmlwenMuaXQwHhcNMjUwNjA0MTI0OTMzWhcNMjcwNjA0MTI0OTMzWjCBkjELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUxhemlvMQ0wCwYDVQQHDARSb21hMRYwFAYDVQQKDA1QYWdvUEEgUy5wLkEuMSQwIgYDVQQDDBtmb28xMS5ibG9iLmNvcmUud2luZG93cy5uZXQxJjAkBgkqhkiG9w0BCQEWF3BhZ29wYXNwYUBwZWMucGFnb3BhLml0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgXY4FApFJCj91Gpb1K9GEIouTq2X3L0K64Iq0ob4l/iX7p1ysisVV2vOhj1xEm/3M24U5HcywPPpNIOEHTESjqOCAW4wggFqMB0GA1UdDgQWBBSQofFAtq50ibRZ/Bl43kcxMbxIIzCB5QYDVR0jBIHdMIHagBTzUINxjECpXem0zyIpsnTqv3DEGaGBuaSBtjCBszELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUxhemlvMQ0wCwYDVQQHDARSb21hMTEwLwYDVQQKDChJc3RpdHV0byBQb2xpZ3JhZmljbyBlIFplY2NhIGRlbGxvIFN0YXRvMQswCQYDVQQLDAJJVDEeMBwGA1UEAwwVcHJlLnRhLndhbGxldC5pcHpzLml0MSUwIwYJKoZIhvcNAQkBFhZwcm90b2NvbGxvQHBlYy5pcHpzLml0ggYBlzr5eUMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAAcwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cHM6Ly9wcmUudGEud2FsbGV0LmlwenMuaXQvcGtpL3RhLXN1Yi5jcmwwCgYIKoZIzj0EAwIDRwAwRAIgBSyH++oPDP8ipRxHcJ8u2HkN7wL44XpJFxSIBV9RFHMCIBixpcT43NSsk0EvhJb4g68c1d9OrBnXOXVuyCtWWE6a",
      "MIIDQzCCAuigAwIBAgIGAZc6+XlDMAoGCCqGSM49BAMCMIGzMQswCQYDVQQGEwJJVDEOMAwGA1UECAwFTGF6aW8xDTALBgNVBAcMBFJvbWExMTAvBgNVBAoMKElzdGl0dXRvIFBvbGlncmFmaWNvIGUgWmVjY2EgZGVsbG8gU3RhdG8xCzAJBgNVBAsMAklUMR4wHAYDVQQDDBVwcmUudGEud2FsbGV0LmlwenMuaXQxJTAjBgkqhkiG9w0BCQEWFnByb3RvY29sbG9AcGVjLmlwenMuaXQwHhcNMjUwNjA0MTI0NTE3WhcNMzAwNjAzMTI0NTE3WjCBszELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUxhemlvMQ0wCwYDVQQHDARSb21hMTEwLwYDVQQKDChJc3RpdHV0byBQb2xpZ3JhZmljbyBlIFplY2NhIGRlbGxvIFN0YXRvMQswCQYDVQQLDAJJVDEeMBwGA1UEAwwVcHJlLnRhLndhbGxldC5pcHpzLml0MSUwIwYJKoZIhvcNAQkBFhZwcm90b2NvbGxvQHBlYy5pcHpzLml0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEaE0xyhd3e9LDT7uwHOclL5H3389gwiCwFhI3KOvidn0glBIHYxqH+4Z9VTMYWG5L8cwC9AaJUCNGu2dp5ZiiTKOB5TCB4jAdBgNVHQ4EFgQU81CDcYxAqV3ptM8iKbJ06r9wxBkwHwYDVR0jBBgwFoAU81CDcYxAqV3ptM8iKbJ06r9wxBkwDwYDVR0TAQH/BAUwAwEB/zBEBggrBgEFBQcBAQQ4MDYwNAYIKwYBBQUHMAKGKGh0dHBzOi8vcHJlLnRhLndhbGxldC5pcHpzLml0L3BraS90YS5jZXIwDgYDVR0PAQH/BAQDAgEGMDkGA1UdHwQyMDAwLqAsoCqGKGh0dHBzOi8vcHJlLnRhLndhbGxldC5pcHpzLml0L3BraS90YS5jcmwwCgYIKoZIzj0EAwIDSQAwRgIhAOsQYzR+eGf4je63VGHqkpmkBbfyOre+mfIdHHowWWR/AiEA58xBNb5UW5uMB+tQur8fq24RD5MmRHLYS6bDgIYmluw="
    ],
    "alg": "ES256",
    "kid": "8UkfrvttLkpAQOOp"
  }

{
    "attested_keys": [
        {
            "crv": "P-256",
            "kty": "EC",
            "x": "4HNptI-xr2pjyRJKGMnz4WmdnQD_uJSq4R95Nj98b44",
            "y": "LIZnSB39vFJhYgS3k7jXE4r3-CoGFQwZtPBIRqpNlrg",
            "kid": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"
        }
    ],
    "key_storage_status": {
        "status": {
            "status_list": {
                "idx": 412,
                "uri": "https://revocation_url/statuslists/1"
            }
        },
        "exp": 1687288395
    },
    "iat": 1687281195,
    "exp": 1687288395,
    "key_storage": [ "iso_18045_moderate" ],
    "user_authentication": [ "iso_18045_moderate" ]
}

Nota

Poiché lo schema di certificazione non è ancora stato definito, il contenuto esatto di certification non è definito e sarà specificato in un futuro aggiornamento.

Nota

Come meccanismo di revoca per la KA, è preferito l'indice condiviso per tipo descritto nella Sezione 2.5.2 di EUDI-TS 3.

Nota

Un fornitore di Wallet DEVE scegliere il periodo di validità tecnica della KA e DEVE mantenere l'elenco degli stati di revoca per l'intero periodo di validità di tale elenco, come indicato nel claim key_storage_status.exp.

12.1.6. Token Status List (Profilo dell'Attestato di Wallet Unit)¶

Questa sezione profila il meccanismo Token Status List (TSL) di TOKEN-STATUS-LIST per le Wallet Unit Attestation. Una TSL convoglia lo stato corrente di molte Wallet Unit Attestation in un Status List Token (SLT) compatto e firmato.

Lo SLT Provider DEVE essere il Fornitore di Wallet.

12.1.6.1. Status List¶

Una Status List contiene un array di byte compresso le cui entry rappresentano gli stati di molte Wallet Instance Attestation (WIA) o Key Attestation (KA). Una WIA DEVE includere il proprio riferimento alla Status List in client_status.status.status_list. Una KA DEVE includere il proprio riferimento alla Status List in key_storage_status.status.status_list. Ciascun riferimento alla Status List DEVE contenere idx e uri. Sia le WIA sia le KA sono JWT. Pertanto, in ciascun riferimento, idx è un intero JSON e uri è una stringa JSON. In entrambi i casi, uri DEVE essere un URI conforme a RFC 3986.

Secondo questa specifica, una WIA o una KA può avere uno dei seguenti stati:

VALID. La WIA o la KA è valida. Questo stato è rappresentato da 0x00 nella SLT.

INVALID. La WIA o la KA è revocata. Questo stato è rappresentato da 0x01 nella SLT.

Di conseguenza, il Fornitore di Wallet DEVE impostare il parametro bits nell'oggetto status_list della SLT a 1.

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

12.1.6.2. Assegnazione dell'indice della Key Attestation¶

Secondo R_KA_1 di CIR2026/1731, un Fornitore di Wallet DEVE scegliere una delle seguenti opzioni di assegnazione dell'indice per il claim key_storage_status.status di una KA. L'opzione selezionata determina se l'indice della status list è condiviso dalle KA dello stesso tipo di archiviazione delle chiavi oppure è specifico di una singola KA.

Indice condiviso per tipo. Tutte le KA che attestano chiavi archiviate nello stesso tipo di WSCD o di keystore DEVONO contenere lo stesso valore di indice in key_storage_status.status. Di conseguenza, lo stato rappresentato da quell'indice è condiviso da tutte tali KA.
Indice per Key Attestation. Una KA che attesta chiavi archiviate in un singolo WSCD o keystore DEVE contenere in key_storage_status.status un valore di indice univoco rispetto a ogni altra KA. Di conseguenza, ciascuna KA ha una entry distinta nella status list e il suo stato di revoca può essere gestito in modo indipendente.

Il requisito di valori idx distinti si applica solo all'opzione per Key Attestation. Le KA che usano un indice condiviso per tipo ne sono esenti.

12.1.6.3. Status List Token¶

Il Fornitore di Wallet DEVE agire sia come Status Issuer sia come Status Provider. Il Fornitore di Wallet DEVE pubblicare ciascuna SLT tramite HTTP GET all'URI nel membro client_status.status.status_list.uri della WIA oppure nel membro key_storage_status.status.status_list.uri della KA. 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, il Fornitore di Wallet DEVE firmare la SLT con il Trust Anchor usato per validare le sue Wallet Instance Attestation, come specificato in Revocation Trust Anchors.

12.1.6.4. Considerazioni sulla privacy¶

I Fornitori di Wallet DEVONO aggregare nella stessa Status List le informazioni di stato di più WIA o KA che usano indici per Key Attestation. I Fornitori di Wallet DEVONO pubblicare la SLT allo stesso uri per tali attestazioni. Lo scopo è impedire ai Fornitori di Wallet di tracciare o profilare gli Utenti in base all'uso delle Wallet Unit Attestation. Ove appropriato, ciascuna Status List DOVREBBE contenere circa 10.000 entry, in conformità a EUDI-TS 3 e CIR2026/1731. Questi requisiti di aggregazione e di dimensione non si applicano alle KA che usano un indice condiviso per tipo.

12.1.7. Catalogo e-Service PDND del Fornitore di Wallet¶

La morte dell'Utente porta alla revoca delle Istanze di Wallet dell'Utente e all'eliminazione dell'account dell'Utente presso il Fornitore di Wallet. Per questo motivo, il Fornitore di Wallet fornisce il seguente e-service tramite PDND. Un Provider di PID/IT-Wallet ID che è stato notificato dalla Fonte Autentica del PID/IT-Wallet ID della morte dell'Utente DEVE inviare una notifica ai Fornitori di Wallet utilizzando questo endpoint. Le chiamate al Catalogo e-Service PDND del Fornitore di Wallet, inclusa Notifica Morte Utente, DEVONO essere autenticate e autorizzate. Le richieste non autenticate DEVONO essere rifiutate. Una Notifica Morte Utente andata a buon fine DEVE portare alla revoca dell'Istanza del Wallet come per le altre revoche avviate dal Provider di PID/IT-Wallet ID (WP_161).

Nota

Una Specifica OpenAPI completa è disponibile qui.

12.1.7.1. Notifica Morte Utente¶

Descrizione	Questo servizio viene utilizzato per notificare al Fornitore di Wallet la necessità di revocare l'Istanza di Wallet ed eliminare l'account dell'Utente a causa della morte dell'Utente.
Fornitore	Fornitore di Wallet
Consumatore	Fornitore di Attestati Elettronici di Dati di Identificazione Personale