DPP Agent docs

EN 18219 — Digital Product Passport resolver services

EN 18219 specifies what happens between a scanner reading the URL a product carries and the passport content reaching the reader's screen. In practice this is a resolver: a service that accepts an incoming HTTP request against a GS1 Digital Link URI and returns the correct passport representation for the caller.

If EN 18216 answers how is the passport addressed, EN 18219 answers how is the address turned into content, reliably, over time, across languages, and for different classes of reader.

What EN 18219 requires

The standard makes six substantive requirements of a compliant resolver.

1. Deterministic URI parsing

The resolver must correctly parse the full GS1 Digital Link URI including all application identifiers. /01/07350053850015 must resolve to the product-level passport. /01/07350053850015/22/RED-M must resolve to the variant-level passport for the red medium. /01/07350053850015/22/RED-M/10/2026-W17/21/SN-000042 must resolve to the item-level passport for a single serialized unit. A resolver that only supports GTIN-level and ignores CPV, BATCH or SERIAL is not conformant.

Structurally the resolver builds an internal identifier tuple (GTIN, CPV, BATCH, SERIAL) from the URL, then hierarchically matches: first serial-level, then batch-level, then variant-level, then product-level. The most specific match wins. This lets a brand publish a shared "base" passport for the product line and override with a batch-specific passport when a new supplier changes the composition without re-issuing the base.

2. Content negotiation

The resolver must respect standard HTTP Accept, Accept-Language and Accept-Encoding headers. In practice:

  • Accept: text/html — the human-readable rendering. Default for browsers.
  • Accept: application/json or application/ld+json — the machine-readable rendering. Default for agents, scanners with structured-data pipelines, regulatory validators.
  • Accept: application/xml — some regulator tooling still uses XML. The standard permits refusing this with 415 Unsupported Media Type but recommends supporting it if the resolver operator has downstream regulator integrations.

Language negotiation is more subtle. A single passport typically carries data in multiple languages (the brand's home market plus each import market the product is sold into). The resolver must:

  • Parse Accept-Language and select the best available match using RFC 4647 language-tag matching.
  • Fall back to the passport's declared default language when no negotiated match exists.
  • Never silently return "no data" for a valid language request; if a section is untranslated, return the base language with an explicit xml:lang attribute so the caller can render a "translation missing" affordance.

3. Section-level audience scoping

Not every reader is entitled to see every part of a passport. Consumer readers get materials, care, footprint, resale information. Recyclers get disassembly, hazardous-substance content, take-back paths. Customs authorities get economic-operator information, HS/TARIC codes, country-of-origin evidence. The resolver must enforce section-audience rules declared in the passport data itself.

EN 18219 does not prescribe an access-control mechanism (that is out of scope). It requires that the resolver expose an audience parameter (either via query string or Accept header extension) and enforce the passport's own section-visibility declarations. Reader identity verification — how does the resolver know a request really is from a certified recycler — is deferred to the ecosystem (mutual TLS with EU-registered certificates is the current de facto approach).

4. Redirect and error semantics

The resolver's HTTP status codes must be meaningful. The standard enumerates:

  • 200 OK — passport returned.
  • 301 Moved Permanently or 308 Permanent Redirect — the identifier resolves to a different URL now (brand has migrated resolver hosts). Must include an accurate Location header. Callers are expected to cache and update.
  • 302 Found or 307 Temporary Redirect — short-lived rerouting, do not cache.
  • 404 Not Found — the identifier is unknown. The resolver must NOT return a soft-404 (200 with an "not found" body). Regulatory scanners rely on the status code being accurate.
  • 410 Gone — the identifier existed but has been withdrawn from the market permanently. Different from 404 because it tells the caller "do not retry, do not treat this as a temporary miss".
  • 451 Unavailable For Legal Reasons — identifier exists but the caller's jurisdiction cannot access it (rare, but used by battery-safety-recall systems).

5. Persistence over time

Persistence is where EN 18219 shades into EN 18221 (the lifecycle standard). EN 18219's contribution is that the resolver must remain callable at the URL for the product's regulated lifetime. In practice this means:

  • The resolver host domain must be under the brand's or operator's control, not a transient shortener.
  • Cache-control headers must let downstream infrastructure honour the resolver's freshness declarations without hiding stale content.
  • Resolver-side rate-limiting must not lock out legitimate scanning bursts (product launches, recall campaigns).

6. Zero client-side state

The resolver must return usable content on the first HTTP response — no client-side JavaScript required. Regulatory scanners, headless validators, and non-JavaScript consumer devices (some in-store point-of-sale terminals, older phones) must all get the passport data in the first response. This does not preclude progressive enhancement for browser consumers; it precludes making JS execution mandatory.

This requirement is what breaks many brand-built solutions. A single-page React app hosted at dpp.brand.com/01/07350... looks identical to a spec-compliant resolver in a browser, but returns an empty body to a curl request. That is non-conformant.

Common mistakes

Serving a soft 404. The resolver returns 200 OK with an HTML page that says "we couldn't find this product". Regulator crawlers treat this as a valid passport. Import-inspection systems mark the product as compliant when it should be flagged. Fix by returning proper 404 status codes.

Locale-guessing from IP. The resolver looks at the caller's IP address and picks a language. This breaks tourists, VPN users, and every automated scanner. Fix by respecting Accept-Language and using IP-based locale only as the last fallback.

Losing the audience parameter through a middleware. A CDN edge cache or a load balancer strips query strings for cache-key efficiency. Consumer and regulator content gets cross-served. Fix by including the audience parameter in the cache key.

Client-side rendering for the resolver page. The brand ships a React SPA at the resolver host. Browsers work, curl gets an empty body, AI crawlers see nothing. This is the single most common conformance failure in production. Fix by server-side rendering, prerendering, or an edge function that renders the HTML per request.

How DPP Agent implements EN 18219

DPP Agent's resolver lives at api/v1/resolve.js and runs on a Vercel Edge function. Per-request TTL is single-digit milliseconds at the edge. It implements every EN 18219 requirement:

  • Hierarchical URI matching against passport_id derived from the (GTIN, CPV, BATCH, SERIAL) tuple.
  • Content negotiation for HTML, JSON-LD, and CIRPASS-2 schema shape (?schema=cirpass-2).
  • Locale matching against a curated ISO 639-1 + 639-3 allowlist with a per-passport default language.
  • Section-audience roles (twelve seeded: consumer, economic-operator, manufacturer, importer, distributor, online-marketplace, repairer, refurbisher, recycler, customs-authority, market-surveillance, competent-authority).
  • Proper HTTP status codes for 404, 410 (withdrawn), and 451 (jurisdiction-blocked).
  • All HTML is server-rendered from the passport data before the response leaves the edge — no client-side JS required to see content. Progressive enhancement adds interactivity for browser consumers only.

Practical checklist

  • Resolver URL matches the passport identifier structure exactly (all AI components parsed)
  • HTTP status codes reflect reality (no soft-404, no 200-on-error)
  • Multi-language content is negotiated via Accept-Language, not IP
  • Section-audience declarations in the passport are honoured
  • HTML content is present in the first HTTP response (no JS required)
  • Cache headers and cache-key include audience + locale
  • Rate limiting has headroom for launch or recall bursts
  • Resolver-host DNS is under long-term brand or operator control

Standard reference

CEN/CENELEC JTC 24. EN 18219:2025 — Digital Product Passport — Resolver services.

Companion specifications:

  • RFC 7231 (HTTP semantics)
  • RFC 4647 (language-tag matching)
  • GS1 Digital Link resolver specification (v1.3.0)
  • W3C JSON-LD 1.1