The DPP Has a Delivery Problem. We Solved It.
Most platforms still think a QR code that opens a webpage is “wallet-ready.” It is not. Here is what wallet-ready actually means — and what it took to build it.
🇮🇹 🇩🇪 🇫🇷 🇪🇸 🇵🇹 🇳🇱 🇵🇱 🇸🇪 🇩🇰 🇫🇮 🇨🇿 🇷🇴 🇭🇺 🇬🇷 🇧🇬 🇭🇷 🇸🇰 🇸🇮 🇪🇪 🇱🇹 🇱🇻 🇮🇪🇲🇹 🇸🇦 🇨🇳 🇯🇵 🇰🇷 🇮🇳 🇹🇷 🇻🇳 🇮🇩
On April 16, 2026, a Digital Product Passport for a real textile product was received by a mobile wallet, cryptographically verified, and stored as a Verifiable Credential. The issuer was ia.reeco.eco. The wallet recognized it as ✅ Verified.
I am going to explain what this means technically, why the rest of the market has not done it, and why it matters for the enforcement timeline everyone is ignoring.
The carrier problem is still the problem
I wrote in April 2026 that the industry’s investment in QR codes as proof of “DPP readiness” was a category error. The carrier is necessary but not sufficient.
The delivery problem is the sequel. A QR code that opens a webpage is not a Verifiable Credential. It is a URL. It has no cryptographic proof of origin. It cannot be selectively disclosed. It cannot be stored in a wallet. It cannot be presented to a verifier — a customs authority, a recycler, a marketplace — in a way that is automated, standards-compliant, and independent of the vendor’s uptime.
I have asked seven DPP providers to show me their credential issuance endpoint. The question produces one of two reactions: a confused silence, or a demo of a QR code that opens a dashboard.
A dashboard is not a credential. A dashboard is a webpage with a login.
What OID4VCI actually requires
The EU Digital Identity Wallet infrastructure — which will be the mandatory access layer for DPP under the EUDIW framework — is built on OID4VCI 1.0, finalized September 2025. This is the protocol that governs how a Verifiable Credential is issued to a wallet.
It requires, at minimum:
A credential issuer metadata endpoint at /.well-known/openid-credential-issuer. A token endpoint implementing the pre-authorized code flow. A credential endpoint that issues the credential in a signed, selective-disclosure format. A JWKS endpoint publishing the issuer’s public keys.
None of this is a webpage. None of this is a dashboard. It is a cryptographic infrastructure that takes a product claim, signs it with the issuer’s private key, and delivers it to a wallet in a format that any verifier can independently verify — without calling the vendor, without having a commercial relationship with the platform, without depending on the vendor’s SLA.
The 10-year retention requirement in ESPR Article 9 is not addressable by a vendor SLA. It is addressable by a credential that can be independently verified against a published public key. These are different architectures. Only one of them is ESPR-compliant in the enforcement sense.
What we built and what it proved
Reeco’s OID4VCI issuer runs at https://ia.reeco.eco/dpp-issuer/ and exposes the complete endpoint set required by OID4VCI 1.0 Final. The credential format is SD-JWT VC (dc+sd-jwt), signed with ES256 (P-256) and EdDSA (Ed25519).
The selective disclosure design is deliberate and operationally motivated. The following claims are selectively disclosable — the holder decides what to reveal per context:
Fiber composition with mass balance coverage. Certifications with validity dates. Country of manufacture. Traceability events. Sustainability indices (Durability Index V1.02, Repairability Index V3.1, Waste Index V1.0 — Zenodo DOI 10.5281/zenodo.19206499). Brand name and supplier name.
Always visible, never redactable: product ID, GTIN, product name, product category.
This means a brand presenting the DPP to customs can disclose the full composition and certification chain. The same brand presenting to a consumer through a retail channel discloses composition and sustainability indices but not the supplier name. Same credential. Same cryptographic signature. Different disclosure. The verifier cannot tell what has been withheld — only that what has been disclosed is authentic.
This is selective disclosure as designed in RFC 9901. It is not a privacy option. It is a structural requirement for any DPP system that simultaneously serves customs enforcement and consumer transparency without exposing commercially sensitive supply chain data.
The automated test suite runs 8 end-to-end checks and reports OID4VCI flow COMPLIANT in 0.09 seconds. The curl-based credential issuance produces a valid dc+sd-jwt beginning with eyJ0eXAiOiJkYytzZC1qd3Qi — verifiable by anyone at jwt.io.
On April 16, 2026, at 19:03 CET, Sphereon Wallet on an Android device received a DPP for order sub-001 and displayed: https://ia.reeco.eco — ISSUER — ✅ Verified. The raw credential shows issuanceDate: 2026-04-16T16:57:21Z, credentialSubject with product claims, and a cryptographic proof with 5 keys.
What does not work yet — and why that is a normative problem, not a technical one
The EU Digital Identity Wallet reference implementation requires issuers to be registered in a Trusted Issuer List maintained by the European Commission. That list currently covers PID — personal identity documents issued by EU Member States.
It does not cover non-PID attestations. There is no textile DPP entry in the Trusted Issuer List because the list for non-PID attestations does not exist yet. The ARF (Architecture Reference Framework) Annex 2 is in the process of defining the mechanism. The CIRPASS-2 stakeholder process — in which I participate as Expert Member of EWG1, EWG3, and EWG5 — is one of the channels through which this architecture is being shaped.
When the reference EUDIW wallet scans a Reeco DPP offer, it fetches the metadata correctly, verifies the credential format, and then silently aborts because it cannot find the issuer in its trust list. This is not a bug in our issuer. It is a gap in the normative infrastructure.
Sphereon Wallet, which operates in a more permissive mode for non-government credentials, completes the flow and marks the issuer as Verified. The credential is in the wallet, the data is present, the cryptographic proof is valid.
The question of when the EC Trusted Issuer Registry will open for non-PID attestations is a regulatory question, not a technical one. My position for CIRPASS-2 is that textile DPP issuers should be eligible for registration under the same trust framework that governs any other qualified attestation provider — not as a special case, not after a separate legislative cycle, but as part of the initial implementation of the non-PID attestation layer.
Why this matters before the registry exists
The brands building DPP infrastructure in 2026 are making an architectural choice that will cost them again in 2027 if they make it wrong.
A DPP implemented as a static webpage requires a complete rebuild when wallet-based delivery becomes mandatory. The rebuild is not a migration. The data model is different, the signing infrastructure is different, the delivery protocol is different. The cost is not trivial.
A DPP implemented today as an OID4VCI Verifiable Credential — which is what Reeco issues — is already in the correct format. When the Trusted Issuer Registry opens, you add a registration. You do not rebuild.
I have not found another textile DPP platform that is currently issuing SD-JWT VC credentials via OID4VCI 1.0. If one exists and I have missed it, I am happy to be corrected.
The UNTP alignment
Reeco is registered in the UNTP Software Register (MR !732, UNICC GitLab, approved April 2026) as a compliant implementation of the UNTP DigitalProductPassport schema. The UNTP specification defines what a DPP should contain. It does not define how it should be delivered.
OID4VCI is the delivery layer that UNTP currently lacks. A contribution to uncefact/spec-untp proposing OID4VCI as the standard delivery mechanism for UNTP DPP — with Reeco as the reference implementation — is in preparation.
For the market
The issuer is live. The credential offer format is standard OID4VCI and the JWKS is public at https://ia.reeco.eco/dpp-issuer/jwks. Any brand, verifier, or wallet provider can test against it without asking permission.
If you are a DPP provider and you cannot show your /.well-known/openid-credential-issuer endpoint, your platform is not wallet-ready. It may be useful for other purposes. It is not ready for the enforcement infrastructure that ESPR requires.
That is a falsifiable claim. The endpoint either exists or it does not.
Stefano Cipriani is the founder of Reeco® and Stefano Cipriani Studio (Prato, Italy). Expert Member CIRPASS-2 EWG1, EWG3, EWG5. JRC Registered Stakeholder, Unit B5 Seville. ORCID: 0009-0001-3423-9402. Wikidata: Q138773743. Patent CN113529235.