🇮🇹🇩🇪🇫🇷🇪🇸🇵🇹🇳🇱🇵🇱🇸🇪🇩🇰🇫🇮🇨🇿🇷🇴🇭🇺🇬🇷🇧🇬🇭🇷🇸🇰🇸🇮🇪🇪🇱🇹🇱🇻🇮🇪🇲🇹🇸🇦🇨🇳🇯🇵🇰🇷🇮🇳🇹🇷🇻🇳🇮🇩

Il 16 aprile 2026, un Digital Product Passport per un vero prodotto tessile è stato ricevuto tramite un portafoglio mobile, verificato crittograficamente e memorizzato come Credenziale Verificabile. L'emittente era ia.reeco.eco. Il portafoglio lo riconobbe come ✅ Verificato.

Spiegherò cosa significa tecnicamente questo, perché il resto del mercato non l'ha fatto e perché è importante per la tempistica di applicazione che tutti stanno ignorando.

Thanks for reading! Subscribe for free to receive new posts and support my work.

Il problema del portaerei è ancora il problema

Ho scritto nell'aprile 2026 che l'investimento del settore nei codici QR come prova della "prontezza DPP" era un errore di categoria. Il trasportino è necessario ma non sufficiente.

Il problema della consegna è il sequel. Un codice QR che apre una pagina web non è una Credenziale Verificabile. È un URL. Non ha alcuna prova crittografica di origine. Non può essere divulgato selettivamente. Non può essere conservato in un portafoglio. Non può essere presentato a un verificatore — un'autorità doganale, un riciclatore, un marketplace — in modo automatizzato, conforme agli standard e indipendente dal tempo di attività del fornitore.

Ho chiesto a sette fornitori DPP di mostrarmi il loro endpoint per il rilascio delle credenziali. La domanda provoca una di due reazioni: un silenzio confuso, oppure una dimostrazione di un codice QR che apre una dashboard.

Un cruscotto non è una credenziali. Una dashboard è una pagina web con un accesso.

Cosa OID4VCI effettivamente richiede

L'infrastruttura del portafoglio di identità digitale UE — che sarà il livello di accesso obbligatorio per DPP nell'ambito del framework EUDIW — è costruita su OID4VCI 1.0, finalizzata a settembre 2025. Questo è il protocollo che regola come una Credenziale Verificabile viene rilasciata a un portafoglio.

Richiede, almeno:

Un endpoint di metadati emittente di credenziali a /.ben noto/emittente di credenziali openid. Un endpoint di token che implementa il flusso di codice pre-autorizzato. Un endpoint di credenziali che rilascia l'accreditamento in un formato di dichiarazione selettiva firmata. Un endpoint JWKS che pubblica le chiavi pubbliche dell'emittente.

Niente di tutto questo è una pagina web. Niente di tutto questo è una dashboard. Si tratta di un'infrastruttura crittografica che prende una richiesta di prodotto, la firma con la chiave privata dell'emittente e la consegna a un wallet in un formato che qualsiasi verificatore può verificare indipendentemente — senza chiamare il fornitore, senza avere un rapporto commerciale con la piattaforma, senza dipendere dallo SLA del fornitore.

Il requisito di mantenimento di 10 anni previsto dall'Articolo 9 dell'ESPR non è affrontabile tramite un SLA del fornitore. È indirizzabile tramite una credenziale che può essere verificata indipendentemente rispetto a una chiave pubblica pubblicata. Queste sono architetture diverse. Solo uno di questi è conforme all'ESPR in termini di applicazione.

Cosa abbiamo costruito e cosa ha dimostrato

L'emittente OID4VCI di Reeco funziona a https://ia.reeco.eco/dpp-issuer/ e espone l'insieme completo di endpoint richiesto da OID4VCI 1.0 Final. Il formato delle credenziali è SD-JWT VC (DC+SD-JWT), firmato con ES256 (P-256) ed EdDSA (Ed25519).

Il design della divulgazione selettiva è deliberato e motivato operativamente. Le seguenti affermazioni sono selettivamente divulgabili — il titolare decide cosa rivelare in base al contesto:

Composizione della fibra con copertura di bilancio di massa. Certificazioni con date di validità. Paese di produzione. Eventi di tracciabilità. Indici di sostenibilità (Indice di Durabilità V1.02, Indice di Riparabilità V3.1, Indice dei Rifiuti V1.0 — Zenodo DOI 10.5281/zenodo.19206499). Nome del marchio e del fornitore.

Sempre visibili, mai redigibili: ID prodotto, GTIN, nome prodotto, categoria prodotto.

Ciò significa che un marchio che presenta il DPP alla dogana può divulgare l'intera composizione e catena di certificazione. Lo stesso marchio che si presenta al consumatore tramite un canale retail rivela composizione e indici di sostenibilità, ma non il nome del fornitore. Stessa credenziali. Stessa firma crittografica. Diversa divulgazione. Il verificatore non può sapere cosa è stato trattenuto — solo che ciò che è stato rivelato è autentico.

Questa è una divulgazione selettiva come previsto nell'RFC 9901. Non è un'opzione per la privacy. È un requisito strutturale per qualsiasi sistema DPP che serve contemporaneamente l'applicazione delle dogane e la trasparenza dei consumatori senza esporre dati commercialmente sensibili della catena di approvvigionamento.

La suite di test automatizzato esegue 8 controlli e report end-to-end OID4VCI flusso CONFORME in 0,09 secondi. L'emissione delle credenziali basate su curl produce una validità DC+SD-JWT A partire da eyJ0eXAiOiJkYytzZC1qd3Qi — verificabile da chiunque al jwt.io.

Il 16 aprile 2026, alle 19:03 CET, Sphereon Wallet su un dispositivo Android ha ricevuto un DPP per l'ordine sub-001 e ha mostrato: https://ia.reeco.eco — EMITTENTE — ✅ Verificato. La credibilità grezze mostra Data di emissione: 2026-04-16T16:57:21Z, TitoloOggetto con dichiarazioni sul prodotto e una prova crittografica con 5 chiavi.

Cosa non funziona ancora — e perché questo è un problema normativo, non tecnico

L'implementazione di riferimento del Digital Identity Wallet dell'UE richiede che gli emittenti siano registrati in una Trusted Issuer List mantenuta dalla Commissione Europea. Attualmente quell'elenco copre i PID — documenti d'identità personali rilasciati dagli Stati membri dell'UE.

Non copre le attestazioni non legate al PID. Non esiste alcuna voce DPP tessile nella Lista degli Emittenti Affidabili perché l'elenco per attestazioni non PID non esiste ancora. L'ARF (Architecture Reference Framework) Annex 2 è in fase di definizione del meccanismo. Il processo degli stakeholder di CIRPASS-2 — a cui partecipo come Membro Esperto di EWG1, EWG3 ed EWG5 — è uno dei canali attraverso cui questa architettura viene modellata.

Quando il wallet EUDIW di riferimento scansiona un'offerta Reeco DPP, recupera correttamente i metadati, verifica il formato delle credenziali e poi annulla silenziosamente perché non riesce a trovare l'emittente nella sua lista fiduciaria. Questo non è un bug del nostro emittente. È una lacuna nell'infrastruttura normativa.

Sphereon Wallet, che opera in modo più permissivo per le credenziali non governative, completa il flusso e contrassegna l'emittente come Verificato. La credenziale è nel wallet, i dati sono presenti, la prova crittografica è valida.

La questione di quando il Registro degli Emittenti Affidabili della CE aprirà per attestazioni non PID è una questione normativa, non tecnica. La mia posizione per CIRPASS-2 è che gli emittenti DPP tessili dovrebbero essere idonei alla registrazione secondo lo stesso quadro fiduciario che regola qualsiasi altro fornitore qualificato di attestazione — non come caso speciale, non dopo un ciclo legislativo separato, ma come parte dell'implementazione iniziale dello strato di attestazione non PID.

Perché questo è importante prima che il registro esista

I marchi che stanno costruendo l'infrastruttura DPP nel 2026 stanno facendo una scelta architettonica che costerà loro di nuovo nel 2027 se la sbagliano.

Un DPP implementato come pagina web statica richiede una completa ricostruzione quando la consegna tramite wallet diventa obbligatoria. La ricostruzione non è una migrazione. Il modello dati è diverso, l'infrastruttura di firma è diversa, il protocollo di consegna è diverso. Il costo non è banale.

Un DPP implementato oggi come OID4VCI Verificable Credential — che è ciò che Reeco emette — è già nel formato corretto. Quando si apre il Registro degli Emittenti Affidabili, aggiungi una registrazione. Non si ricostruisce.

Non ho trovato un'altra piattaforma DPP tessile che attualmente rilascia credenziali SD-JWT VC tramite OID4VCI 1.0. Se esiste una e me la sono persa, sono felice di essere corretta.

L'allineamento UNTP

Reeco è registrato nel Registro Software UNTP (MR !732, UNICC GitLab, approvato aprile 2026) come implementazione conforme dello schema UNTP DigitalProductPassport. La specifica UNTP definisce cosa dovrebbe contenere un DPP. Non definisce come debba essere consegnato.

OID4VCI è il livello di consegna che attualmente manca all'UNTP. Un contributo a UNCEFACT/SPIC-UNTP. è in preparazione la proposta di OID4VCI come meccanismo standard di erogazione per UNTP DPP — con Reeco come implementazione di riferimento.

Per il mercato

L'emittente è attivo. Il formato dell'offerta di credenziali è standard OID4VCI e la JWKS è pubblica in https://ia.reeco.eco/dpp-issuer/jwks. Qualsiasi marca, verificatore o fornitore di portafoglio può testarla contro di essa senza chiedere permesso.

Se sei un fornitore DPP e non puoi mostrare il tuo /.ben noto/emittente di credenziali openid Endpoint, la tua piattaforma non è pronta per il wallet. Potrebbe essere utile anche per altri scopi. Non è ancora pronto per l'infrastruttura di applicazione che l'ESPR richiede.

Questa è un'affermazione falsificabile. L'endpoint o esiste o non esiste.

Stefano Cipriani è il fondatore di Reeco® e Stefano Cipriani Studio (Prato, Italia). Membro esperto CIRPASS-2 EWG1, EWG3, EWG5. Stakeholder registrato JRC, Unità B5 Siviglia. ORCO: 0009-0001-3423-9402. Wikidata: Q138773743. Brevetto CN113529235.

Thanks for reading! Subscribe for free to receive new posts and support my work.