DPP Workflow Example
Our 4TheRecord examples of a Digital Product Passport is built upon the global standards set by the W3C (World Wide Web Consortium) for Decentralized Identifiers (DIDs). Instead of hiding information in a centralized, alterable database, every single one of our products has its own unique, cryptographically secured identity. Below you will find the exact technical workflow that happens in milliseconds when scanning the QR code on a product.
#1 Scanning the QR Code (Entry Point)
Every product is equipped with a unique QR code. Instead of containing a standard website URL, it holds a standardized link directed to a universal DID resolver.
Example #1 QR Codes with resolved Links on the Physical Product for STEEL:
Example #2 QR Codes with resolved Links on the Physical Product for TEXTILE:
#2 The Universal Resolver (Neutral Intermediary)
The link on the physical product points in our case directly to a Universal Resolver gateway (did.re), which utilizes the robust GoDiddy API. Instead of acting as a traditional web server that simply hosts data, a resolver acts like a decentralized DNS or phone book. It translates a raw cryptographic identity string into an actual server location. The following explanations are based on the STEEL example which is analog to the TEXTILE example.
Let’s break down exactly what happens when this URL is requested:
The Gatekeeper https://did.re
This is the proxy frontend for the GoDiddy API resolver. It accepts standard web requests from mobile browsers or auditing applications and translates them into decentralized infrastructure lookups.The Method did:web:
This indicates the specific W3C standard used to resolve the identity. In our case the did:web method tells the resolver that the identity is bound to a trusted web domain, using standard web security (HTTPS) to discover the underlying cryptographic passport.The Domain & Path Separators did.4therecord.io:products:steel00001
In the world of Decentralized Identifiers, standard URL slashes (/) cannot be used inside the core identifier string. Instead, the W3C standard uses colons (:) to separate the domain from the internal folder paths. When the GoDiddy API sees did.4therecord.io:products:steel00001, it automatically converts those colons back into a secure web path layout behind the scenes to fetch the file: https://did.4therecord.io/products/steel00001/did.jsonThe Target Parameter ?service=dpp
A single decentralized identity can have multiple associated endpoints (for example: one endpoint for an auditing report, one for a supply chain log, and one for a customer dashboard). By passing the query parameter ?service=dpp, we explicitly instruct the GoDiddy resolver to look into the product's identity file, select the service entry with the ID #dpp, and execute a seamless HTTP redirect directly to that specific URL.
#3 The Decentralized Product Identity (did.json)
The resolver automatically queries our secure server to read the product's core identity document - the did.json. This file is immutable and serves as the product's digital ID card. It contains two crucial pieces of information:
The Controller: Who manufactured the product? (A cryptographic reference to our Company DID).
The ServiceEndpoint: Where is the DPP hosted? Attention: In our example we directly point to an HTML page instead of the json-file. Why? Please see paragraph #4 and paragraph #5b.
Live Raw File on the Web: https://did.4therecord.io/products/steel00001/did.json
{
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:web:did.4therecord.io:products:steel00001",
"controller": "did:web:did.4therecord.io",
"service": [
{
"id": "did:web:did.4therecord.io:products:steel00001#dpp",
"type": "DigitalProductPassportWeb",
"serviceEndpoint": "https://4therecord.io/products/steel00001"
}
]
}
#4 Automatic Redirect to the Digital Product Passport
As soon as the resolver extracts the serviceEndpoint from the JSON file, it instantly triggers an HTTP redirect. The user is seamlessly forwarded to the dpp.json.
However, in our example case - as we are not using a wallet or similar software - we had to redirect to our secure HTML product page:
Target Interface URL for our example: https://4therecord.io/products/steel00001
Here, the customer can view a beautifully designed frontend featuring all verified product and sustainability data.
#5a Transparency via Decoupled Data (dpp.json) - Best Practice Standard
Before diving into our specific deployment, it is important to understand the global best practice framework established by the W3C and the United Nations Transparency Protocol (UNTP).
The core challenge of a Digital Product Passport (DPP) is that it must be effortlessly processed by machines (like customs software or ERP systems) while remaining visually accessible to humans (like consumers or auditors) without requiring technical expertise.
To achieve this, the standard utilizes a decoupled design pattern. The raw data file (dpp.json) remains completely agnostic of font sizes, colors, or layouts. Instead, it includes a standard renderMethod object. This object acts as an instruction manual, pointing to an external HTML/CSS template hosted on a public server.
When an application - such as a Verifiable Credentials Wallet, a customs inspection platform, a supply chain dashboard, or a smart browser proxy - resolves the DPP, it intercepts this renderMethod. The application then downloads the linked HTML template and dynamically injects the raw cryptographic JSON data into the visual layout.
Example for the renderMethod:
{
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"type": ["VerifiableCredential", "DigitalProductPassport"],
"id": "did:web:did.4therecord.io:products:steel00001",
"issuer": "did:web:did.4therecord.io",
"renderMethod": [
{
"id": "did:web:did.4therecord.io/templates/passport-v1.html",
"type": "TemplateRenderMethod",
"renderSuite": "html"
}
],
"credentialSubject": {
"productDescription": {
"productName": "Steel Beam HEB 300",
"description": "High-strength structural steel beam optimized for modern, sustainable construction frameworks.",
"batchNumber": "BATCH-STL-2026-998"
},
"sustainability": {
"carbonFootprintGWP": "450 kg CO2e / Ton",
"humanRights": "Fully compliant with international labour rights and union standards.",
"childLabour": "Verified zero-risk supply chain for raw materials."
},
"manufacturer": {
"companyName": "4therecord.io",
"location": "Duisburg, Germany"
}
}
}
#5b Transparency via Decoupled Data (dpp.json) - Our Implementation
While the global standard paves the way for dynamic client-side rendering via applications, we have chosen a pragmatic, robust, and highly production-ready hybrid approach for our infrastructure. The content is theoretically retrieved from the associated JSON. But because of the link in serviceEndpoint (in did.json), the resolver redirects the customer to an HTML page - instead to this dpp.json file.
Live Payload File on the Web:https://did.4therecord.io/products/steel00001/dpp.json
{
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"type": ["VerifiableCredential", "DigitalProductPassport"],
"id": "did:web:did.4therecord.io:products:steel00001",
"issuer": "did:web:did.4therecord.io",
"credentialSubject": {
"productDescription": {
"productName": "Steel Beam HEB 300",
"description": "High-strength structural steel beam optimized for modern, sustainable construction frameworks.",
"batchNumber": "BATCH-STL-2026-998"
},
"sustainability": {
"carbonFootprintGWP": "450 kg CO2e / Ton",
"humanRights": "Fully compliant with international labour rights and union standards.",
"childLabour": "Verified zero-risk supply chain for raw materials."
},
"manufacturer": {
"companyName": "4therecord.io",
"location": "Duisburg, Germany"
}
}
}
#6 Cryptographic Proof of Provenance (Company DID)
Because the dpp.json contains the field issuer with the value "did:web:did.4therecord.io", any modern auditing software can independently verify that this product legitimately originates from 4TheRecord GmbH.
To make this verification possible without relying on a centralized registry, the did:web standard utilizes the well-known URI concept (RFC 8615). The .well-known directory is a standardized web location reserved for infrastructure metadata. By forcing the Decentralized Identifier (DID) to resolve to a specific, secure path on our web server, anyone can fetch our public cryptographic keys directly from our domain using standard HTTPS.
Our official corporate DID document is securely hosted here:
Live DID File: https://did.4therecord.io/.well-known/did.json
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2018/v1"
],
"id": "did:web:did.4therecord.io",
"verificationMethod": [
{
"id": "did:web:did.4therecord.io#key-1",
"type": "Ed25519VerificationKey2018",
"controller": "did:web:did.4therecord.io",
"publicKeyBase58": "2t7HqNmnMbgZKjZ8v2f7S5UVT3t9J7nKK8wbHp4ywgg7"
}
],
"authentication": [
"did:web:did.4therecord.io#key-1"
],
"assertionMethod": [
"did:web:did.4therecord.io#key-1"
],
"service": [
{
"id": "did:web:did.4therecord.io#company-credential",
"type": "LegalEntityCredential",
"serviceEndpoint": "https://4therecord.io/dpp"
}
]
}
If you resolve our corporate credential via a standard DID proxy tool, you will notice a specific architectural choice we made for this prototype:
Verify Corporate Credential via Resolver: https://did.re/did:web:did.4therecord.io?service=company-credential
Currently, our serviceEndpoint routes the request directly to our human-readable HTML landing page https://4therecord.io/dpp. This ensures that anyone clicking the link or using a standard browser is immediately presented with a clean, visual representation of our corporate metadata, location, and trade registry details.
In a fully decentralized production ecosystem, pointing a service endpoint directly to a website is discouraged. Instead, best practice dictates that the endpoint should resolve to another raw, machine-readable Verifiable Credential file - for instance: https://did.4therecord.io/.well-known/company_vc.json
In that idealized setup, the auditor's software or wallet would pull the raw company_vc.json data, verify our trade registry signatures cryptographically, and then use an internal or referenced template to render the view for the user - mirroring the exact same decoupled data philosophy we use for our individual product passes.
If you need further information, please don’t hesitate to contact us via one of these possibilities: