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

Two URLs resolve, as of this week:

  • https://ia.reeco.eco/v0.7/dpp/6df75070-714f-4031-9bd5-b4014b22993e

  • https://ia.reeco.eco/v0.7/dpp/6df75070-714f-4031-9bd5-b4014b22993e/jws

The first returns a Verifiable Credential. The second returns a JWS over that credential, signed by an Ed25519 key whose public material is published at did:web:ia.reeco.eco. Both are conformant to UN/CEFACT UNTP 0.7.0, DigitalProductPassport type. To my knowledge, this is the first Italian DPP emitted against that specification and made publicly verifiable.

This post is not an announcement. It is a note on what changes when a Digital Product Passport stops being a regulatory shape and becomes an artifact you can resolve, parse, and verify with a standard JOSE library.

The gap between specification and running code

Most of the DPP conversation — three years into the ESPR secondary acts and well inside the UN/CEFACT UNTP recommendations process — still takes place at the level of what a DPP should be. Granularity. Data model. Trust anchor topology. Identifier strategies. These conversations are necessary. The EWG3 work on identity and verifiable credentials, the CIRPASS-2 contributions to the recommendations process, the JRC’s stakeholder consultations: all of it is serious work and is shaping the field.

But there is a second conversation that only opens once an issuer is actually running. What does the spec look like when you serialize it? Where does the JSON-LD context resolve from? Which fields end up empty in practice — not from implementer laziness, but because the textile supply chain does not surface them at the DPP issuance moment? Which signing curve does your DID document advertise, and does the verifier you imagined would check the artifact actually pick the right key?

These questions have empirical answers only after something runs.

What the artifact contains

The credential at the URL above describes a deliberately illustrative product: a knit fabric, CPC 2820, manufactured in Türkiye by a placeholder mill called “Test Mill.” It is not a commercial passport. It is not a claim about a real product on a real shelf. The fabric is a vehicle for the stack underneath.

What the stack proves:

  • A did:web:ia.reeco.eco identifier resolves to a DID document at .well-known/did.json, advertising both an Ed25519 key (ed25519-1, used for the JWS above) and an ES256 key. Two curves are exposed because verifier ecosystems have not converged on one.

  • The credential is typed as DigitalProductPassport per UNTP 0.7.0. It is not a custom Reeco type, not a flavored variant, not a “DPP-like” object.

  • The JWS is retrievable from a separate endpoint, so a relying party can request the credential and the proof independently — useful when caching or replication policies differ for the two.

  • The issuer software, Reeco DPP Issuer 0.2.0-untp070, is the same instance listed in the UN/CEFACT UNTP Software Register (MR !732, merged April 2026). The 33-test migration suite passing on commit 7e68064 is the integration boundary against the 0.7.0 schema.

None of this is novel research. It is plumbing. The value is that the plumbing is wired to the actual specification, not to a parallel one.

Why “first Italian” is not a flag-planting claim

It is tempting, when something runs first in a national context, to read it as a competitive marker. That is not the right frame here.

The relevant frame is geographic. Italy holds a substantial share of European textile manufacturing — Prato, Biella, Como, Carpi — and the operational reality of how mass balance, certification, country-of-origin, and component traceability work on the floor is anchored in this geography. ESPR will bind manufacturers, importers, and brands operating across it. The UN/CEFACT recommendations process and the JRC’s implementation guidance need the feedback loop that comes from running issuers in the places where the textile actually moves.

A first emission from Prato is not a national achievement. It is the start of that feedback loop on Italian textile soil — one issuer, one stack, conformant, public, inspectable.

Notes for the spec community

A few observations for UNTP and CIRPASS-2 colleagues who may inspect the artifact:

  • The Ed25519 / ES256 dual-key pattern was driven by verifier-side fragmentation. A pure Ed25519 stack works for some downstream consumers and fails silently in others. Any normative recommendation on signing curves will materially reduce implementation cost for SMEs.

  • The granularity question — what level of product description belongs in the DPP itself versus in linked credentials — does not resolve on paper. It resolves when an issuer has to fill the JSON. Several fields that look optional in the schema turn out to be operationally required to make the credential useful to a brand sustainability officer. Others marked recommended are difficult or impossible to populate from the upstream supply chain at the issuance moment. Implementation experience here is worth surfacing into the EWG1 and EWG3 conversations.

  • Public verifiability is cheap to specify and expensive to operate. Hosting an issuer, a DID document, and credential URLs at production-grade SLAs is not a small ask for SMEs in the textile sector. The recommendations process should weigh this when shaping conformance criteria.

These are not complaints. They are what the implementer’s chair looks like. CIRPASS-2 has been deliberate about gathering this kind of input through its expert working groups, and the UNTP register is explicitly structured to accept implementations as a form of contribution. This post is in that spirit.

What it changes for brands

For sustainability and compliance officers reading this: a verifiable DPP changes the trust model.

Today, most claims that travel with a textile product are PDFs, mill declarations, certifier-issued certificates referenced by serial number. The verification path is human, slow, and rests on the credibility of the document author.

A conformant DPP is a different object. It is signed by a key whose public counterpart sits at a stable, resolvable location. The signature is checkable in milliseconds by any standard JOSE library. The link between the product, the issuer, and the underlying claims is cryptographic, not narrative.

This does not replace certification. It does not eliminate audit. What it does is reduce the cost of asking the question “is this claim what its author said it was?” — and once that cost approaches zero, the asymmetry between sophisticated and unsophisticated buyers across the supply chain narrows. That is the operational shift worth thinking about, well in advance of the ESPR deadlines forcing it.

Reeco informs brands, on a per-unit basis, when the certified material their suppliers report is consistent with the mass balance of the finished product, and when it is not. The brand decides what to do with that information. The DPP is the carrier; the verification stack is the trust anchor; the brand retains autonomy on every claim. A working issuer makes that loop concrete rather than hypothetical.

Closing

The credential is at the URL. The JWS is at the URL. The DID document is at https://ia.reeco.eco/.well-known/did.json. Inspection is welcome — corrections, technical critique, requests for additional fields, edge cases that break the verifier — all useful.

Standards mature through implementation. This is one implementation. There will be more.

Stefano Cipriani — Reeco · Stefano Cipriani Studio · PratoCIRPASS-2 Expert Member (EWG1 / EWG3) · JRC Registered Stakeholder · UN/CEFACT UNTP Software Register