Skip to main content
Version: Work in Progress
UNTP Public Review
Public review has now closed. The UNTP team is working through the review comments and expects to release UNTP version 1.0 by 1 September 2026.

Jurisdictional Extension

info

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

Overview

A growing number of jurisdictions are introducing regulated digital product passports: mandatory regimes that require a defined set of product data to be lodged, carried, and disclosed before goods may be placed on that market. Each arrives with its own attribute set, its own registry or lodgement process, its own data carrier, and its own rules about who may see what. The EU Digital Product Passport is the most developed of them, but it is one instance of a pattern that will repeat, not the pattern itself.

UNTP does not compete with these regimes. It is the layer they can be built on.

Alignment does not mean identical requirements. It means the same identifiers, the same credential format, and the same traceability semantics — so that a regulator's specific requirements become an extension on a common base rather than a separate reporting regime.

That distinction matters most for the actors furthest from any regulated market. Most of the world's primary production is not destined for a single jurisdiction, and much of it will never enter a market with a passport mandate at all. A base layer defined as "the upstream feed for one jurisdiction's regulation" is of little use to a cooperative selling into domestic and regional markets — yet that same cooperative benefits from verifiable conformity data wherever the goods end up. UNTP is designed for that case first. Market-entry compliance is a consequence of the design, not its purpose.

This page describes why jurisdiction-specific data requirements cannot be pushed upstream, how the work divides between primary producers and market-entry operators, and where alignment is genuinely at risk.

Challenges

Obligations attach at market entry; the data originates upstream

Regulatory obligations attach at market entry, to the economic operator placing the product on the market. But the data those obligations need originates upstream, with actors who are not economic operators in that market and who often have no idea which market the product will end up in.

  • A grain lot is binned with other lots at the silo and split across five destinations.
  • Livestock are sold at auction to a buyer the producer never meets, for an end market the producer is never told.
  • Concentrate from several mines is blended at the smelter, and the resulting cathode is sold on an exchange.

At the moment of production, the jurisdiction-specific requirement is genuinely unknowable. A regulation that pushes its bespoke schema upstream is asking the producer to answer a question that does not yet have an answer.

This is a logical problem before it is an economic one, and the distinction is worth holding onto. The obstacle is not the cost of completing a schema; it is that nobody upstream yet knows which schema applies. That is settled only when the destination market is chosen — several transactions later, and by someone else. Simplifying or subsidising the reporting burden therefore does not fix it, because what is missing is knowledge of the destination, not the capacity to report.

Bespoke upstream schemas multiply

Where a jurisdiction defines its own upstream data requirements, an upstream actor supplying several markets faces one schema per market — and must decide, at production time, which ones to populate. Most of that work is wasted, because most of those destinations never eventuate for any given lot. The burden lands hardest exactly where data capability is thinnest, and it produces worse data rather than better: a schema completed speculatively by an actor who cannot verify which rules apply is a guess dressed up as a disclosure.

Regulated markets are a subset, not the whole picture

A significant share of global trade never touches a jurisdiction with a passport mandate. South-South trade, domestic value chains, and commodity flows into unregulated markets all have real transparency problems — buyer due diligence, finance, fraud, greenwashing — that verifiable credentials address. If the shared base layer is shaped around one regulation's obligations, those actors are asked to adopt someone else's compliance regime to solve their own problem. They will decline, and the upstream data that regulated markets depend on will not exist.

Solution

A common base with jurisdiction-specific extensions

Three things have to be shared for a regulation to be an extension rather than a separate regime:

  • The same identifiers — resolvable, verifiable identifiers for products, facilities, and parties, so that a claim made upstream can be linked to the product presented at the border. See Identity Resolver.
  • The same credential format — one verifiable credential profile, one signature suite family, one rendering mechanism, so a credential issued anywhere can be verified anywhere. See Verifiable Credentials.
  • The same traceability semantics — a shared meaning for production, movement, and transformation events, for mass balance, and for conformity claims and their evidence. See Digital Traceability Events and Conformity Credential.

Everything else a regulator needs — a mandated attribute set, registry lodgement, a specific data carrier, access-control tiers — sits above that base as an extension. The Extensions Methodology makes this structural rather than aspirational: extensions are additive, must not redefine core properties, and must validate against both the extension schema and UNTP core. A credential that satisfies a jurisdictional extension is by construction still a UNTP credential, readable by any other jurisdiction's systems.

The division of labour

The primary producer publishes once: conformity credentials, emissions, land use, and the identity of the lot, in UNTP form. Downstream operators do the jurisdiction-specific work, because they are the ones with the market knowledge and the legal obligation.

QuestionWho can answer itWhere the answer lives
What happened on this farm or in this facility, and who verified it?Primary producerUNTP DPP, DCC, DFR, DTE, issued once
Which market is this consignment entering?Market-entry operatorDetermined downstream, often several transactions after production
Which attribute set, registry, and data carrier does that market require?Market-entry operatorJurisdictional extension applied to the market-facing passport
Which data is public, which is restricted, which is authority-only?Market-entry operator, under jurisdiction rulesAccess-control tiers on the market-facing passport

This does not let producers off the hook. They still answer for their own operations — what they did, what was measured, who assessed it — and those are the questions they are uniquely able to answer. What changes is who translates that evidence into a particular jurisdiction's reporting form. The producer's credential is an input that downstream operators consume and reference, not a document whose shape they get to dictate.

The practical consequence is that upstream investment is not stranded. A producer who issues UNTP credentials for a domestic buyer has already done the work required when a lot is later exported, and has done it once rather than once per destination.

Central registries are a market-entry control, not a data model

A central registry is a mechanism for controlling who may place goods on a market. UNTP neither requires nor prohibits one. It does not assume a registry exists, because there is no global central register to assume — which is why identity binding in UNTP is done with verifiable credentials and resolvers rather than by registry lookup.

That is not a conflict. A jurisdiction that operates a registry can hold a registry entry which points at, or resolves to, a UNTP product passport. The registry governs market access; the passport carries the evidence. The two mechanisms answer different questions and can coexist without either giving ground.

Where alignment is genuinely at risk

Alignment is not automatic, and claiming seamless compatibility does more harm than good with a technical audience. Three areas are real divergence risks:

  • Mandated identifier schemes. UNTP is deliberately scheme-agnostic and requires only that schemes used by extensions be registered in the identifier scheme register. A regulation that mandates one scheme for every actor in the chain, including upstream actors outside its jurisdiction, removes the "publish once" property that makes the base layer worth adopting. Mandating a scheme at market entry is a legitimate control; mandating it at the point of primary production is the same category error as mandating the schema.
  • Mandated data carriers. Requiring a specific carrier or resolution API on goods entering a market is a reasonable market-entry control. Pushing that requirement upstream, to actors labelling goods for many destinations, is not.
  • Tiered access control. Public, restricted, and authority-only tiers are central to most passport regulations, and UNTP has to model them credibly or the extension story breaks down: an upstream credential published as a single public document cannot serve a regime that requires authority-only fields. Variant-Based Disclosure and Decentralised Access Control are the current answer, but they are best-practice guidance rather than a settled normative model. Hardening them is a precondition for the alignment claim, not a detail to be resolved later.

Naming these openly is the honest position, and the more useful one. Alignment is a design goal that has to be actively maintained on both sides — not a property UNTP acquires for free.

Examples

Mapping a jurisdiction's attribute set onto the core

The DIN DKE SPEC 99100 battery passport specification — the German standard implementing the EU Battery Regulation — defines 88 mandatory and recommended data attributes. Every one of them maps onto the UNTP core model with no gaps, as direct properties, product characteristics, performance claims, lifecycle events, or related documents. The attribute-by-attribute mapping is published alongside the DPP specification.

That mapping is the concrete form of the argument on this page. The regulation's requirements did not need a separate schema; they needed a required subset of a common one, plus the market-entry obligations that only the operator placing the battery on the EU market can discharge.