Il 29 aprile 2026 la Commissione europea ha pubblicato il progetto di regolamento di esecuzione relativo al registro DPP e ha avviato contemporaneamente un periodo di consultazione di quattro settimane. Fino al 27 maggio 2026, ogni persona e ogni organizzazione nell’UE e al di fuori di essa può inviare i propri commenti tramite il portale «Have Your Say». I contributi sono pubblici, ciascuno è firmato con il nome o l’organizzazione, e confluiscono ufficialmente nella versione finale del regolamento.
Abbiamo discusso la bozza in modo approfondito qui sul blog. Dedichiamo questo articolo a illustrare cosa abbiamo risposto alla Commissione.
Perché abbiamo presentato quattro contributi separati
Il portale accetta 4 000 caratteri per ogni contributo. Avremmo potuto condensare tutti i punti in un unico lungo contributo. Ciò avrebbe reso la lettura più scomoda e la citazione più difficile per i collaboratori della Commissione, che a maggio dovranno esaminare decine di contributi. Quattro contributi separati sono individuabili singolarmente nell’elenco pubblico e ciascuno può ricevere una risposta - o essere respinto - in modo isolato, senza influenzare gli altri punti.
Abbiamo presentato i seguenti quattro argomenti:
1. Definire i requisiti minimi per i fornitori di servizi DPP
Il progetto di regolamento definisce correttamente il modello decentralizzato: I dati DPP risiedono presso l’operatore economico o presso il suo fornitore di servizi DPP; il registro della Commissione memorizza solo i riferimenti. Per i fornitori di servizi DPP (art. 2 n. 32 dell’ESPR) è previsto un elenco ufficiale dei fornitori autorizzati.
Ciò che manca è una definizione di ciò che un fornitore di servizi deve effettivamente garantire per essere inserito in tale elenco e rimanervi. Presumibilmente, gli obblighi sostanziali saranno disciplinati in un atto delegato ai sensi dell’articolo 4 del regolamento quadro ESPR. Il registro entrerà tuttavia in funzione prima che tale atto sia pubblicato.
La nostra proposta: stabilire direttamente nel presente regolamento di esecuzione i criteri minimi per i fornitori di servizi oppure indicare un termine vincolante entro il quale dovrà essere presentato l’atto delegato. Tra i requisiti minimi proposti figurano:
- Disponibilità dell’interfaccia pubblica di lettura del DPP pari ad almeno il 99,5% al mese
- Un accordo sul livello di servizio (SLA) che definisca la tempistica entro cui una nuova versione del DPP deve essere integrata nel backup di sicurezza (proposta: 24 ore o in tempo reale, ove tecnicamente possibile)
- Verifica crittografica obbligatoria delle versioni in entrata da parte del fornitore di servizi
- Pubblicazione delle chiavi pubbliche dell’operatore economico secondo un percorso standardizzato (RFC 8615, proposta
/.well-known/dpp-keys/) - Processo definito di cambio fornitore e di insolvenza, affinché i dati DPP possano essere migrati in modo ordinato verso un altro fornitore in caso di inadempienza di un fornitore
Questi obblighi non comportano alcun costo per un fornitore serio - che li adempie comunque -, ma impediscono una corsa al ribasso tra fornitori a basso costo che finirebbe per compromettere l’integrità dell’elenco.
2. Verificabilità a lungo termine dei DPP registrati
L’articolo 9, paragrafo 4, limita la disponibilità dell’attestato di registrazione a 90 giorni di calendario. Entro tale termine, il registro rigenera l’attestato su richiesta. Ciò va bene per la gestione corrente, ma non è in linea con il ciclo di vita dell’obbligo relativo ai DPP sottostante: l’articolo 10, paragrafo 3, fissa la conservazione standard a 10 anni dalla registrazione, mentre la normativa settoriale può richiedere un periodo più lungo.
Un’autorità di vigilanza del mercato, un funzionario doganale, un operatore del riciclaggio o un ricercatore nel 2032 dovrebbe poter verificare che un DPP registrato nel 2026 fosse effettivamente registrato, senza dover fare affidamento sul fatto che l’operatore economico originario esista ancora e possa richiedere un nuovo certificato.
Le nostre due proposte sono di facile attuazione:
- Chiarire esplicitamente che i byte di prova contrassegnati con un sigillo qualificato dalla Commissione possono essere memorizzati temporaneamente, archiviati e ridistribuiti dall’operatore economico o dal fornitore di servizi. Il sigillo qualificato ai sensi dell’articolo 35, paragrafo 2, del regolamento eIDAS garantisce la presunzione di integrità e origine indipendentemente da dove si trovino i byte.
- Un endpoint di verifica pubblico e non autenticato presso il registro, che fornisca una risposta firmata in relazione a un ID di registrazione. Attualmente, ogni verifica da parte di terzi presuppone che l’operatore economico intervenga attivamente: questa è la forma sbagliata per un documento probatorio che deve sopravvivere al suo emittente.
Inoltre, abbiamo proposto di definire in modo deterministico la generazione dell’hash: SHA-256 come funzione hash, JSON Canonicalization Scheme (RFC 8785) come serializzazione, al di fuori del blocco della firma. Nell’ecosistema W3C questa famiglia è denominata eddsa-jcs-2022; Transpareo utilizza la variante strettamente correlata eddsa-jcs-sha256 (SHA-256 tramite JCS). Senza questa specifica di pinning, due fornitori di servizi serializzerebbero lo stesso DPP con hash diversi e il campo hash nella prova di registrazione non sarebbe riproducibile.
3. L’articolo 17 non deve limitare l’accesso ai dati DPP pubblici
L’articolo 17 cita il «download massiccio di dati» come possibile abuso del registro. Ciò è corretto per i metadati amministrativi presenti nel registro stesso (identità, log, tracce di audit): questi non devono essere oggetto di download di massa.
I dati DPP pubblici presso il produttore o il fornitore di servizi sono però proprio l’ambito che l’ESPR intende rendere ampiamente accessibile. I riciclatori che estraggono dati composizionali sulle flotte di prodotti; la ricerca che analizza trasversalmente le dichiarazioni di sostenibilità; la vigilanza del mercato che effettua analisi comparative: si tratta in tutti questi casi di forme di «download massivo di dati» dal livello pubblico dei DPP e di utilizzi mirati, proprio per i quali è stato redatto il regolamento.
La nostra proposta è una frase chiarificatrice nell’articolo 17 che limiti l’ambito di applicazione ai dati dei registri e, per i dati DPP, rimandi ai rispettivi atti delegati specifici per settore. Altrimenti, al momento del lancio, i fornitori di servizi si troveranno di fronte a una scelta: o limitare in modo restrittivo l’accesso pubblico per motivi di sicurezza - compromettendo così l’esperienza dei consumatori - oppure lasciarlo aperto e rischiare che in seguito venga classificato come abuso ai sensi dell’articolo 17.
4. Pubblicare la specifica OpenAPI e la sandbox prima del lancio
L’articolo 3, lettera b), richiede un’API per le registrazioni. L’articolo 8, paragrafo 5, la definisce come uno dei due canali per la registrazione. Il regolamento, tuttavia, non specifica quando debba essere pubblicato il contratto API.
Chi automatizza i flussi di lavoro di registrazione - ogni fornitore di servizi e ogni operatore economico con un catalogo di dimensioni considerevoli - ha bisogno della specifica API con largo anticipo rispetto al lancio, per poterla implementare e testarla su un endpoint reale. Trovare una specifica nella settimana precedente l’entrata in vigore trasferisce il rischio di integrazione a tutti i fornitori dell’ecosistema.
Abbiamo quindi proposto:
- Di pubblicare una specifica OpenAPI 3.1 almeno otto settimane prima dell’entrata in vigore - per un avvio previsto il 19 luglio 2026, quindi entro il 24 maggio 2026
- Un ambiente sandbox parallelo, in cui i fornitori di servizi e i produttori possano integrare le proprie soluzioni e testare l’autoverifica ai sensi dell’articolo 8, paragrafo 6
- Una politica di versioning basata su Semver, con un periodo di preavviso di almeno 18 mesi
Ulteriori suggerimenti di progettazione: chiavi idempotenti nelle chiamate di registrazione, registrazione in batch per cataloghi di grandi dimensioni, registrazione asincrona con callback via webhook e codici di errore leggibili da macchina per i casi di errore nella verifica automatica.
Perché lo facciamo
Una consultazione non è un gioco per accumulare punti. Se ogni contributo riesce a rendere più precisa una singola frase nella versione finale, ha raggiunto il suo scopo. La Commissione legge effettivamente questi contributi: l’esperienza maturata nel processo ESPR stesso dimostra che i contributi tecnicamente fondati spesso lasciano traccia nei testi finali.
Ci candideremo comunque per l’inserimento nell’elenco dei fornitori di servizi DPP non appena sarà pubblicata la procedura di ammissione. È quindi nel nostro diretto interesse che le regole in base alle quali ci presentiamo siano precise e definiscano condizioni di parità. I quattro contributi sono il nostro modo concreto per garantire che l’elenco non si riduca a un mero marchio di marketing.
Chi vuole partecipare
Il periodo per inviare feedback è aperto fino al 27 maggio 2026. I contributi possono essere redatti in qualsiasi lingua ufficiale dell’UE, richiedono la registrazione sul portale e saranno visibili pubblicamente. Chi emetterà o verificherà i DPP - produttori, fornitori di servizi, aziende di riciclaggio, autorità - dovrebbe dare almeno un’occhiata all’iniziativa su Have Your Say. Anche un contributo breve ma tecnicamente preciso è utile.
Il nostro strumento di verifica Transpareo Time Machine , tra l’altro, soddisfa già nella pratica open source l’esigenza di verifica accennata al punto 2: chi desidera verificare in modo indipendente un DPP di Transpareo può farlo già oggi con questo strumento, senza dover attendere un punto di verifica formalmente stabilito nel registro della Commissione.