T0: ricevuta immediata e firma dell’attestazione#

T0 è il primo livello di prova. Viene prodotto sincronicamente quando CertiSigma accetta l’hash e crea o ritrova l’attestazione. La ricevuta contiene almeno hash, identificativo, timestamp applicativo, versione del formato, identificativo della chiave e firma ECDSA P-256.

T0 risponde alla domanda: il sistema di attestazione ha registrato e firmato questo hash in questo momento applicativo? Non equivale a un timestamp qualificato e non implica un’ancora su blockchain pubblica.

Verifica#

La firma si verifica con la chiave pubblica associata al key_id. Il verificatore deve ricostruire esattamente il payload firmato secondo la versione del formato, calcolarne il digest e verificare la firma ECDSA. Non basta confrontare l’attestation ID o leggere una pagina web.

ricevuta T0
+ chiave pubblica corretta
+ formato canonico della firma
→ verifica ECDSA

Le chiavi pubbliche possono ruotare. L’evidence bundle deve quindi conservare il riferimento della chiave utilizzata e la verifica deve ottenere la chiave storica corretta, non soltanto quella attiva al momento del controllo.

Uso in CertiExch#

T0 viene associato immediatamente a eventi come:

cristallizzazione di un dossier;
pubblicazione di una versione;
accettazione di un’offerta;
conferma di settlement;
record date;
rettifica;
chiusura di un lotto;
export di continuità.

La disponibilità immediata consente al workflow di proseguire senza attendere il batch T1. La policy dello strumento o dell’infrastruttura può tuttavia richiedere T1 prima di una comunicazione esterna o di una determinata decisione.

Limiti#

T0 dipende dalla chiave e dall’orologio del servizio di attestazione. Offre autenticità e integrità della ricevuta, ma non la stessa indipendenza temporale di una TSA qualificata o di un’ancora pubblica. Deve essere descritto come livello immediato, non come “prova assoluta sulla blockchain”.

Controlli operativi#

Un errore di attestazione T0 va gestito secondo la criticità dell’evento. Il sistema deve evitare di inventare una ricevuta locale equivalente. Gli eventi che richiedono attestazione fail-closed restano in attesa o passano a manual_review; gli eventi ammessi in modalità degradata devono essere marcati esplicitamente e riallineati appena il provider torna disponibile.