FROZEN · 2026-08-19
BKO Protocol 1.0
BKO Protocol 1.0 è congelato dal 19 agosto 2026. Le Proof già emesse con il formato bkc-proof-package/1.0 sono valide senza riemissione: il verificatore le risolve sulle regole di BKO 1.0.
Versione: bko/1.0 · formati accettati dal verificatore: bko/1.0bkc-proof-package/1.0
Schema canonico del Proof Package
JSON canonico: chiavi ordinate lessicograficamente a ogni livello, nessuno spazio superfluo, array nell'ordine emesso, timestamp in UTC. L'hash del pacchetto si calcola sulla forma canonica di tutti i campi tranne `hash`.
| Campo | Tipo | Regola |
|---|---|---|
| format | string | Deve essere uno dei formati accettati e determina le regole di verifica. |
| generated_at | ISO-8601 UTC | Istante di emissione del pacchetto, normalizzato in UTC. |
| object | object | uri, name, state, version, current_hash: il CONTEXT su cui tutto poggia. |
| decision | object | id, decided_at, decided_by, choice, reason, chain_hash. |
| stages | array | CONTEXT → EVIDENCE → AI → POLICY → HUMAN → ACTION → OUTCOME → PROOF. |
| workflow | object|null | Percorso operativo con lo stato osservato di ogni passo. |
| reality | object|null | Reality Record: una sola classificazione per elemento. |
| chain | array | Eventi append-only: ogni prev_hash è l'hash della riga precedente. |
| refs | array | Riferimenti ricalcolabili: hash oggetto, hash catena, ultimo evento. |
| hash | hex(64) | SHA-256 della forma canonica del pacchetto senza il campo hash. |
Semantica degli stati
- VERIFIED
- Esiste un fatto in catena con hash ricalcolabile offline.
- Condizione: Un evento presente in `chain` con hash valido e prev_hash coerente.
- OBSERVED
- Il fatto è accaduto ed è stato registrato, ma non è ricalcolabile.
- Condizione: Un riferimento temporale o un evento senza hash utilizzabile per il ricalcolo.
- DECLARED
- È una dichiarazione della configurazione firmata o dell'utente, non un'esecuzione.
- Condizione: Una policy, un ruolo o una capacità dichiarata, senza evento corrispondente.
- NON DETERMINABILE
- Non ci sono fatti sufficienti: Bonketiba non afferma nulla.
- Condizione: Assenza di evento, riferimento e dichiarazione applicabile.
Regole di verifica
- R1 — Il campo `format` è tra i formati accettati; altrimenti la verifica si ferma.
- R2 — Il campo `hash` è esadecimale minuscolo di 64 caratteri.
- R3 — SHA-256 della forma canonica del pacchetto senza `hash` deve dare esattamente `hash`.
- R4 — Ogni evento in `chain` ha un hash esadecimale valido e distinto dagli altri.
- R5 — Per ogni evento successivo al primo, `prev_hash` è l'hash dell'evento precedente.
- R6 — Gli istanti in `chain` non regrediscono: la catena è cronologicamente monotona.
- R7 — `decision.chain_hash` compare tra i riferimenti dichiarati in `refs`.
- R8 — Ogni classe del Reality Record appartiene al vocabolario dei quattro stati.
- R9 — I conteggi del Reality Record coincidono con il ricalcolo elemento per elemento.
- R10 — L'esito `passed` è ricalcolato dalle regole: nessun NON DETERMINABILE, verifica offline VERIFIED, azione non solo DECLARED.
Revoche
Una prova non si cancella: si revoca. Il pacchetto resta verificabile, il verdetto diventa REVOKED e la ragione è parte del registro.
- VALID — Tutte le regole di verifica passano e nessuna revoca è registrata.
- REVOKED — Il pacchetto è integro ma l'emittente ha revocato la prova: non usarla come evidenza.
- NOT_VERIFIED — Almeno una regola di verifica fallisce: hash, catena o vocabolario non tornano.
La revoca è l'unico controllo che richiede una lista di revoca: offline, senza quella lista, il verdetto massimo esprimibile è VALID (non revocato per quanto noto).
Gestione delle chiavi
- Ogni firma dichiara il proprio `key_id`: la verifica risolve la chiave dichiarata, non quella corrente.
- Le chiavi ritirate restano pubblicate con stato `retired`: le prove firmate prima del ritiro restano verificabili.
- L'algoritmo è ECDSA P-256 (IEEE P1363) su SHA-256; l'integrità di catena e pacchetto usa SHA-256 puro.
- Il Proof Package BKO è verificabile senza chiavi: hash e catena bastano. La firma aggiunge l'autenticità dell'emittente.
- Cambiare algoritmo o curva richiede una nuova versione di protocollo: BKO 1.0 resta congelato.
Richiede una nuova versione
- Modifica dello schema canonico o del significato di un campo
- Modifica della canonicalizzazione usata per gli hash
- Modifica delle regole di verifica o del loro ordine
- Modifica della semantica di uno dei quattro stati
- Modifica del calcolo dell'esito del Reality Test
Non tocca la verifica
- Rotazione delle chiavi con key_id risolvibile
- Nuove etichette, traduzioni e modifiche di interfaccia
- Campi additivi ignorati dai verificatori conformi a 1.0
- Nuovi report derivati da dati già firmati