DSRProtocol

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.

TopicManufacturer — Data ControllerDSR — Data Processor
Passport contentOwns 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 registrationRetains legal responsibility for placing compliant goods on the market.Executes the registration on instruction as Technical Proxy (pointer push).
IdentityProvides and maintains a verified business identity (EORI/VAT + domain).Verifies the identity to a documented standard and binds it to the tenant.
SecurityManages its own users, roles and offboarding within the tenant.Provides encryption, access control, audit logging and platform security.
RetentionInstructs 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
CapabilityStatusEvidence / note
Secure Resolver hosting the passportBuiltschema.org JSON-LD (/passport.json); <100 ms server-side resolve.
Instant per-category Conformity ReportBuilt/conformity completeness across the ESPR five categories.
GS1-standard identity (GTIN + Digital Link)BuiltCheck-digit validation; canonical /01/{gtin}/21/{serial}; bulk-issuable.
Verified business identity (EORI/VAT + domain)In progressWebAuthn / magic-link auth in place; registry-number + domain checks to add.
Append-only, tamper-evident audit (not a ledger)BuiltCompliance audit trail; anonymised scan telemetry.
Technical Proxy — EU-API token custody & pointer pushRoadmap (P4)CEN 18222 connector behind a feature flag; registry infrastructure evolving.
Regulatory Portal (read-only market surveillance)Next deliverableBuilds on /conformity; scoped read-only role + audit.
Archived / read-only retention state (7–10 yr)ConceptDefined here; build scheduled after the Regulatory Portal.
eIDAS 2.0 / qualified signatures / EU Business WalletRoadmapInteroperate 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)

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.
DSRProtocol · Confidential — Internal / Data Room · Draft v0.1 Directory not database · Processor not Controller · <100ms resolve · zero-egress · no immutable PII