CertiSigma e livelli T0/T1/T2#

CertiSigma riceve commitment crittografici degli eventi e restituisce evidenze progressivamente più forti. Il provider non decide la validità economica dell’operazione e non sostituisce il registro: prova che un determinato hash è stato acquisito e, nei livelli successivi, marcato o ancorato.

I tre livelli#

Livello	Funzione	Cosa non dimostra da solo
T0	Ricevuta immediata del commitment e firma del provider/enclave.	Titolarità, pagamento o correttezza economica dell’evento.
T1	Marca temporale qualificata o evidenza temporale prevista dalla policy.	Che l’operazione sia stata regolata.
T2	Ancora indipendente opzionale, normalmente tramite batch/Merkle root e rete pubblica.	Che il contenuto non hashato sia autentico o giuridicamente efficace.

La prova deve sempre essere letta insieme all’evento, al suo hash, al Master Record e alle ricevute dei sistemi che hanno prodotto l’effetto.

Dati inviati#

L’adattatore invia almeno:

hash_hex
source
extra_data
request_id

L’hash deve essere uno SHA-256 esadecimale di 64 caratteri. Documenti e payload integrali non devono essere inviati se il contratto richiede soltanto il commitment.

Provider simulato#

Il provider simulato:

crea T0 localmente;
consente di avanzare artificialmente a T1 e T2;
produce riferimenti e firme dimostrative;
memorizza gli oggetti nello store del simulatore;
riusa l’attestazione esistente per lo stesso hash.

Il riferimento a Bitcoin prodotto nel T2 simulato è espressamente dimostrativo e non deve essere presentato come transazione pubblicata realmente.

Provider HTTP dell’enclave#

Il provider reale usa:

endpoint HTTPS;
bearer token;
verifica TLS e hostname;
request ID propagato;
timeout configurato;
risposta JSON validata.

In pre-produzione e produzione, endpoint non HTTPS o credenziale mancante impediscono l’uso del provider.

Polling e webhook#

Il sistema può acquisire gli avanzamenti tramite polling o webhook. In entrambi i casi bisogna verificare:

identificativo dell’attestazione;
hash;
livello precedente e nuovo livello;
firma/autenticazione del messaggio;
non regressione del livello;
non duplicazione dell’evento;
timestamp;
eventuale prova di inclusione nel batch.

Un webhook non verificato deve essere ignorato e registrato come evento di sicurezza.

Batching e prova di inclusione#

Quando più commitment sono aggregati, T2 può riferirsi a una Merkle root. Il proof package deve consentire di dimostrare:

hash dell’evento
+ percorso Merkle
+ root del batch
+ riferimento dell’ancora
= inclusione verificabile

La sola root non permette di verificare un evento senza il percorso di inclusione.

Stati operativi#

Gli stati applicativi possono includere:

richiesta creata;
T0 acquisito;
T1 pending;
T1 acquisito;
T2 non richiesto;
T2 pending;
T2 acquisito;
provider indisponibile;
prova incoerente;
sincronizzazione richiesta.

Non degradare automaticamente un evento economico già valido perché T2 è in ritardo, salvo che la policy dello strumento renda quel livello condizione necessaria. T0, T1 e T2 hanno finalità probatoria, non sono sinonimi degli stati di settlement.

Gestione delle anomalie#

Anomalia	Azione
Hash restituito diverso	Rigettare la prova e aprire incidente.
Identificativo sconosciuto	Non collegarlo a un evento esistente.
T1/T2 duplicato	Trattare idempotentemente e verificare contenuto.
Livello regressivo	Non sovrascrivere il livello più forte; investigare.
Provider offline	Conservare T0/pending e applicare la policy di retry.
Risposta non JSON o HTTP non 2xx	Nessun avanzamento; registrare errore tecnico.

Qualificazione del servizio#

Prima del pilot reale verificare:

soggetto che opera l’enclave;
QTSP e servizio qualificato utilizzato per T1;
validità delle catene di certificazione;
policy di batching;
tempi massimi T0/T1/T2;
failover fra provider;
gestione delle chiavi;
conservazione delle ricevute;
prova di inclusione e verifica indipendente;
SLA, incidenti e continuità.