Discovery Mechanisms Overview
Purpose
This section defines how Digital Product Passports (DPPs) can be discovered, accessed, and verified
across both physical and digital product ecosystems.
It provides a domain-agnostic foundation, allowing each product specification (such as AIPS for AI products)
to implement its own concrete mechanisms.
1. Discovery in Context
Digital Product Passports are designed to be universally discoverable — whether attached to a
physical item, embedded in a digital artifact, or referenced within a marketplace.
The discovery mechanism acts as the entry point to the DPP’s verifiable record.
Each product’s DPP URI should resolve to:
- a machine-readable representation (
application/ld+jsonor RDF), - and/or a human-readable viewer interface.
2. Common Discovery Mechanisms
| Mechanism | Description | Product Contexts | Typical Use |
|---|---|---|---|
| QR Code | Two-dimensional visual code resolving to a DPP URI or API endpoint. | Physical goods, digital marketplaces, documentation. | Printed on labels, packaging, datasheets, dashboards. |
| NFC Tag | Embedded chip storing DPP URI (optionally signed). | High-value physical goods, lab equipment, smart packaging. | Tap-based validation with mobile devices. |
| GS1 Digital Link | GS1-compliant URL encoding product identity + DPP link. | Regulated industries (food, pharma, electronics). | Traceability, compliance integration. |
| Standard URI/URL | Direct link to the product’s canonical DPP representation. | Digital, AI, or data products. | Marketplace listings, portals, API responses. |
| Content Negotiation | HTTP negotiation (Accept: headers) returning the DPP in preferred format. | All web-exposed DPP APIs. | Seamless integration with catalogs and agents. |
| Blockchain Anchor (optional) | Hash of the DPP registered on a distributed ledger. | High-trust or regulated ecosystems. | Immutable proof of integrity. |
Note: QR codes are not limited to physical products.
In post-modern marketplaces, QR codes are increasingly used in digital product listings, PDF reports, and model cards as visual trust badges resolving to a verifiable DPP URI.
3. Relationship to the BPS DPP Core
All mechanisms above are transport-layer agnostic — they only affect how a DPP is discovered,
not how it is structured or validated.
Each resolved endpoint must conform to the BPS DPP Core specification and expose:
- A canonical URI,
- A versioned representation,
- A verifiable signature or hash.
4. Domain-Specific Extensions
Individual product specifications extend this overview:
| Domain Spec | Extension | Example |
|---|---|---|
| AIPS (AI Product Specification) | Adds mechanisms for model registries, digital manifests, and embedded metadata. | Model card QR → DPP viewer |
| DIPS (Data Product Specification) (future) | Focuses on data catalog integration and governance registry linking. | Catalog entry → DPP API |
| Physical Product Profiles | Use QR/NFC/GS1 primarily for consumer and regulator transparency. | Apparel tag → EU DPP viewer |
5. Best Practices
- Always use HTTPS URIs that are versioned and canonical.
- Use shortened or resolvable URLs within QR codes for longevity.
- Ensure public read access to Lite DPPs for transparency.
- Pair QR/NFC discovery with a Verifiable Credential or signature for integrity validation.
- Maintain backward compatibility: older discovery links should redirect to newer DPP versions when superseded.
6. Summary
DPP discovery mechanisms bridge human trust and machine verifiability.
While QR and NFC remain critical for physical traceability,
URIs, manifests, and linked metadata enable equal transparency for digital and AI products.
Future product specifications (like AIPS and DIPS) build upon this foundation, ensuring that discovery, verification, and interoperability stay consistent across product domains.