DPP Compliance Playbook — Governance & Technical Proxy
How DSR operates as a secure Resolver and Technical Proxy for the EU Digital Product Passport.
Draft v0.1 · 2026 · A living document — figures and dates to be re-confirmed before external use.
Confidential · Internal / Data Room
What this is. DSR is building a DPP-as-a-Service compliance operating system: we give a manufacturer a single, self-serve way to issue GS1-standard product passports, resolve them in <100 ms, and — when the EU registry opens — register the pointer on their behalf. We sit on top of their existing ERP/PLM/MES; we do not replace the systems of record and we do not put personal data on any immutable ledger. This Playbook sets out, in plain terms, how we secure the data, how we authenticate with the EU, how roles and liability are split, and how we guarantee long-term persistence — the four questions every enterprise partner and auditor will ask.
1
The core distinction — Registry vs Passport
Do not conflate the two. The EU Registry is a directory (a phonebook); the passport itself lives on our Resolver. This separation is what keeps trade-secret data private and keeps our claims honest.
ManufacturerData Controller — owns the product and the accuracy & legality of its passport content.
▶
Authorises (token)
▶
DSR PlatformData Processor · Technical Proxy + Resolver — custodies the EU-API token, hosts the passport, and runs the <100 ms resolve + conformity report.
▶
Pushes the POINTER only — GTIN + secure host URL
EU DPP Registry — the "Directory"A phonebook entry: Product X belongs to Manufacturer Y and resolves at this secure URL. No materials, carbon or repair data ever sent here.
▶
Serves the FULL passport on scan (GS1 Digital Link QR)
Consumer / RegulatorScans the QR → resolves via DSR → sees the actual passport and an instant per-category conformity report.
Why this matters: we never over-promise. We do not upload a client's bill-of-materials, carbon footprint or repair instructions to the EU. We register a pointer and remain the secure host of the content — which is exactly the paid job.
2
The Technical Proxy model — who connects to the EU API
DSR does. The legal responsibility for the data stays with the manufacturer, but they neither want to — nor should have to — build and maintain the API handshake with the European Commission. We absorb that complexity; it is why they subscribe.
How the handshake works
- Authorise once, in the dashboard. The client verifies their business identity and grants a scoped authorisation for DSR to act on their behalf.
- Generate the index. Our system builds the registration record (GS1 identifier + secure host URL) for each product.
- Push the pointer. We register that pointer with the EU Registry via the standardised API (CEN 18222) — pointer only, never the content.
- Resolve on demand. Any scan or audit resolves through our Resolver to the live passport in <100 ms.
Token custody & security posture
- Scoped, revocable authorisation — least-privilege; the client can revoke at any time from the dashboard.
- Secrets encrypted at rest; access is server-side only and never exposed to the browser or logs.
- Every proxy action is audited — append-only, tamper-evident, attributable to the authorising tenant.
- Feature-flagged rollout — the connector ships behind a flag against the stabilising CEN 18222 spec; no hard launch-date promises.
3
Roles & responsibilities — Processor vs Controller
A clear split, written into the TOS/SLA, protects DSR from liability for content it does not author, and gives the client a defensible governance story.
| Topic | Manufacturer — Data Controller | DSR — Data Processor |
| Passport content | Owns and is responsible for the accuracy & legality of all data entered (materials, claims, declarations). | Hosts and serves the content faithfully; does not author or warrant its correctness. |
| EU registration | Retains legal responsibility for placing compliant goods on the market. | Executes the registration on instruction as Technical Proxy (pointer push). |
| Identity | Provides and maintains a verified business identity (EORI/VAT + domain). | Verifies the identity to a documented standard and binds it to the tenant. |
| Security | Manages its own users, roles and offboarding within the tenant. | Provides encryption, access control, audit logging and platform security. |
| Retention | Instructs the required retention period per product category. | Guarantees persistence for that period, including a read-only archive (see §7). |
Liability red line: DSR is not liable for incorrect client-entered data. Our obligation is faithful processing, hosting, security and availability — not the truth of the manufacturer's declarations.
4
The Trust Gateway — identity of the signer
Now — verified business identity (shipping)
- EORI / VAT validation — check the registration number against the relevant public registry.
- Verified domain control — confirm the client controls the corporate domain used to sign.
- Hardened tenant auth — password + WebAuthn passkeys and magic-link sign-in already in the platform.
- Signer attribution — every passport publish is attributable to a verified tenant user, recorded in the audit trail.
Later — eIDAS 2.0 (roadmap, not claimed)
- Qualified electronic signatures and EU Business Wallet / verifiable credentials once regulation forces higher-assurance identity.
- Interoperate with the SSI world (DIDs / VCs) rather than rebuild it.
- Honest positioning: we say "verified business identity", never "eIDAS-compliant", until the qualified layer is genuinely delivered.
5
Data sovereignty, security & privacy
Zero-egress — defined precisely
- We do not exfiltrate a client's other systems. We resolve against the passport we host; we do not copy or centralise their ERP/PLM data.
- The registry push is pointer-only — identifier + host URL, never content.
- What we do store, plainly: the passport a client asks us to host, plus an append-only audit trail — required to serve and to meet retention. "Zero-egress" is not "we store nothing".
PII-free by design (GDPR + KVKK)
- Passports carry product data, not personal data. This resolves the retention-vs-erasure tension: a 7–10-year hold never traps someone's personal information.
- Scan telemetry is anonymised — IP anonymisation, user-agent stripping, coarse geo dropped — so analytics never become surveillance.
- Append-only, tamper-evident audit — not an immutable public ledger. No blockchain, no cryptocurrency, no proof-of-work; tamper-evidence comes from cryptographically hashed records, so erasure of any incidental personal data remains possible.
- EU/EEA residency option and encryption in transit and at rest; KVKK-aligned for Turkish clients.
6
Data retention & stewardship
ESPR requires passport data to remain accessible for defined periods (commonly 7–10 years, product-dependent). Our platform must persist this data even if a client stops subscribing — with no lock-in and no data hostage-taking.
Persistence & the archived state
- Archived / read-only state — on churn, a passport freezes to a durable, read-only record that continues to resolve for the mandated retention period. Concept — build later
- Continuity guarantee — access to the conformity record is preserved for regulators and consumers throughout retention.
- No lock-in — a full data-export / portability guarantee; the client can take their passports elsewhere at any time.
Commercial model — stewardship (pricing TBD)
- Tiered Data Stewardship Pricing — based on product volume and retention duration; long-term hosting after churn may carry a stewardship fee.
- Quotable EU-first in € with $ and £ equivalents; figures deliberately TBD until storage costs at scale are known.
- Minting stays free; the meter remains plan + resolutions (consistent with the Price Sheet).
7
Market surveillance access — the Regulatory Portal
If an auditor comes knocking, they need a secure, read-only way to pull an instant Conformity Report for any product ID they scan — without ever touching a client's account or writing to any record.
What it provides
- Scan a product ID / GTIN → instant Conformity Report, built on the existing
/conformity endpoint.
- Scoped, read-only regulator account — no edit, no export of trade-secret internals beyond the mandated passport view.
- Every regulator access is logged — who, what, when — in the append-only audit trail.
Status
- Foundations already built — machine-readable passport (
/passport.json) and per-category conformity (/conformity). Built
- To build — the scoped read-only role, invite flow and the auditor-facing portal view. Next deliverable
8
Governance readiness matrix — transparency as a sales asset
| Capability | Status | Evidence / note |
| Secure Resolver hosting the passport | Built | schema.org JSON-LD (/passport.json); <100 ms server-side resolve. |
| Instant per-category Conformity Report | Built | /conformity completeness across the ESPR five categories. |
| GS1-standard identity (GTIN + Digital Link) | Built | Check-digit validation; canonical /01/{gtin}/21/{serial}; bulk-issuable. |
| Verified business identity (EORI/VAT + domain) | In progress | WebAuthn / magic-link auth in place; registry-number + domain checks to add. |
| Append-only, tamper-evident audit (not a ledger) | Built | Compliance audit trail; anonymised scan telemetry. |
| Technical Proxy — EU-API token custody & pointer push | Roadmap (P4) | CEN 18222 connector behind a feature flag; registry infrastructure evolving. |
| Regulatory Portal (read-only market surveillance) | Next deliverable | Builds on /conformity; scoped read-only role + audit. |
| Archived / read-only retention state (7–10 yr) | Concept | Defined here; build scheduled after the Regulatory Portal. |
| eIDAS 2.0 / qualified signatures / EU Business Wallet | Roadmap | Interoperate with the SSI world when regulation requires it. |
Honest headline: the Resolver, conformity reporting and GS1-standard identity are live; identity verification is in progress; the EU-API proxy and archival state are on a disciplined roadmap. We publish this openly — transparency is the sale.
Non-negotiable red lines (claims discipline)
- Directory, not database. We register a pointer with the EU; trade-secret content never leaves our Resolver.
- Processor, not Controller. We are not liable for client-entered data; the manufacturer owns accuracy and legality.
- Never "certified". We say "ESPR-aligned" / "registry-ready", self-benchmarked — never "EU-certified" or "government-approved".
- Honest eIDAS. "Verified business identity" today; eIDAS 2.0 / qualified signatures are roadmap, never claimed as present.
- No blockchain or cryptocurrency. (We do use cryptography — AES-CMAC chip authentication, TLS, hashed audit records; “crypto” here means coins and distributed ledgers, not cryptography.) The audit trail is append-only and tamper-evident — not an immutable public ledger — which keeps it GDPR-erasure-friendly.
- Zero-egress, precisely. No exfiltration of other systems; no immutable PII; but we do persist the passport we host — we never claim "we store nothing".
- Retention ≠ trapping PII. Passports are PII-free by design, so 7–10-year retention never holds personal data (GDPR + KVKK safe).
- No hard dates. CEN 18222 and the EU registry are still moving; the connector ships behind a flag with no committed launch date.
9
US right-to-repair — the same resolver-linked identity
The EU mandates a Digital Product Passport; the United States is legislating a parallel obligation from the other direction — right-to-repair. Both converge on the same thing we already provide: a persistent, resolver-linked identity on the product that opens the right information on a normal phone, with no app. One engine answers both regimes — EU-first for the passport, US-ready for repair.
EU — the passport mandate
- ESPR (Regulation (EU) 2024/1781) — the Digital Product Passport becomes mandatory by product group; the EU central DPP registry is live (since 20 July 2026).
- GS1 “Sunrise 2027” — retail checkout moves to 2D codes, so one GS1 Digital Link QR serves both the till and the passport.
- Empowering Consumers + e-labelling — structured, multilingual data with auditable records for the product’s regulated life.
US — the repair mandate (a growing patchwork)
- State right-to-repair laws — New York (2023), California (2024, items $50+), Minnesota (2024), Connecticut & Texas (2026), Oregon (2027) — the map keeps widening.
- Colorado’s parts-pairing ban (January 2026) forbids software locks that stop replacement parts working.
- Brands must give “fair and reasonable” access to repair manuals, parts and tools — typically via a persistent QR / link with no login.
How DSR serves both, honestly: we host one persistent resolver-linked identity per unit and route each audience to the right governed view — the EU passport for regulators and consumers, and repair manuals, parts lists and tool access for US right-to-repair — from the same scannable link, with no login. As ever, we are the Resolver and host; the manufacturer remains responsible for the accuracy and legality of the content. US right-to-repair dates are drawn from public 2026 sources and are still shifting — re-confirm before external use.
10
Standards, references & timeline
Standards we build to
- ESPR — the EU Ecodesign for Sustainable Products Regulation (the DPP mandate).
- CEN 18222 — the technical committee defining the DPP API / data-carrier standards (engineering to monitor releases).
- GS1 Digital Link + ISO/IEC 15459 — product identity and the canonical QR URI.
- schema.org JSON-LD — machine-readable passport output.
- GDPR + KVKK — EU and Turkish data-protection posture; eIDAS 2.0 on the identity roadmap.
Regulatory timeline (evolving — re-confirm)
- ~Jul 2026 — EU central DPP Registry infrastructure goes live.
- ~Feb 2027 — Battery Passport becomes the first mandatory DPP.
- ~Q2 2027 (expected) — textile delegated act adopted; enforcement typically ~18 months later.
- 2027 — GS1 "Sunrise": QR at point-of-sale via GS1 Digital Link.
Dates are drawn from public 2026 sources and are still shifting. Treat as directional and re-confirm immediately before any client-facing or regulatory use.
The one-line positioning
"Keep your systems of record. DSR is the secure Resolver that hosts your product passports and — when the EU registry opens — registers the pointer on your behalf. We handle the EU-API complexity so you don't hire integration engineers; you keep control of the data, and no personal data ever touches an immutable ledger."
Bottom line. We have the engine; this is the governance layer that makes it enterprise-grade. DSR is the Resolver and Technical Proxy: the EU gets a pointer, the client keeps their data, regulators get instant read-only conformity, and passports persist for the mandated years without lock-in. We win on orchestration, not replacement; GDPR/KVKK-safe trust, not an immutable ledger; and disciplined claims — verified business identity now, eIDAS later, self-benchmarked always, and never a promise we cannot keep.