SDPP — Digital Product Passports resolved by RFID, time, and place.
A Spatiotemporal Digital Product Passport — SDPP — answers a different question than a URL. Instead of asking "who looked up this product on the public web?", it asks "which tag was tapped, when, and where?". The resolver runs on QDat.io, on infrastructure the operator owns, and it routes every NFC or RAIN read to the right view based on the spatiotemporal coordinates of the read itself — not on the requester's IP.
A product passport that depends on the network is not a passport.
Classic web resolvers route requests by IP address: a shopper opens a URL, a server geolocates the IP, and a CDN serves whichever variant matches. That model assumes the requester is on the public Internet, that the brand still operates a resolver, and that the geolocation of an IP is anything close to where the asset actually is. None of those assumptions hold for an industrial asset on a thirty-year service life — on a vessel, in a mine, in a substation, on an aircraft, in a refinery. The asset's DPP has to be valid even when the network is gone and the brand has moved on.
IP geolocation describes the requester's network, not the asset's position. A technician on a satellite uplink reads as somewhere else entirely.
Public DNS routes everything to whoever currently owns the host. Acquisitions, redirects, or a lapsed domain silently break the contract.
The interaction itself is invisible. There is no record of which physical tag was actually touched at which physical location at which physical time.
RFID resolves on (When, What, Where)
Every tap is a spatiotemporal event before it is a URL.
RFID — both NFC at the centimetre scale and RAIN UHF at the multi-metre scale — is a physical-layer primitive. The reader sees the tag's identifier at a specific time and at a specific reader position. That triple — When, What, Where — is created at the moment of interaction, not inferred from a network header afterwards. The SDPP architecture treats that triple as the resolver's input.
When — the read timestamp
The reader stamps the tap with millisecond precision the moment the tag responds. The chip cannot lie about the time the read happened; the operator's clock is the trivially-available half of the spatiotemporal pair.
What — the on-chip identity
The NFC NDPP record (NFC Forum Type 5 on dual-interface RAIN+NFC ICs like the EM4425 / EM4427, or Type 2/4 on standalone NFC ICs) carries the canonical product identity in the chip's NDEF memory. It is locked at commissioning, readable for decades, and verifiable without an online certificate authority.
Where — the reader's location
The reader inherits GPS coordinates, an override pin, or a known reader-station ID. A handheld at the asset, a portal at a dock door, a fixed reader on a conveyor — each anchors the interaction to a real position on Earth, not to a routing accident.
When the same NFC tag is tapped at a repair shop, at a recycling centre, or at the consumer's kitchen, the chip's UID is identical — but the spatiotemporal tuple is different. The SDPP resolver routes each tap to the appropriate DPP view from that tuple, server-side, in the operator's perimeter.
NDPP / NDEF / CBOR-LD
What actually lives on the chip — and why a phone can read a DPP with no app installed and no webpage hosted anywhere.
The NFC Forum's NFC Digital Product Passport (NDPP) Technical Specification — published as a candidate spec in early 2025 and now in community review — defines the on-chip layout that turns a generic NFC tag into a Digital Product Passport carrier. NDPP standardises an NDEF message that carries both a URL to the online DPP (the part a resolver like QDat.io consumes) and an optional embedded payload of the DPP itself. The embedded payload is a CBOR-LD document — a compact binary serialisation of JSON-LD — and the linked-data vocabulary it speaks fluently is the ISO 59040 Product Circularity Data Sheet. The chip carries one or more NDEF records: one is the URI, another is the CBOR-LD blob; the spec leaves room for additional records (signatures, regulator extensions, manufacturer-specific data) without breaking the basic read path.
NDEF — the envelope every NFC tag already speaks
NDEF (NFC Data Exchange Format) is the NFC Forum's message format for tag contents. Every modern Android, every iPhone since iOS 13, every commercial reader already parses NDEF without an extra application: each message is a sequence of records with a TNF (Type Name Format), a type, an optional ID, and a payload. NDPP just defines new record types (e.g. text/ndpp and a CBOR-LD record) for DPP carriage; the envelope itself is the same one used by URL records, vCards, and Wi-Fi handover pairings — already universally supported.
EM4425 — one non-volatile memory, two radios
The EM Microelectronic EM4425 (em|echo-V) is a dual-interface IC: a RAIN UHF (EPC Gen2v2 / ISO 18000-63) radio and an NFC (Type 5 / ISO 15693) radio that share one and the same non-volatile memory. Because both interfaces address the same memory bank, the GS1 Digital Link can be commissioned over either radio — written by a UHF encoder on the production line, or tapped in over NFC by a phone — and read back over either radio afterwards. A pallet-scale UHF portal and a single-item NFC tap resolve the byte-identical Digital Link URL from the byte-identical memory, so the SDPP resolver receives the same canonical identity no matter which physical layer carried the read.
JSON-LD → CBOR-LD — semantic compression of linked data
JSON-LD (W3C, 2020) is JSON with a @context that maps each key to a globally-unique IRI, so the data carries its own meaning. CBOR (RFC 8949) is a binary serialisation cousin of JSON — same data model, ~30 % smaller, machine-cheap to parse. CBOR-LD (W3C First Public Working Draft, 2026) layers on top: the JSON-LD @context becomes a CBOR-LD term codec that compresses repeated IRIs to small integers, with compression ratios over 60 % better than gzip on linked data. The chip stores CBOR-LD; the reader expands it back to JSON-LD using the same @context the issuer signed. JSON-LD is the human-readable face, CBOR-LD is the on-chip face, CBOR is the carrier, and JSON is what you see when the resolver hands it to a browser.
ISO 59040 PCDS — the vocabulary that fits inside
ISO 59040:2025 — Product Circularity Data Sheet — is the ISO standard, published February 2025, for exchanging circularity information about a product: recycled content, repairability, disassembly, regulatory status. A PCDS document is a structured set of around 130 true/false claims plus references and identifiers. Expressed as JSON-LD and compressed via CBOR-LD, a full PCDS reduces to a payload roughly the size of a short SMS — small enough to sit comfortably in the user memory of an EM4425, NTAG 424, or ICODE DNA chip alongside the NDPP envelope and the resolver URL.
Priority fields — the bytes that surface at the speed of a tap
Not every reader needs the full PCDS at every tap. NDPP separates a small set of priority fields — canonical identifier, GTIN, model, manufacturer, last-update timestamp — into the leading NDEF records, so a phone reading the tag sees them in the first few bytes, before unpacking the CBOR-LD body. The full passport stays available for whoever wants it; the priority subset is what a quick scan needs to answer 'what is this thing' without spinning up a network round-trip or a JSON-LD context dereference.
Modern Android distributions ship a hardened CBOR codec inside the platform itself — bundled into the Identity Credential and Credential Manager stack that handles ISO 18013-5 mobile driving licences and the new W3C Digital Credentials API. Reading a CBOR-LD payload off an NFC tag therefore requires no install: the Android tag dispatch system already routes NDEF records to the foreground activity, and android.identity already knows how to decode CBOR. The same is increasingly true on iOS as Apple Wallet integrates the same ISO 18013-5 stack. The endpoint of this stack is a Digital Product Passport that needs no application on the mobile OS and no webpage hosted anywhere: the chip is the DPP, the OS is the parser, the ISO 59040 vocabulary is the lingua franca, and the NDPP standard is what guarantees the three of them line up. A network resolver like QDat.io then layers spatiotemporal routing on top for the cases where you want more than what the chip alone carries.
QDat.io runs inside the operator's perimeter. Operational reads — which technician, which asset, which site, when — never leave the operator's network. Privacy is preserved by where the resolver runs, not by policy.
Chip-resident truth
The NDPP record is signed and locked at commissioning. Verification happens against trust anchors cached locally — no online certificate authority round-trip required.
Network-optional
Every read, write, and audit query continues to work locally. When bandwidth permits, the local plane replicates upstream — signed events, mirrored trust anchors, regulator updates.
Spatiotemporal routing
The same chip resolves to a service-history view at the repair shop, a dismantling view at the recycler, and a consumer view at home — decided server-side from the When/What/Where of each tap.
One link per item. A geo-and-time rule engine decides what it resolves to.
Under the surface, the SDPP resolver is a single public endpoint — GET /api/v1/dpp/{identifier} — that QDat.io serves inside the operator's perimeter. It follows the GS1 Digital Link pattern: one resolvable web link per item, keyed by the item's own identifier and joined to product-level data through a GS1 SKU. What the base standard leaves open, QDat.io fills in: the resolver does not always return the same passport. It evaluates geofence and elapsed-time rules against the tag's last known location and last-seen timestamp, so the identical link resolves to a different destination near a depot than it does in a customer's home, or before versus after a warranty window.
01
Which operator? (Host)
The resolver is multi-tenant by Host header: the request's hostname is matched against each operator's configured DPP host, so one deployment serves many operators and every read stays scoped to the org that owns the tag.
02
Which item? (identifier)
Within that org the identifier is matched in order — the per-item EPC/UID exact, then the stored link exact, then a link-suffix match — so a scanned GS1 Digital Link path (…/<id>) resolves even when the tag stored the full https://host/<id> URL.
03
Which passport? (template + rules)
The tag's bound passport template carries the branding, the visible-field allowlist, and the geo/time rules. Those rules are evaluated against the tag's last latitude/longitude and last-seen timestamp — the spatiotemporal anchors written on every scan.
04
Fire or render
If a rule fires, the resolver redirects to the rule's destination with the item's id appended, so the target knows which item triggered it. If none fire, it renders the passport — operator sections plus mandatory product, manufacturer, sustainability, and a scan-location block.
Geo block — haversine ≤ radius
A rule's geo block matches when the great-circle (haversine) distance between the tag's last-seen coordinates and the rule's centre is within its radius. A tag that has never reported GPS can never match a geo block.
Time block — elapsed ≥ threshold
A time block matches when at least N days / hours have elapsed since the tag was last seen. A rule carrying both a geo and a time block fires only when both are satisfied — a spatiotemporal AND.
Precedence is deterministic
Among all firing rules, geo-bearing rules beat time-only rules — place is treated as more specific than elapsed time — and otherwise first-in-list wins. The reason is labelled geo, time, or spatiotemporal for audit.
Two channels, one rule set
The same rules, read from the same anchors, run in two places: the web resolver redirects the browser only for rules that opt their page in, while every scan re-evaluates all rules on the device side and can silently redirect the handheld with no round-trip.
Same link, three resolutions
Customer's home · seen 30 days agoRenders the passport — product, CO₂e, and repairability from the GS1-SKU record, plus the scan-location block. Neither block matches.
Within 250 m of the depot · seen 400 days agoRedirects to the return-service page with the item id appended. Geo and time both match → reason "spatiotemporal".
At the depot · but seen only 30 days agoRenders the passport. Geo matches, time doesn't, and the AND fails.
Reference instance
TapDPP is the reader. tapdpp.qdat.io is the resolver you can sign into.
tapdpp.qdat.io runs the same QDat.io codebase an operator would self-host, kept publicly online so the loop closes end-to-end: a TapDPP-equipped Android writes the canonical https://tapdpp.qdat.io/<UID> URL onto a tag in the morning, taps it back, and the resolver answers from the When/What/Where of that read. Operators wiring their own deployment swap the host for theirs; the chip, the app, the MQTT wire format, and the DPP view do not change.
Sign in
A demo login is issued from /demo — request access and you'll receive credentials scoped to the demo tenant on tapdpp.qdat.io. Per-tenant isolation means demo users see the demo tenant's tags and nothing else.
Browse tags
Every NFC and RAIN read landed against the instance surfaces as a tag row carrying its UID, last-seen timestamp, and last-seen GPS pin. That row is the spatiotemporal triple the resolver indexes on — When, What, Where, in one line.
Open a DPP URL
Click a row and the resolver opens that tag's DPP view at https://tapdpp.qdat.io/<UID> — byte-identical to the URL written on the chip itself, so the page a phone gets by tapping the physical tag is the same page the dashboard hands you.
TapDPP — the revamped QDat.io reader for NFC NDPP tags.
TapDPP turns any NFC-equipped Android phone or tablet into a fully recognized QDat.io reader. It writes the canonical https://tapdpp.qdat.io/<UID> URL onto NFC Type V and Type A tags — the same URL that resolves on the reference instance above — publishes every tap live to the QDat.io MQTT broker, and mirrors QDatDroid's heartbeat protocol so TapDPP appears as a live, remotely controllable reader on the operator's dashboard. When the broker is unreachable, scans are queued in an encrypted offline cache and drained the moment QDat.io confirms the writes.
Sideload install — enable "Install unknown apps" for your browser or file manager.
From sideload to a different URL on the same chip — in under five minutes.
TapDPP, the chip, and the QDat.io resolver are designed to demonstrate the SDPP loop end-to-end on a single phone and a single tag. Here is what the round trip looks like for a first-time user.
01
Install TapDPP on an Android handset
Open this page on an NFC-capable Android phone or tablet and tap the Download .apk button in the section above. When the browser asks, enable "Install unknown apps" for that browser — Android tucks the toggle under Settings → Apps → Special access. Open the downloaded file and confirm. TapDPP runs on Android 8.0 (API 26) and later.
02
Sign in to QDat.io from the login screen
Launch TapDPP. The first screen is a Sign-in card. For the public reference instance, tap "Connect to tapdpp.qdat.io" — the app provisions an MQTT pairing in one tap and routes every scan to the demo tenant your /demo credentials are scoped to. For a private deployment, scan the MQTT pairing QR your operator handed you instead; the broker host (e.g. mqtt.acme.qdat.io) decides the tag-URL prefix automatically.
03
Tap a blank NFC tag
Bring an unprovisioned NFC Type V (ISO 15693) or NFC Type A (NTAG / Mifare Ultralight) tag to the back of the phone. TapDPP writes an NDEF URI record carrying https://tapdpp.qdat.io/<UID> into the chip's user memory, then publishes the scan event — UID, timestamp, GPS — to the QDat.io broker.
04
See the URL come back on the Last-Scan card
The home screen renders the freshly written URL underlined as a tap-to-open link, alongside the tag's UID, the IC manufacturer decoded from the UID byte, and the GPS pin of the read. Tap the URL — your browser opens https://tapdpp.qdat.io/<UID>, served by the resolver itself. The MQTT activity log below shows the same triple acknowledged by the broker as a TAG_REGISTERED.
05
Open the QDat.io dashboard and switch the DPP template
Sign in to tapdpp.qdat.io in a browser. Find the tag row you just provisioned — UID, last-seen time, last-seen pin. Open it and switch the DPP Template. Templates are the JSON-LD context the resolver serves under that UID: consumer view, service-history view, dismantling view, regulator view. Same chip, same URL — different page.
06
Add a geotime fence and bind an alternate URL to it
From the same tag row, add a Fence: draw a polygon on the OSM map, set a time window (e.g. 09:00–17:00 weekdays at the dock), and bind it to an alternate URL the chip should carry inside that fence. Save the rule. The fence lives on the resolver, alongside the tag's history — not on the chip.
07
Tap the same chip again — QDat.io pushes a different URL
Bring the same tag back to the phone. TapDPP publishes the new (UID, time, GPS) triple. QDat.io evaluates the fence, returns a TAG_REGISTERED ack carrying the alternate URL, and TapDPP rewrites the chip in place. The Last-Scan card renders a four-line block showing the old URL, the new URL, and the rewrite timestamp. The chip has just been re-routed — server-side — on When, What, and Where.
What landed in the v1.22.0 line
The six things that make the SDPP loop work end-to-end.
TapDPP and its sibling Heli.App share one URL endpoint, one onboarding flow, and one spatiotemporal resolver. The full release history lives in the in-app Release Log; the items below are the ones the SDPP architecture actually depends on.
One canonical tag URL — https://tapdpp.qdat.io/<UID>
Both flavours write the same endpoint to NFC. The default prefix is derived automatically from the MQTT broker host scanned via the QDat.io pairing QR (mqtt.tapdpp.qdat.io → https://tapdpp.qdat.io/) so an operator's own broker hostname becomes the tag URL with no extra config.
Server-driven URL rewrite — the RURL line
When QDat.io's TAG_REGISTERED ack carries a redirect_url for the just-scanned UID, the Last-scan card replaces the regular URL line with a red, underlined RURL line bearing the redirect target — and TapDPP rewrites the chip in place. This is the spatiotemporal resolver visibly routing one chip to different URLs based on When and Where.
The Where pillar made operator-explicit. A single master toggle ("Send location with scans") suppresses all location — including the manual override pin — when off. A Live GPS / Override GPS radio pair picks the source; double-tap on the OSM map stages a draft pin that only commits on Save. Landscape splits 50/50 into controls + full-height map.
Spatiotemporal-DPP onboarding splash
First launch routes through a four-block intro: the SDPP concept, a worked bicycle-tag example (same tag → service-history, end-of-life, or consumer view by location), a live GPS self-diagnostic across six discrete states, and three setup paths — live GPS, manual override pin, or continue without location.
Offline-first MQTT — dual pairings
A QR-scanned production broker and a one-tap tapdpp.qdat.io demo provisioning live side by side; the active source is switchable from Settings. The offline queue persists scans through reconnect cycles and drains as soon as the broker acknowledges — so the SDPP loop survives intermittent or absent network.
NFC Type V + NFC Type A write paths
Tag Init writes to both NFC Type V (ISO 15693) and NFC Type A (NTAG / Mifare Ultralight). A raw block-write fallback handles NTAG-style chips that do not surface Ndef/NdefFormatable, and a deferred two-tap validation flow confirms the URL on chips that drop the link after writeNdefMessage.
Next
Ready to see SDPP resolve on (When, What, Where)?
Book a QDat.io demo to see how TapDPP pairs an NFC NDPP tag, an Android handheld, and the QDat.io on-premise resolver into a single spatiotemporal DPP workflow.
