Firma elettronica semplice difendibile (eIDAS)¶

Questa piattaforma implementa e documenta un flusso di firma elettronica semplice (SES) con prova tecnica forte, adatto a processi AML/CFT dove conta soprattutto la difendibilità probatoria del processo.

Non viene presentata come:

firma qualificata;
servizio QTSP;
sostituto universale di ogni forma di firma richiesta da leggi speciali.

Viene invece presentata correttamente come:

firma elettronica ai sensi della definizione generale eIDAS;
SES evidence-based, cioè una firma semplice sostenuta da una catena di prova molto più ricca della media;
base tecnica e documentale difendibile in audit, contenzioso e controlli interni.

Inquadramento giuridico corretto¶

Il perimetro normativo corretto è questo:

l'articolo 3 eIDAS definisce la firma elettronica in termini ampi come dati elettronici collegati ad altri dati elettronici e usati per firmare;
l'articolo 25 eIDAS stabilisce che una firma elettronica non può essere privata di effetti giuridici o di ammissibilità come prova solo perché è elettronica o non qualificata;
solo la firma qualificata gode in tutta l'Unione dell'equivalenza espressa alla firma autografa.

Questa documentazione quindi non promette ciò che il sistema non promette nel codice:

non dichiara QES;
non dichiara firma qualificata;
non usa impropriamente il linguaggio della firma digitale certificata.

Per RIV Digital il punto corretto è un altro: costruire un fascio probatorio forte, coerente, verificabile e spiegabile attorno a ogni atto di firma AML.

Fonti ufficiali di riferimento¶

Cosa rende difendibile questo flusso¶

Una SES è tanto più difendibile quanto più il sistema sa dimostrare cinque cose:

chi ha firmato;
cosa ha firmato;
con quale intenzione ha firmato;
con quale controllo aggiuntivo ha confermato l'atto;
come la prova è stata conservata e resa verificabile nel tempo.

Nel flusso reale di dwh + GoeSign + walt.id, queste cinque domande ricevono una risposta concreta:

Domanda	Prova tecnica reale
Chi ha firmato?	`signer_ref`, snapshot identità, VC verificata, ruolo e tenant
Cosa ha firmato?	hash documento, `document_id`, `version_id`, target business
Intenzione?	presentazione documento, key terms, intent text, slide-to-sign
Controllo aggiuntivo?	challenge WebAuthn/passkey quando la policy lo richiede
Conservazione?	evidence envelope, notarization receipt, archive bundle, verification

Sequenza reale del sistema¶

sequenceDiagram
    participant User as Firmatario
    participant DWH as dwh
    participant SSI as walt.id
    participant GS as GoeSign
    participant WORM as Archive

    DWH->>SSI: issue / verify VC minima
    User->>DWH: apre azione regolatoria
    DWH->>GS: crea ceremony con policy
    GS-->>DWH: sessione con intent level e step_up_required
    User->>DWH: review documento + key terms + intent text
    alt policy con step-up
        DWH->>GS: challenge/begin
        User->>GS: passkey/WebAuthn assertion
        GS-->>DWH: challenge/verify = ok
    end
    User->>DWH: slide-to-sign
    DWH->>SSI: verifica identità di firma / VC
    DWH->>GS: sign
    GS->>GS: intent proof + evidence envelope
    GS->>GS: notarize
    GS->>WORM: archive bundle
    GS-->>DWH: receipt verificabile
    DWH->>DWH: sig_record + ssi_signing_evidence + ledger

Come si estende alla firma massiva¶

Nel ramo massive signing la struttura probatoria cambia oggetto, non livello di rigore.

La domanda non è più soltanto:

“chi ha firmato questo documento?”

Diventa:

“chi ha autorizzato questo motore a firmare in serie, con quale scope, con quale controllo forte e con quali limiti?”

La risposta corretta è:

il soggetto umano attiva un mandato con ceremony GoeSign e passkey;
il mandato viene notarizzato e archiviato;
dwh emette una AmlSigningMandateCredential;
il batch porta nel proprio manifest i riferimenti al mandato attivato;
il sigillo batch prova l’esecuzione tecnica del sistema autorizzato, non una nuova firma umana per ogni file.

Sequenza sintetica del ramo massive¶

sequenceDiagram
    participant Human as Firmatario umano
    participant DWH as dwh
    participant GS as GoeSign
    participant Batch as dwh-batch-engine
    participant WORM as Archive

    Human->>DWH: crea mandato
    DWH->>GS: activation/start
    Human->>GS: challenge passkey + slide-to-sign
    GS->>WORM: archive mandate bundle
    DWH->>Batch: autorizza uso mandate attivo
    Batch->>GS: create -> seal -> notarize -> archive batch

Cosa deve restare vero¶

l’atto umano resta l’activation del mandato;
il batch resta un’esecuzione tecnica sotto mandato;
il manifest batch deve sempre consentire di risalire a mandate_payload_hash, mandate_intent_proof_id, mandate_archive_record_id, mandate_activation_session_id;
nessun testo UI deve suggerire che ogni file del batch sia stato firmato manualmente.

I componenti del fascio probatorio¶

1. eKYC ed evidenze di onboarding¶

Il sistema conserva:

i dati raccolti durante onboarding/eKYC;
i documenti caricati;
gli hash dei documenti;
gli esiti di verifica;
i riferimenti di caso e dossier.

Questa parte non è “la firma”, ma è la base che collega la firma a un'identità AML verificata.

2. Verifiable credential minima¶

La VC non sostituisce la ceremony. Serve a dimostrare che:

il soggetto è stato verificato;
appartiene a un tenant preciso;
ha un ruolo o uno scope di firma;
la credenziale è attiva e non revocata.

La VC viene usata come rail di identità portabile e verificabile, non come promessa di firma qualificata.

3. Ceremony GoeSign¶

La ceremony fornisce il cuore dell'intenzionalità:

presentazione documento;
key terms;
intent text versionato;
gesto deliberato finale;
challenge passkey quando richiesta.

Questa parte è essenziale perché in contenzioso la domanda non è solo “chi era l'utente”, ma anche “ha davvero espresso volontà di firmare questo contenuto?”.

4. Passkey binding¶

Quando la policy lo richiede, la passkey non è un badge grafico ma un fatto runtime verificato:

challenge browser-side reale;
verifica server-side reale;
sessione che passa a challenged;
proof_id collegato all'evidenza finale;
stepup_verified_at persistito.

Questo rende il controllo forte parte della firma, non un prerequisito astratto.

5. Notarizzazione e archiviazione¶

Dopo la firma:

viene costruito l'evidence envelope;
viene prodotto o collegato un receipt di notarizzazione;
viene creato un bundle archiviabile e verificabile;
il bundle viene conservato con logica WORM/immutabile dove configurata.

Questa è la parte che rende la prova duratura, non solo valida nel momento della UI.

Cosa il sistema afferma, e cosa non afferma¶

Il sistema afferma correttamente¶

che esiste una firma elettronica;
che l'atto è legato a una identità AML verificata;
che la ceremony è ricostruibile;
che l'integrità del contenuto è verificabile;
che la cronologia tecnica è ricostruibile;
che la prova è archiviata e riesaminabile.

Il sistema non afferma¶

che ogni firma sia automaticamente equivalente alla firma autografa;
che il sistema sia un QTSP;
che il wallet SSI da solo basti a creare una firma qualificata;
che la presenza di una passkey trasformi da sola una SES in QES o in altra categoria superiore.

Questa distinzione è fondamentale per un audit serio.

Regole di verità del prodotto¶

Per restare difendibile, il prodotto deve rispettare sempre queste regole:

nessun bypass se una policy richiede VC o step-up;
nessun testo UI che faccia credere a una firma qualificata quando non esiste;
nessun badge verde senza verifica reale;
nessun log solo locale privo di riferimento al bundle verificabile;
nessuna perdita di evidenza al restart dello stack demo o runtime.

Il sistema deve separare correttamente due concetti:

il principio GDPR di storage limitation, secondo cui i dati non vanno tenuti oltre il necessario;
l'obbligo AML del titolare di conservare certe evidenze per il periodo imposto dalla normativa applicabile e dalle policy aziendali.

Per questo la documentazione di piattaforma usa la formulazione corretta:

la retention lunga non è “libera”;
è giustificata quando esiste una base giuridica di obbligo normativo AML/CFT o altra base legittima documentata;
la privacy notice deve dichiarare chiaramente finalità, base giuridica e periodo di conservazione.

Nel contesto RIV Digital la documentazione di riferimento prevede:

evidenze AML e di firma conservate fino a 10 anni quando il programma AML del cliente lo richiede;
claim minimizzati nelle VC;
bundle e ledger conservati con politiche separate dal dato operativo corrente.

Checklist per audit interno e AgID¶

Un audit serio su questo flusso dovrebbe poter verificare:

sessione GoeSign e policy usata;
documento/versione/hash firmati;
testo intenzionale mostrato all'utente;
se il ramo era singolo o massive sotto mandato;
quale activation session ha reso usabile il mandato;
quale VC di mandato era attiva;
quale manifest batch collega l’esecuzione al mandato;
esito step_up_required e, se applicabile, evento STEP_UP_CHALLENGE_PASSED;
esito verifica SSI / VC;
sig_record e ssi_signing_evidence;
receipt di notarizzazione;
archive bundle e verifica bundle;
retention policy applicata;
copy UI coerente con il ramo SES.

Pagine da conoscere¶

Area	Pagina
Stato personale firma	`/profilo/identita-firma`
Inventario credenziali	`/profilo/credenziali`
Firme in attesa	`/firme/pending`
Receipt / bundle	`/goesign/receipt/:id`
Normativa e testi legali	`/normativa`
Evidenze / ledger	`/logs/ledger`, `/logs/export`

Sintesi finale¶

Il valore del sistema non è “simulare una firma forte”.

Il valore del sistema è:

mantenere una classificazione giuridica onesta;
raccogliere una catena di prova molto solida;
permettere a un revisore terzo di verificare il nesso fra identità, intenzione, contenuto, controllo forte e conservazione.

Questo è il significato corretto di SES difendibile nella piattaforma RIV Digital.