Vai al contenuto

Firme massive sotto mandato

La firma massiva in dwh non è una scorciatoia per evitare la firma umana. È un modello preciso:

  • un soggetto umano autorizzato attiva un mandato con ceremony GoeSign e passkey;
  • il mandato autorizza un solo motore batch reale, oggi dwh-batch-engine;
  • il motore batch crea, sigilla, notarizza e archivia i pacchetti documentali entro scope e limiti del mandato;
  • ogni batch resta verificabile perché il manifest porta con sé la lineage del mandato.

Questa è la differenza sostanziale fra:

  • firma umana singola: l’utente firma direttamente il singolo pacchetto;
  • firma massiva: l’utente firma il potere di esecuzione e il sistema esegue sotto quel potere.

Cosa viene firmato davvero

Nel ramo massive signing il gesto umano giuridicamente rilevante è l’attivazione del mandato.

Quell’atto produce una catena completa:

  • payload canonico del mandato;
  • sessione GoeSign dedicata;
  • challenge WebAuthn/passkey;
  • intent_proof;
  • receipt di notarizzazione;
  • archive record del mandato.

Il batch successivo non è una “nuova firma umana silenziosa”. È una esecuzione tecnica sigillata sotto un mandato già attivato.

Questa distinzione va mantenuta sempre in audit, UX e contenzioso.

Posizionamento giuridico corretto

Questo flusso va raccontato come:

  • firma elettronica semplice con prova forte;
  • modello evidence-based coerente con eIDAS;
  • flusso difendibile perché ricostruisce identità, intenzione, scope, controlli, integrità e conservazione.

Non va raccontato come:

  • firma qualificata;
  • QTSP;
  • equivalente automatico a firma autografa in ogni contesto.

La base giuridica resta la stessa del ramo singolo:

  • articolo 3 eIDAS: definizione ampia di firma elettronica;
  • articolo 25 eIDAS: non si può negare effetto giuridico o ammissibilità probatoria solo perché la firma è elettronica o non qualificata.

La forza del ramo massive signing deriva dalla catena di prova, non da un claim più forte della realtà runtime.

Dove si usa nell'app

Funzione Pagina
Workbench firme regolatorie /firme/pending
Console firme massive /firme/massive/
Identità di firma e passkey /profilo/identita-firma
Credenziali eID + learning + mandato /profilo/credenziali
Receipt mandate activation /goesign/receipt/:session_id

I ruoli che operano direttamente oggi sono:

  • RFA
  • RSOS
  • SUPERADMIN

Altri ruoli di governance possono avere visibilità o supervisione, ma non devono usare questo flusso come entrypoint quotidiano se non richiesto dal modello operativo del tenant.

Sequenza runtime reale

sequenceDiagram
    participant Human as RFA / RSOS
    participant DWH as dwh
    participant GS as GoeSign
    participant SSI as walt.id
    participant Batch as dwh-batch-engine
    participant WORM as Archive

    Human->>DWH: apre /firme/massive
    DWH->>GS: POST /mandates
    DWH->>GS: POST /mandates/:id/activation/start
    GS-->>DWH: activation_session_id
    Human->>DWH: ceremony + slide-to-sign
    DWH->>GS: challenge/begin -> challenge/verify -> sign -> notarize -> archive
    DWH->>GS: POST /mandates/:id/activate
    DWH->>SSI: issue AmlSigningMandateCredential
    Batch->>GS: POST /batches
    Batch->>GS: POST /batches/:id/seal
    Batch->>GS: POST /batches/:id/notarize
    Batch->>GS: POST /batches/:id/archive
    GS->>WORM: archive bundle

Catena di evidenza che rende il batch difendibile

Il BatchManifest reale include i campi che legano il batch al mandato attivato:

  • mandate_id
  • mandate_payload_hash
  • mandate_intent_proof_id
  • mandate_archive_record_id
  • mandate_activation_session_id
  • created_by
  • created_at
  • items

Questo consente di rispondere in modo verificabile a cinque domande:

Domanda Dove si trova la prova
Chi ha autorizzato l’automazione? issuer_ref, issuer_role, credential e sessione di activation
Con quale gesto intenzionale? activation session GoeSign con passkey e intent_proof_id
Con quale scope? scope del mandato e authorized_system_identity
Quale sistema ha eseguito davvero il batch? created_by_system_identity + seal artifact
Come si prova integrità e conservazione? manifest_hash, seal_artifact, notarize_receipt_id, archive_record_id, bundle archivistico

Invarianti di verità del prodotto

Il flusso massive resta difendibile solo se queste invarianti restano vere:

  1. nessun batch parte senza mandato active e activation_verified=true;
  2. il sistema autorizzato è quello fissato dalla piattaforma, oggi dwh-batch-engine;
  3. scope e controlli del mandato vengono verificati sui documenti;
  4. la policy passkey resta dentro la ceremony di activation, non come badge esterno;
  5. il batch non viene raccontato come nuova firma umana per ciascun documento;
  6. la UI e i docs distinguono sempre fra atto umano di delega e esecuzione tecnica sigillata.

Cosa deve capire un auditor

Un auditor serio deve poter ricostruire in ordine:

  1. chi ha creato il mandato;
  2. quale payload del mandato è stato effettivamente firmato;
  3. quale passkey/credential è stata usata nell’activation;
  4. quale VC di mandato è stata emessa dopo la verifica;
  5. quali batch sono stati creati sotto quel mandato;
  6. quale manifest e quale seal artifact corrispondono al batch contestato;
  7. quale archive record rende la prova riesaminabile nel tempo.

Se questa catena è ricostruibile, la firma massiva è tecnicamente e probatoriamente difendibile allo stesso livello del ramo singolo, pur restando nel perimetro SES.