Digital Product Passport

info

Please note that this specification is suitable for pre-production pilot implementations.

Artifacts

v0.8.0 Schema and Samples

The JSON schema and sample credential instances for the Digital Product Passport are maintained in this repository.

• JSON Schema:

Schema	Description
DigitalProductPassport.json	Full credential schema including the W3C VC envelope and Product subject
Product.json	Standalone schema for the Product credential subject

• Sample Instances:

Sample	Description
DigitalProductPassport_instance.json	Copper concentrate from a sample mine in Zambia
DigitalProductPassport_cathode_instance.json	Refined copper cathode from a sample refinery in Japan
DigitalProductPassport_battery_instance.json	75 kWh battery from a sample manufacturer in Germany

The three samples represent successive stages of a copper-to-battery supply chain.

Vocabulary and Context

The DPP is built on the UNTP Core Vocabulary, which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published under https://vocabulary.uncefact.org/untp/.

A credential references the versioned context, not that base path. For this release that is https://vocabulary.uncefact.org/untp/0.8.0/context/, which is what the samples on this page use. The unversioned path is where the vocabulary is published, not a context a credential can resolve.

Overview

The digital product passport (DPP) is issued by the shipper of goods and is the carrier of basic product and packaging data together with quality, safety and sustainability performance for every serialised product item (or product batch) that is shipped between actors in the value chain. It is deliberately simple and lightweight and is designed to carry the minimum necessary data at the granularity needed by the receiver of goods — for example the carbon footprint of a product shipment, where the receiver needs it. The passport contains links to conformity credentials which add trust to the ESG claims in the passport. The passport also contains links to traceability events which provide the "glue" to follow the linked-data trail (subject to confidentiality constraints) from finished product back to raw materials. The UNTP DPP does not conflict with national regulations such as the EU DPP. In fact, it can usefully be conceptualised as the upstream B2B feedstock that provides the data and evidence needed for the issuing of high quality national level product passports. See Jurisdictional Extension for how jurisdiction-specific requirements sit above the common base, and why they cannot be pushed upstream to actors who do not yet know which market the product will reach.

What a DPP is obliged to carry is set by whoever asks for it, not by UNTP. The model below is a common structure with a small mandatory core — an identifier, a name, a classification, where and in what country it was made. Everything else, including every sustainability claim, is optional and carried only where a regulator, a customer or a scheme requires it. Greenhouse gas emissions are one such case among many: a buyer may need a product carbon footprint to compile its own reporting, and UNTP carries that as a performanceClaim like any other, but nothing in UNTP makes emissions reporting of any scope a condition of conformance.

The same holds for the evidence behind a claim. UNTP makes an attestation and its issuer visible and verifiable; it does not decide whose attestations a reader must accept. A verifier applies its own rules — regulatory, contractual or commercial — to decide whether a conformity credential from a particular assessor, accredited under a particular scheme in a particular country, satisfies its needs. That judgement sits with the reader, consistent with UNECE Recommendation 49, and UNTP's role is to make the basis for it legible and verifiable rather than to arbitrate it.

Conceptual Model

Requirements

The digital product passport is designed to meet the following detailed requirements as well as the more general UNTP Requirements.

ID	Name	Requirement Statement	Solution Mapping
DPP-01	Granularity	The DPP should support use at either model level or at batch level or at serialised item level.	The idGranularity property together with modelNumber, batchNumber, and itemNumber
DPP-02	Classification	The DPP should support any number of product classifications using codes from a defined classification scheme. Issuers SHOULD prefer a recognised, maintained and internationally used scheme (for example UN CPC, HS or GS1 GPC) over a proprietary or locally defined one, because a code a reader can look up is worth more than one it cannot. Additional proprietary classifications MAY be carried alongside.	The productCategory array of Classification objects, each naming its idScheme
DPP-03	Materials provenance	The DPP should provide a simple structure to allow issuers to break down the material composition of their products by mass fraction and origin country so that raw material provenance requirements are easily assessed and met.	The materialProvenance array of Material objects, each with originCountry, massFraction, recycledMassFraction, and hazardous indicator
DPP-04	Produced at	The DPP should provide a simple structure to describe the manufacturing facility at which the product was made. The facility identifier SHOULD be resolvable and verifiable.	The producedAtFacility property with id, name, and registeredId
DPP-05	Dimensions	The DPP must support the definition of key product dimensions such as length, width, height, weight, volume so that conformity claims made at the unit level (eg CO2 intensity in Kg/Kg) can be used to calculate actual values for the shipped product.	The dimensions property using the Dimension class with Measure values
DPP-06	Traceability	The DPP should provide a means to follow links to further DPPs and conformity credentials of constituent products so that (subject to confidentiality constraints), provenance claims can be verified to any arbitrary depth up to primary production.	The relatedDocument array can link to upstream DPPs and DTE traceability event credentials using typed links
DPP-07	Characteristics	The DPP should allow an issuer to provide industry-specific product attributes that are not covered by the core model, using an open and extensible structure.	The characteristics property accepts arbitrary key-value pairs (additionalProperties: true)
DPP-08	Verifiable Party	The DPP should provide DPP issuer, product manufacturer, and facility operator identification including a name, a resolvable and verifiable identifier, and proof of ownership of the identifier.	CredentialIssuer with issuerAlsoKnownAs, Product.relatedParty with defined roles, and Product.producedAtFacility — all SHOULD have related resolvable Identity Resolver credentials
DPP-09	Claims	The DPP MUST provide a means to include any number of performance claims within one DPP so that it can provide a single point to aggregate all claims about the product.	The performanceClaim array of Claim objects
DPP-10	Conformity Topic	The DPP MUST provide a simple mechanism to express the sustainability/circularity/conformity topic for each claim so that similar claims can be grouped and the high-level scope easily understood.	The Claim.conformityTopic property referencing the Conformity Topics taxonomy
DPP-11	Metrics	The DPP MUST provide a simple mechanism to quantify a conformity claim (eg carbon intensity, water consumption) using either a numeric measure with tolerance, or a categorical score, or both.	The Performance class with metric (from the Performance Metrics taxonomy), measure (value + unit + tolerance), and score (code + rank)
DPP-12	Criteria	The DPP MUST provide a means to reference a standard or regulation as well as the specific criteria within that standard or regulation — so that claims can be understood in terms of the criteria against which they are made.	Claim.referenceCriteria, Claim.referenceRegulation, and Claim.referenceStandard
DPP-13	Evidence	The DPP MUST provide a means to reference independent conformity assessments that support and verify the claims being made. The related evidence SHOULD be digitally verifiable but MAY be a simple document or web page.	The Claim.evidence property links to a UNTP Digital Conformity Credential (DCC) or other supporting document
DPP-14	Packaging	The DPP should provide a structure to describe the product's packaging including dimensions, materials used, and any packaging-specific labels or conformity claims.	The packaging property using the Package class with dimensions, materialUsed, packageLabel, and performanceClaim
DPP-15	Labels	The DPP should support the inclusion of certification marks, regulatory symbols, and other visual labels that appear on the product or its packaging.	The productLabel array of Image objects (product-level) and Package.packageLabel (packaging-level)
DPP-16	Related documents	The DPP should provide a means to link to supporting documents such as manuals, reports, declarations, studies, or guidance that are relevant to the product but are not structured data within the credential.	The relatedDocument array of Link objects with linkURL, linkName, mediaType, and linkType
DPP-17	Lifecycle data	The DPP should provide a means to link to dynamic in-use data that changes over the product's life (eg remaining capacity, charge cycles, temperature exposure, maintenance records) so that current product state can be discovered from the passport.	Links in relatedDocument to UNTP Digital Traceability Event (ModifyEvent) credentials that carry updated state-of-health or usage data
DPP-18	Scoring	The DPP should support expressing performance as a categorical score (eg a carbon footprint class A through E, or a compliance rating) in addition to numeric measures, so that regulatory grading schemes can be represented.	The Performance.score property with code, rank, and definition
DPP-19	Substances of concern	The DPP should provide a structured means to declare substances present in a material that appear on a regulatory candidate or restricted-substance list, naming the substance, the list it is declared against, its concentration, and where in the product it occurs, so that a reader can assess a restricted-substance obligation without parsing a safety data sheet. Concentration may be withheld where commercially sensitive; presence of a declaration is itself the statement that the substance exceeds the list's threshold.	The substanceOfConcern array of SubstanceOfConcern objects on each Material, with regulatoryList as a Classification. The coarse hazardous boolean remains as a screening flag
DPP-20	Bill of materials	The DPP should provide a means to list the discrete components and sub-assemblies a product is assembled from, as distinct from the materials it is made of. Because a component is itself a product, an entry should identify the component and link to its own passport where one exists rather than restating its content, so that composition can be traversed without any one credential having to contain its own supply chain.	The includedComponent array of Component objects, each with an optional componentPassport link
DPP-21	Repairability	The DPP should indicate which components are available separately as spare parts and for how long, so that a repairer can establish what can be replaced before committing to a repair. Repair and maintenance documentation should be reachable as linked resources rather than embedded.	Component.sparePart and Component.availabilityPeriod; repair documentation via relatedDocument with an appropriate linkType

Logical Model

A Digital Product Passport has two layers, which are easier to follow separately.

• The product model: what the passport says about the product, covering its identity, what it is made of, where it was made, and what is claimed about it. This is an assembly of classes from the UNTP core vocabulary, and the part a product-data system maps onto.
• The credential envelope: who said it, when, and how a verifier can tell it has not been altered. This is the W3C Verifiable Credentials wrapper, identical for every UNTP credential type.

The two layers are independent of each other. A product model describes a product whether or not it is ever signed, and the envelope will secure any subject. UNTP joins them by placing a Product in the envelope's credentialSubject and recommends that pairing as the default, since an unsigned product record tells a verifier nothing about who is accountable for it. Serialising the product model some other way is possible, but out of scope for UNTP core.

The product model

Each box is a class; each labelled arrow is a property, with its cardinality at the target end: 1 exactly one, 0..1 optional single, * any number. Properties whose values are plain text, numbers, dates or codes are listed inside the box; properties whose values are other objects appear as arrows. The class names are the type values that appear in the JSON, so Claim in the diagram is "type": ["Claim"] in a credential.

Everything in the diagram is defined in the Core Vocabulary and shared with other UNTP credential types. Party, Facility, Claim, Criterion, Measure, Link and the rest appear in facility records and conformity credentials too. Nothing in the product model is unique to the DPP except the Product class itself.

Product, the credential subject. Seven properties are mandatory: id, name, idScheme, idGranularity, productCategory, producedAtFacility and countryOfProduction. Everything else is optional.

Property	Type		What it carries
id	URI	required	The product identifier, ideally resolvable — see Product Identification
name	text	required	The product name
description	text		A longer description
idScheme	IdentifierScheme	required	The scheme that issued id, such as GS1 GTIN
idGranularity	code	required	Whether id denotes a model, a batch or an individual item
modelNumber, batchNumber, itemNumber	text		The manufacturer's own identifiers at each level
productCategory	Classification *	required	What kind of product this is, as a code in a named scheme
productImage	Link		A picture of the product
producedAtFacility	Facility	required	Where it was made
countryOfProduction	Country	required	The country of manufacture
productionDate, expiryDate	date		When it was made, and when it expires
relatedParty	PartyRole *		Other organisations and the role each plays
dimensions	Dimension		Weight, length, width, height, volume — each a Measure
materialProvenance	Material *		The materials it is made of, by origin, mass fraction and recycled content, including any substances of concern
includedComponent	Component *		The components and sub-assemblies it is assembled from — its bill of materials — and which of them are available as spare parts
packaging	Package		The packaging, with its own dimensions, materials and labels
productLabel	Image *		Regulatory or scheme marks shown on the product
characteristics	Characteristics		Industry-specific attributes — an open extension point, see Characteristics
performanceClaim	Claim *		What is claimed about the product, and the evidence for it
relatedDocument	Link *		Manuals, reports and other documents

The supporting classes. Facility is a production site, identified as it is in a Digital Facility Record. PartyRole pairs a Party with the role it plays, which is why a manufacturer and an importer can both appear without ambiguity. Material is one constituent substance, with its originCountry, materialType classification, mass, optional safety link, and any SubstanceOfConcern declarations. Component is one constituent part, identified and optionally linked to its own passport (see Materials, components and spare parts). Package mirrors the product's own structure, with dimensions, materials, labels and claims of its own. Claim is the assertion structure shared across UNTP: it references a Criterion from a Standard or Regulation, is classified by ConformityTopic, carries quantified Performance (a Measure and/or a Score against a PerformanceMetric), and links to evidence, typically a Digital Conformity Credential. Classification, Country, Measure, Dimension, Address, Link and Image are shared value objects.

The groupings used elsewhere on this page (manufacturing context, material provenance, performance claims) are headings for sets of related properties. They are not classes, and there is no ManufacturingContext object in a credential.

The credential envelope

The envelope is the W3C Verifiable Credential that carries the product model. It contributes no product data. Its job is to let a reader decide whether the document can be trusted.

Property	What it carries
issuer	The DID of the organisation making the assertions, anchored to a registered identity by a Digital Identity Anchor
validFrom, validUntil	The period over which the issuer stands behind the passport
credentialStatus	Where to check whether it has since been revoked
credentialSubject	The Product — the product model above
renderMethod	How to present it to a person
proof / JOSE signature	The cryptography that makes tampering detectable

How a verifier combines them

A verifier reads the envelope first and the product model second. It checks the signature against the issuer's DID, resolves that DID to a Digital Identity Anchor to learn which registered organisation controls it, checks credentialStatus, and confirms the passport was valid at the time that matters. The product data becomes meaningful once it is attributable to a known organisation.

That ordering is why UNTP recommends the pairing rather than treating it as optional.

Credential Schema

The full JSON Schema — the envelope wrapping the Product subject — is the working version, a candidate for UNTP v1.0.0.

Loading schema viewer...

For detailed class and property definitions, see the Core Vocabulary reference.

Implementation Guidance

The core implementation question for any DPP issuer is: how do I map my existing product data requirements to this standard? Whether the requirements come from a national regulation (such as the EU Battery Regulation), an industry standard, or an internal product information system, the mapping follows the same approach. Every source data attribute falls into one of six categories:

Mapping Type	UNTP Pattern	When to use
Direct property	Named properties on Product (e.g. id, dimensions.weight, productCategory, producedAtFacility, materialProvenance, productLabel)	The source attribute has a direct equivalent in the UNTP core vocabulary
Characteristic	Product.characteristics — an open object that accepts any key-value pairs	Industry-specific technical parameters with no generic UNTP equivalent (e.g. battery voltage, rated capacity, internal resistance)
Performance claim	Product.performanceClaim — a Claim referencing a ConformityTopic, a PerformanceMetric, and optionally a Score, with optional evidence linking to a Digital Conformity Credential (DCC) for independent verification	Quantified sustainability or conformity metrics (e.g. carbon footprint, recycled content, energy efficiency)
Lifecycle event	A UNTP Digital Traceability Event (ModifyEvent) linked from the DPP	Dynamic data that changes over the product's life (e.g. remaining capacity, charge cycles, temperature exposure, accident records)
Related document	Product.relatedDocument — a Link to an external resource	Supporting documents such as manuals, reports, studies, or declarations that are not structured data
No mapping	—	We aim to avoid any unmapped cases. If you find a data requirement that cannot be mapped, please contact our mailing list so we can address it

The first three types carry static data set at manufacture and live inside the DPP credential. Lifecycle events capture dynamic in-use data in separate DTE credentials linked from the DPP. Related documents and conformity evidence provide links to supporting resources.

Dynamic data and lifecycle events are not the same thing, and the mapping above uses events for a reason. A current state-of-health figure is an observation about the product as it is now. A lifecycle event is a dated record of something that happened to the product, signed by whoever did it. UNTP carries the second because a reader in another country needs to know who asserted a change and when, rather than only what a value reads today. Where a system just needs the present value, publish it at a resolvable address and link to it as a related document.

Claims versus direct properties

Direct properties and performance claims cover similar-looking attributes, so the choice between them needs a rule.

A direct property records a fact about the product that anyone holding it could establish: its weight, its dimensions, its category, the facility that made it. Nothing is asserted against a standard and no evidence is attached.

A performance claim records a value measured against a stated yardstick. It names the Criterion from the standard, regulation or scheme that defines how the figure was arrived at, classifies the subject matter with a ConformityTopic, expresses the result as a Measure or Score against a named PerformanceMetric, and links to evidence. A carbon footprint means little without the methodology and boundary that produced it, and two figures calculated under different rules cannot be compared.

The test to apply is whether the value depends on a method that has to be named for the number to mean anything. Weight does not. Energy efficiency usually does, since it is measured under a defined test procedure. A battery's rated capacity can go either way: as a manufacturer's specification it is a direct property, and as a figure verified against a test standard it is a claim with evidence.

Materials, components and spare parts

A product is described in two ways. materialProvenance covers what it is made of: the substances, with origin country, mass fraction and recycled content. Cobalt sulphate, graphite, copper. Each Material may carry substanceOfConcern entries declaring substances on a regulatory candidate list, against the list that names them.

includedComponent covers what it is assembled from, which is the bill of materials: a cell module, a battery management system, a housing.

A component is itself a product. It can have its own passport, its own materials, its own claims and its own upstream chain, so a component entry identifies it and links to that passport rather than restating it:

"includedComponent": [{
  "type": ["Component"],
  "id": "https://id.gs1.org/01/09520123456788",
  "name": "Lithium-ion cell module, 6.25 kWh",
  "idScheme": { "type": ["IdentifierScheme"], "id": "https://id.gs1.org/01/", "name": "GS1 GTIN" },
  "quantity": { "value": 12, "unit": "H87" },
  "componentPassport": {
    "linkURL": "https://credentials.example.com/dpp/cell-module-6250",
    "linkName": "Cell module passport",
    "linkType": "https://test.uncefact.org/vocabulary/link-type/dpp"
  },
  "sparePart": true,
  "availabilityPeriod": { "startDate": "2026-03-01", "endDate": "2036-03-01" }
}]

Only name is required. A component with no passport of its own is still worth listing, since a reader learns that the product contains it and whether it can be replaced.

A spare part is a component that can be bought separately, so sparePart and availabilityPeriod sit on the component entry rather than forming a second list that could disagree with the first. A repairer and a recycler read the same structure.

includedComponent is not the manufacturing input list. A Digital Traceability Event, the UNTP Make event or its EPCIS Association equivalent, already records what went into producing the product. The two answer different questions and are disclosed to different readers.

	Question	Where it lives
includedComponent	What parts is this product made up of, that a holder of the product needs to know about?	In the passport
Make event inputs	What was consumed to produce this item, on this date, at this facility?	In a linked traceability event

The production record is often commercially sensitive, particularly upstream, which is why it stays in an event the issuer can withhold or release under its own access control rather than being fixed into the passport. includedComponent is optional and the issuer decides what to list: in most passports that is the serviceable and replaceable parts, plus anything a reader needs for another reason, such as a component carrying a substance of concern. Listing an exhaustive bill of materials is permitted but rarely required, and an issuer should not read this property as an obligation to publish one.

Link types

Every Link in a UNTP credential carries a linkType saying what the target is in business terms: a conformity credential, a dismantling manual, a spare-parts catalogue. That value is a URI, and it must identify a definition a reader can look up.

linkType is a business classification of the target resource, distinct from two properties it is often confused with:

Property	Answers	Example
linkType	What kind of thing is the target, in business terms?	a Digital Conformity Credential
mediaType	What format is it in?	application/vc+ld+json
IANA link relations	What is the target's relationship to the context resource?	predecessor-version, alternate

UNTP deliberately does not mandate which vocabulary the classification comes from. Link is used for so many different purposes across the model that a single UNTP-owned list would either be perpetually incomplete or would grow to absorb every sector's document taxonomy. Instead, a linkType SHOULD be drawn from a published, governed vocabulary. UN/CEFACT publishes the link-type code list covering the target kinds the specifications themselves reference — the credential types (dpp, dcc, dte, dfr, dia, dcr), evidence kinds, and product lifecycle information such as dismantling-info and spare-parts-info. An ecosystem with an established vocabulary such as the GS1 link types should use that instead. Failing either, an issuer MAY publish its own type at a URI that dereferences to a definition.

The value MUST be an absolute http(s) URI rather than a compact IRI. iana:dpp is a syntactically valid URI and passes schema validation, but it resolves only for a reader running a JSON-LD processor with that prefix in scope, and only when the prefix is defined at all. Many consumers treat the credential as plain JSON and are left with a token they cannot look up.

An IANA link relation is a legitimate value where the link expresses a relationship rather than a document class. Most business link types have no IANA equivalent, and inventing a mapping to one loses meaning. The two coexist: Identity Resolver linksets use dpp and dte for what a target is alongside predecessor-version and edit for how it relates, in the same linkset.

That position was agreed for Identity Resolver linksets and applies equally to links inside credentials. A reader meeting an unfamiliar type needs the URI to resolve so they can find out what it means.

Passing data along a multi-tier supply chain

A product assembled from many inputs, each with its own upstream chain, does not need a passport that contains all of it. Furniture built from several timber components, one of which is fibreboard made from multiple feedstocks, still gets one passport describing the furniture.

UNTP composes rather than nests. Each actor issues a passport about the product it ships and links to the passports of the inputs it consumed, through Digital Traceability Events that record the transformation. A verifier follows those links as far as it needs, which is the Trust Graph pattern. A finished-goods manufacturer is not obliged to restate what its suppliers already asserted, and usually cannot: the upstream detail is commercially sensitive, changes per batch, and belongs to someone else.

Two consequences follow. How far back a reader can see depends on how many actors upstream have issued credentials and made them discoverable, rather than on how much data the last one put in its passport. And each actor discloses its own data under its own access control instead of handing it to a customer to republish, so confidentiality holds without anyone having to arrange it.

For a due-diligence use case such as deforestation regulation, the reader assembles evidence by traversal: the finished-product passport, the events that produced it, the input passports those events reference, and the conformity credentials attached at whichever tier carries the relevant assessment.

Example: EU Battery Passport (DIN DKE SPEC 99100)

The DIN DKE SPEC 99100 is the German standard implementing the EU Battery Regulation (EU 2023/1542) battery passport data requirements. It defines 94 mandatory and recommended data attributes across seven clusters. Every attribute maps to the UNTP DPP model with no gaps:

Mapping Type	Count	What it covers
Performance claim	25	Carbon footprint, recycled content, energy efficiency, durability metrics
Characteristic	21	Battery-specific technical specifications (voltage, capacity, resistance, lifetime, temperature)
Lifecycle event (DTE)	21	Dynamic in-use data (remaining capacity, charge cycles, temperature exposure, negative events)
Direct property	18	Identifiers, classification, facility, mass, labels, materials, substances of concern, components and spare parts
Related document	9	Dismantling manuals, due diligence reports, safety measures, end-of-life guidance
Total	94

Three attributes moved into direct properties in this release, each having previously needed a workaround:

• Hazardous substances (6.5.5) were carried by setting a hazardous boolean on the affected material. They are now a structured substanceOfConcern declaration naming the substance, the list it is declared against, its concentration and where it sits.
• Part numbers for components (6.6.1.3) were pushed into characteristics as a free-form array, because the model had no component concept. They are now identified entries in includedComponent.
• Spare parts availability (6.6.1.4) was a link to a sourcing portal. Which components are available separately, and for how long, is now structured on the component.

The mapping also records two columns the standard supplies and UNTP has to honour.

Data access splits the 94 attributes into 59 public, 33 restricted to persons with a legitimate interest, one restricted to notified bodies, and one the standard leaves unclassified (6.1.3.3, date of putting the battery into service). The same product therefore carries data at several disclosure levels, which is what Decentralised Access Control and the variant-based disclosure pattern exist to serve.

Information level splits them into 66 at model level and 25 at item level, with three the standard does not assign (6.6.3.2 to 6.6.3.4, the waste-prevention guidance for end users, which is general information rather than a property of either a model or an item). That distinction is DPP-01: attributes recorded once per model sit in a model-level passport, while anything that varies per unit — the battery identifier, the manufacturing date, the state of health — forces a serialised item-level passport. An implementer that reads only the model-level column will under-build.

Relationship to the Commission's own list. The European Commission publishes a Guidance Document: Digital Batteries Passport — data points by category (version 2.0, 15 August 2026), which lists 71 data points, each cited to its legal source in Regulation (EU) 2023/1542 and marked mandatory, conditional or not yet required for EV, light means of transport and industrial batteries separately.

The two are read together rather than one replacing the other. The Commission guidance is the better statement of what the law asks for, because each data point carries its article or annex reference and its applicability by battery category. It states that it is not the Commission's official position and does not add to the obligations in the Regulation, and it does not yet specify units or formats, which it notes may come in a future update. DIN DKE SPEC 99100 supplies exactly that missing layer: measurement units, item-versus-model granularity, and the access tiers summarised above, none of which appear in the guidance document. The attribute counts differ (71 against 94) because the guidance groups at a coarser level than the standard decomposes to.

UNTP maps against DIN DKE SPEC 99100 here because a field-level mapping needs field-level detail. A normative mapping to the Commission's data points is tracked separately for after the v1.0 release, alongside the equivalent regimes in other jurisdictions.

The full attribute-by-attribute mapping, including both columns, is available as a CSV download. The battery sample credential demonstrates the static mappings — direct properties, characteristics, performance claims, related documents, labels, substances of concern and the bill of materials — for a 75 kWh EV battery pack.

The components of a DPP

This section provides sample JSON-LD snippets for each DPP component, drawn from the battery sample credential.

Credential Envelope

All DPPs are issued as W3C Verifiable Credentials (VCDM 2.0). The credential type includes both VerifiableCredential and DigitalProductPassport, and the @context references both the W3C VCDM and UNTP context URIs. The issuer id SHOULD be a DID using a supported DID method, with issuerAlsoKnownAs linking to authoritative business register identifiers.

{
  "type": ["DigitalProductPassport", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.8.0/context/"
  ],
  "id": "https://credentials.sample-battery.example.com/dpp/bat-75kwh-2025",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-battery.example.com",
    "name": "Sample Battery Mfg GmbH",
    "issuerAlsoKnownAs": [
      {
        "id": "https://sample-register.example.com/companies/BAT-001",
        "name": "Sample Battery Mfg GmbH",
        "registeredId": "BAT-001",
        "idScheme": {
          "id": "https://sample-register.example.com",
          "name": "Sample Commercial Register"
        }
      }
    ]
  },
  "validFrom": "2025-03-01T00:00:00Z",
  "validUntil": "2035-03-01T00:00:00Z",
  "credentialSubject": { "type": ["Product"], "..." : "..." }
}

Product Identification

The Product credential subject identifies the product via a resolvable URI (id), an identifier scheme (idScheme), and granularity indicators (modelNumber, batchNumber, itemNumber, idGranularity). The product id should match identifiers on the physical product so that scanning a QR code resolves to this DPP via an Identity Resolver. Classification uses productCategory with schemes such as UN CPC.

"credentialSubject": {
  "type": ["Product"],
  "id": "https://id.sample-battery.example.com/product/bat-75kwh-2025",
  "name": "75 kWh Li-ion Battery Pack",
  "idScheme": {
    "id": "https://id.sample-battery.example.com",
    "name": "Sample Product Identifier Scheme"
  },
  "modelNumber": "BAT-NMC811-75",
  "batchNumber": "2025-SZG-0342",
  "itemNumber": "BAT-75-2025-00471",
  "idGranularity": "item",
  "productCategory": [
    {
      "type": ["Classification"],
      "code": "46410",
      "name": "Primary cells and primary batteries",
      "idScheme": {
        "type": ["IdentifierScheme"],
        "id": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
        "name": "UN Central Product Classification (CPC)"
      }
    }
  ]
}

Manufacturing Context

The producedAtFacility identifies the manufacturing site, countryOfProduction carries the ISO 3166 country, and relatedParty lists organisations in defined roles. The relatedDocument array provides links to supporting documents such as conformity credentials for the facility.

"producedAtFacility": {
  "id": "https://facility-register.example.com/fac-003",
  "name": "Sample Battery Factory",
  "registeredId": "fac-003"
},
"countryOfProduction": { "countryCode": "DE", "countryName": "Germany" },
"relatedParty": [
  {
    "role": "manufacturer",
    "party": {
      "type": ["Party"],
      "id": "did:web:sample-battery.example.com",
      "name": "Sample Battery Mfg GmbH",
      "registeredId": "BAT-001"
    }
  }
]

Dimensions

Physical measurements of the product. Each dimension is a Measure with a value and unit drawn from UNECE Recommendation 20. Include only the dimensions relevant to the product.

"dimensions": {
  "weight": { "value": 450, "unit": "KGM" },
  "length": { "value": 2100, "unit": "MMT" },
  "width":  { "value": 1500, "unit": "MMT" },
  "height": { "value": 150, "unit": "MMT" }
}

Material Provenance

The materialProvenance array describes the constituent materials by origin, mass fraction, recycled content and hazard status. Each Material carries a materialType classification and an originCountry. For the constituent parts, see Components and Spare Parts below.

Where a material contains a substance on a regulatory candidate list above that list's threshold, it is declared with substanceOfConcern (DPP-19). The hazardous boolean remains a coarse screening flag; substanceOfConcern is the structured form, naming the substance, the list it is declared against, its concentration and where it sits.

"materialProvenance": [
  {
    "name": "Cobalt sulphate",
    "originCountry": { "countryCode": "CD", "countryName": "Congo (Democratic Republic of the)" },
    "materialType": {
      "type": ["Classification"],
      "code": "14210",
      "name": "Cobalt ores and concentrates",
      "idScheme": {
        "type": ["IdentifierScheme"],
        "id": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
        "name": "UN Central Product Classification (CPC)"
      }
    },
    "massFraction": 0.05,
    "mass": { "value": 22.5, "unit": "KGM" },
    "recycledMassFraction": 0.16,
    "hazardous": true,
    "substanceOfConcern": [
      {
        "type": ["SubstanceOfConcern"],
        "id": "https://echa.europa.eu/substance-information/-/substanceinfo/100.209.023",
        "name": "Cobalt sulphate",
        "substanceIdentifier": "10124-43-3",
        "idScheme": {
          "type": ["IdentifierScheme"],
          "id": "https://commonchemistry.cas.org",
          "name": "CAS Registry Number"
        },
        "regulatoryList": {
          "type": ["Classification"],
          "code": "SVHC",
          "name": "Candidate List of substances of very high concern for Authorisation",
          "idScheme": {
            "type": ["IdentifierScheme"],
            "id": "https://echa.europa.eu/candidate-list-table",
            "name": "REACH Candidate List"
          }
        },
        "concentration": { "value": 4.8, "unit": "P1" },
        "substanceLocation": "Cathode active material"
      }
    ]
  }
]

concentration is optional — the figure is often commercially sensitive, and an entry in the array is itself the declaration that the substance is present above the list's threshold.

Components and Spare Parts

The includedComponent array is the product's bill of materials (DPP-20): the discrete parts it is assembled from, as distinct from the materials it is made of. Because a component is itself a product, each entry identifies it and links to its own passport where one exists, rather than restating its content.

"includedComponent": [
  {
    "type": ["Component"],
    "id": "https://id.gs1.org/01/09520123456788",
    "name": "Lithium-ion cell module, 6.25 kWh",
    "idScheme": {
      "type": ["IdentifierScheme"],
      "id": "https://id.gs1.org/01/",
      "name": "GS1 GTIN"
    },
    "quantity": { "value": 12, "unit": "H87" },
    "componentPassport": {
      "linkURL": "https://credentials.example.com/dpp/cell-module-6250",
      "linkName": "Cell module passport",
      "linkType": "https://test.uncefact.org/vocabulary/link-type/dpp"
    },
    "sparePart": true,
    "availabilityPeriod": { "startDate": "2026-03-01", "endDate": "2036-03-01" }
  },
  {
    "type": ["Component"],
    "name": "Structural pack housing",
    "quantity": { "value": 1, "unit": "H87" },
    "sparePart": false
  }
]

Only name is required, so a component with no identifier or passport of its own is still worth listing — a reader learns the product contains it, how many, and whether it can be replaced. sparePart and availabilityPeriod carry the repairability information (DPP-21): a spare part is simply a component that can be bought separately, so there is one list rather than two that can disagree.

Characteristics

The characteristics property is an open extension point for industry-specific product attributes not covered by the core model. The schema uses additionalProperties: true, so any key-value pairs can be added. For a battery passport, this is where technical specifications like chemistry, voltages, capacity, resistance, and lifetime parameters belong.

"characteristics": {
  "type": ["Characteristics"],
  "batteryChemistry": "NMC 811 (LiNi0.8Mn0.1Co0.1O2)",
  "batteryCategory": "EV",
  "ratedCapacity": { "value": 150, "unit": "Ah" },
  "certifiedUsableEnergy": { "value": 75, "unit": "kWh" },
  "nominalVoltage": { "value": 400, "unit": "V" },
  "minimumVoltage": { "value": 280, "unit": "V" },
  "maximumVoltage": { "value": 450, "unit": "V" },
  "originalPowerCapability": { "value": 250000, "unit": "W" },
  "expectedLifetimeYears": 15,
  "expectedLifetimeCycles": 1500,
  "capacityThresholdForExhaustion": 80,
  "temperatureRangeIdleState": { "lower": -20, "upper": 50, "unit": "CEL" },
  "initialRoundTripEnergyEfficiency": 95,
  "warrantyPeriodMonths": 96
}

Packaging and Labels

The packaging property describes the product’s packaging including its own dimensions, materials, and performance claims. The productLabel array carries images of certification marks or regulatory labels that appear on the product — such as the CE marking, separate collection symbol, and carbon footprint performance class label required by the EU Battery Regulation.

"packaging": {
  "description": "Reinforced steel transit crate with foam inserts",
  "dimensions": {
    "weight": { "value": 35, "unit": "KGM" },
    "length": { "value": 2300, "unit": "MMT" },
    "width":  { "value": 1700, "unit": "MMT" },
    "height": { "value": 350, "unit": "MMT" }
  }
},
"productLabel": [
  { "name": "CE Marking", "description": "EU conformity marking for the battery pack" },
  { "name": "Separate Collection Symbol", "description": "Crossed-out wheeled bin per EU Battery Regulation Article 13" },
  { "name": "Carbon Footprint Performance Class", "description": "Battery carbon footprint class label (Class B)" }
]

Performance Claims

The performanceClaim array carries the supplier’s self-declared claims. Each Claim references criteria classified by a ConformityTopic from the Conformity Topics taxonomy and carries quantified performance using a PerformanceMetric from the Performance Metrics taxonomy. Claims can reference applicable regulations and standards, and SHOULD link to independent conformity assessments as evidence. Performance can be expressed as a numeric measure, a categorical score, or both.

"performanceClaim": [
  {
    "type": ["Claim"],
    "id": "https://sample-battery.example.com/claims/battery-carbon-2025",
    "name": "Battery Carbon Footprint",
    "referenceRegulation": [
      {
        "id": "https://eur-lex.europa.eu/eli/reg/2023/1542/oj",
        "name": "EU Battery Regulation (EU) 2023/1542"
      }
    ],
    "referenceCriteria": [
      {
        "id": "https://sample-scheme.responsiblebusiness.org/criteria/ghg-reporting/v8",
        "name": "GHG Emissions Reporting (RBA Code of Conduct Section C.1)"
      }
    ],
    "claimedPerformance": [
      {
        "metric": {
          "id": "https://vocabulary.uncefact.org/performance-metrics/product-carbon-footprint",
          "name": "Product Carbon Footprint"
        },
        "measure": { "value": 61, "unit": "KGM" },
        "score": { "code": "B", "rank": 2, "definition": "Carbon footprint performance class B" }
      }
    ],
    "evidence": [
      {
        "linkURL": "https://credentials.sample-cab.example.com/dcc/carbon-verification-bat-75kwh",
        "linkName": "Carbon Footprint Verification — Sample CAB",
        "linkType": "https://test.uncefact.org/vocabulary/link-type/dcc"
      }
    ],
    "conformityTopic": [
      {
        "type": ["ConformityTopic"],
        "id": "https://vocabulary.uncefact.org/conformity-topics/greenhouse-gas-emissions",
        "name": "Greenhouse Gas Emissions"
      }
    ]
  }
]

Referencing Conformity Criteria

Claims SHOULD unambiguously reference a criterion from a recognised scheme, standard, or regulation using a URI. This shared reference is what allows independent conformity assessments to verify supplier claims — both reference the same criterion. Issuers can discover the right criterion URIs via the UNTP Conformity Vocabulary Catalog.