2026-06-17 · 8 min di lettura · Tutti gli articoli

Come dpp.gs si Allinea ai Nuovi Standard EU per DPP (EN 18216, 18219–18223, 18239, 18246)

Per due anni il Digital Product Passport è stato definito solo dalla normativa — l'ESPR stabiliva che un passaporto dovesse esistere, ma non quale forma dovesse avere. Quel vuoto si è colmato nel maggio 2026, quando il comitato tecnico CEN/CENELEC JTC 24 ha pubblicato i primi standard europei per i DPP: la serie EN 18216, 18219–18223, 18239, 18246. Questo articolo mappa dpp.gs su ciascuno di essi, in modo semplice, così puoi vedere esattamente dove la piattaforma è conforme oggi.

La serie EN 18216, 18219–18223, 18239, 18246 in sintesi

JTC 24 ha suddiviso il problema in livelli. Ogni standard regola un aspetto specifico, e un passaporto conforme deve rispondere a tutti:

1. Identità e portatori: GS1 Digital Link (EN 18219 / EN 18220)

Tutto parte dall'identificatore. dpp.gs non inventa mai un ID di prodotto proprietario — usa il GTIN che già possiedi, espresso come GS1 Digital Link. Questa singola scelta soddisfa due standard contemporaneamente: il livello degli identificatori (EN 18219) e il livello dei portatori di dati (EN 18220), perché un Digital Link è progettato per essere contenuto sia in un QR code per consumatori che in un GS1 DataMatrix. Lo stesso codice che uno shopper scansiona in un negozio è il codice che uno scanner doganale legge al confine. Non c'è un secondo sistema di identità da riconciliare.

2. Recupero e ricerca: un URL, molti formati (EN 18216 / EN 18222)

EN 18216 riguarda come viene recuperato un passaporto, ed EN 18222 riguarda come i passaporti vengono trovati e come viene interrogato il loro ciclo di vita. dpp.gs risponde a entrambi dallo stesso punto:

• Recupero — GET /dpp/v1/passports/{GTIN} restituisce il passaporto completo come JSON-LD (o JSON semplice). L'URL del visualizzatore pubblico fa lo stesso tramite negoziazione del contenuto: richiedi application/ld+json e ottieni dati, non una pagina web.
• Ricerca — GET /dpp/v1/passports?sector=textile&operator=… consente a qualsiasi sistema autorizzato di scoprire passaporti per identificatore di prodotto, operatore economico, codice merceologico (HS), settore o stato di registrazione, con paginazione.
• Ciclo di vita — GET /dpp/v1/passports/{GTIN}/lifecycle riporta lo stato di registrazione e le date chiave, così un sistema a valle sa se un passaporto è attivo, in attesa o ritirato.

Le operazioni di scrittura (creazione, aggiornamento, ritiro) rimangono dietro API tenant autenticate — la superficie pubblica è solo lettura e ricerca, che è esattamente l'asimmetria che gli standard presuppongono.

3. Un modello di dati semantico, non un dump di form (EN 18223)

L'interoperabilità fallisce nel momento in cui due sistemi non concordano sul significato di un campo. EN 18223 spinge verso i linked data, e dpp.gs serve ogni passaporto come JSON-LD: un grafo schema.org Product, esteso con il vocabolario GS1 e un namespace dpp: per gli aspetti specifici del passaporto (materiali, sostanze preoccupanti, dati di settore). Il @context è strutturato in modo da poter essere successivamente reindirizzato all'ontologia trasversale CIRPASS senza cambiare la struttura dei dati. Materiali, sostanze e contenuto riciclato sono modellati come elementi condivisi riutilizzati da ciascuno dei 14 settori merceologici — così lo strumento di un riciclatore legge "cobalto, 12%, SVHC: no" allo stesso modo, sia che il prodotto sia una batteria o un giocattolo.

4. Fiducia: Verifiable Credentials firmati (prEN 18246)

Lo standard di autenticazione bozza pone una domanda difficile: come fa un riciclatore, un funzionario doganale o un consumatore a sapere che un passaporto è autentico e non alterato? dpp.gs risponde con crittografia aperta piuttosto che con un registro. Qualsiasi passaporto può essere emesso come Verifiable Credential W3C, firmato con una chiave Ed25519 come vc+jwt compatto (la rappresentazione VC-JOSE-COSE). Chiunque può recuperare la chiave pubblica dell'emittente da /.well-known/jwks.json e verificare la firma offline — dimostrando sia chi ha emesso il passaporto sia che non un byte è stato modificato. Nessuna blockchain, nessun intermediario di fiducia centrale, nessuna dipendenza da un fornitore. (Vedi perché abbiamo scelto gli standard aperti rispetto alla blockchain.)

5. Disponibilità al registro (ESPR Art. 12–13)

Insieme alla serie EN, l'ESPR impone un Registro EU DPP centrale che registra un piccolo insieme di identificatori obbligatori per ogni passaporto. dpp.gs acquisisce già questi campi per ogni prodotto e li tiene pronti per inviarli nel momento in cui l'endpoint del registro della Commissione sarà attivo. Quando arriverà quel giorno, la registrazione sarà un'impostazione di configurazione, non una migrazione.

Cosa significa per te

Se emetti passaporti su dpp.gs, non stai scommettendo su un formato proprietario che gli standard potrebbero contraddire in seguito. Stai emettendo identificatori GS1 Digital Link, dati JSON-LD, portatori QR + DataMatrix e facoltativamente credenziali firmate — esattamente gli ingredienti su cui stanno convergendo gli standard europei. Con il consolidarsi della serie EN e del Registro EU, i tuoi passaporti si adeguano di conseguenza invece di dover essere riemessi.

Letture correlate: GS1 Digital Link spiegato · Standard aperti, non blockchain · Chi vede cosa in un passaporto