Sovereignty and Jurisdiction

info

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

Overview

UNTP has no central data store. Each issuer publishes its own credentials, under its own identifier, from infrastructure it chooses. That is a good starting point for a government assessing adoption, because nothing in the protocol requires national data to sit in a system someone else operates.

Decentralised data does not by itself settle who controls what. An issuer may use a service provider that hosts elsewhere. An identifier register may keep its own copy of metadata about products it has numbered. A resolver that answers "where can I find the passport for this identifier" is a hosted service running somewhere, under some law. And a due-diligence obligation in an importing country can require evidence that an exporting country forbids from leaving.

This page is guidance, not specification. It takes six questions that come up in a cross-border UNTP deployment and, for each, sets out the problem, what the protocol offers, and a worked case. It does not prescribe national policy, resolve conflicts of law, or offer a legal opinion. Requirement SC.01 already states that conformance implies no obligation to store or process data outside a jurisdiction the data owner chooses; everything here builds on that rather than restating it.

Regulated passport regimes, and how a jurisdiction's own attribute set extends the common model, are covered separately in Jurisdictional Extension. The last two sections cover what a corridor agreement between two jurisdictions has to settle, and the questions UNTP does not answer at all.

Identity assurance across a border

Challenge

Before a verifier can act on a credential it has to know who issued it. Three arrangements are in use, and they place the identity assurance in different hands.

Identity carried in the credential. This is the basic UNTP model. The issuer signs the Digital Product Passport itself, and a verifier can scan a QR code on a carton, fetch the passport and check the signature with no register, platform or other intermediary involved. That alone establishes that whoever controls the signing identifier issued this passport, which is not yet the same as knowing who they are.

A linked Digital Identity Anchor closes that gap. Where a national business register has anchored the issuer's identifier to its registered identity, the verifier can follow a chain from the passport to an authority competent to say the company exists, and identity confidence is high. The assurance travels with the credential, so it holds wherever the passport is stored and whoever reads it.

Discovery mediated by an identifier register. This is the UNTP identity resolver pattern. An operator holds a relationship with a product or facility identifier register, the register performs some customer due diligence at enrolment, and the operator can then publish links only for identifiers it controls. Reaching a passport through the resolver therefore carries an implied assurance that somebody checked the publisher at some point.

How much assurance is the open question, and it reduces to how much know-your-customer work that register actually does, which varies widely between schemes and is rarely published. A resolver also returns any number of links, and only some of them need be UNTP credentials: a link may point at a product web page, a safety sheet or a marketing asset. For anything that is not a signed credential, the identity confidence is entirely a function of the registrar's enrolment process, because there is no signature to check.

A register operated by a public authority. A national or regional authority runs the register for product or facility information, takes enrolment, verifies the registrant's identity, and accepts lodged data. The EU Digital Product Passport regime is the most developed example. Assurance comes from the enrolment rather than from the credential, so a verifier that trusts the register needs little else.

This is strong where the registrant is established in the same jurisdiction as the register, because the authority can check it against its own records and act against it if the data is false. It is weaker for a foreign issuer, which the authority cannot verify as readily and may have no means to pursue. The usual mitigation is to require the foreign supplier to act through a locally established representative, which places a domestic party in the chain but does not give the authority any direct knowledge of the actor upstream of it.

Model	Where assurance comes from	Weakest point
Identity in the credential	The issuer's signature, plus a Digital Identity Anchor from an authoritative register	No anchor, or an anchor from a register the verifier does not recognise
Register-mediated discovery	The identifier register's enrolment due diligence	Unpublished and variable due diligence; unsigned resources carry no signature to check
Authority-operated register	The authority's own verification of the registrant	Foreign registrants, reached only through a local representative

A verifier in one country is therefore relying on a process run in another, and in two of the three cases cannot see what that process was.

Solution

The three models are not alternatives. They are three discovery paths, and a single product can sit on all of them at once: a QR code on the carton that resolves straight to the passport, a product identifier register whose resolver lists the same passport among its links, and a national register holding the lodged metadata that regulation requires. Most real deployments will be some mixture, and the mixture will change as a product moves between markets.

That is the reason for the single recommendation this section makes. All UNTP credentials SHOULD be issued as verifiable credentials, whichever path a verifier is expected to find them by. Once a passport carries its own signature and its own anchored identity, how it was reached stops mattering: direct from a carton, through a product identifier register, or out of a national register, the verifier performs the same checks and reaches the same conclusion. Identity assurance becomes a property of the credential rather than of the route.

The alternative is that assurance depends on the path, which has two costs. A credential that is only trustworthy because of where it was found cannot be relied on once it is copied, archived or passed on, and a verifier outside the arrangement that produced it has no way to evaluate it at all. And an authority that assures identity at enrolment is assuring it for its own constituency; that assurance does not travel, so the same product needs re-assurance in every market it enters.

A register loses nothing by this. An authority that verifies its registrants can keep doing exactly that, and signed credentials simply mean its registrants' data is also usable outside its jurisdiction. The two kinds of assurance compound rather than compete: the register's enrolment check and the credential's own anchor are independent reasons to believe the same thing.

Where a verifier does rely on the discovery path rather than on a signature, as it must for an unsigned resource returned by a resolver, it should treat the register's enrolment practice as the thing it is relying on. The resolver trust models section sets out what can and cannot be inferred from a resolver answer.

Example

An importing jurisdiction operates a mandatory product register. Domestic operators enrol, prove identity, and lodge passport metadata. An exporter in a second country, which has no such register, produces goods for that market.

The approach that does not scale is enrolling the exporter in the importing jurisdiction's register, directly or through a local delegate, because the exporter would repeat it for every market it sells into.

What works instead: the exporter issues a Digital Product Passport signed under its own identifier, anchored by a Digital Identity Anchor from its national business register. The local economic operator placing the goods on the market lodges whatever the register requires, referencing the exporter's passport rather than restating it. The importing jurisdiction decides once whether it recognises that national business register, not once per exporter. Market-entry obligations stay with the party that holds them, which is the division of labour described in Jurisdictional Extension.

Identifiers that outlive their infrastructure

Challenge

did:web and did:webvh resolve over DNS and HTTPS. A domain can be suspended, a certificate revoked, and a /.well-known/ path blocked at a border. Any of those makes an identifier unresolvable, and credentials signed under it then fail to verify no matter how sound their cryptography. For credentials meant to last a decade this is a real exposure, and not one the credential's own integrity protects against.

Solution

did:webvh keeps a signed history, so a preserved copy of that history still shows what the key material was. That is what verification dependency closure addresses, and the dependency list in that section is the list of things a long-lived deployment needs a continuity answer for.

What a preserved copy cannot show is that a key was genuine at a point in time, because establishing that requires resolving the live source. Archiving the credentials alone is not enough, and a deployment that assumes otherwise has a gap it will discover late.

UNTP's list of recommended DID methods is not closed. Whether methods that do not depend on global DNS should be recommended is under discussion rather than settled.

Example

A mine issues facility records and traceability events in 2027 under a did:webvh on its own domain. In 2034 a regulator reviewing a battery's provenance needs to verify a credential from that original production run. The mine has since been sold and the domain has lapsed.

Because the identifier was did:webvh, a downstream custodian that archived the DID history alongside the credentials can still show which key signed, and that the history is internally consistent and unbroken up to the point it was captured. What nobody can now establish is whether that domain was genuinely under the mine's control in 2027, because the live source is gone. The regulator's confidence therefore rests on the custodian's capture rather than on resolution, which is a weaker position and one worth entering deliberately rather than by accident. A corridor that expects decade-long retrospective verification should say who captures what, and when.

Where the data actually lives

Challenge

The issuer hosting its own credentials is the default, and for most issuers that means hosting at home. Two other copies are easy to miss. An issuer may use a service provider that hosts in another country, including a provider that operates its identifier or signs on its behalf. And an identifier register commonly keeps its own record of what it has issued, so some metadata about a product or facility exists in the register as well as in the passport.

Resolvers are a third location, and the one UNTP has so far said nothing about. A resolver is the discovery path for every credential under a scheme, so whoever operates it can observe who is asking about what, and can stop answering. Query patterns are information in their own right: encrypting a payload does not conceal that someone asked for it.

Solution

An issuer subject to a residency obligation should treat the hosting location of any provider it uses as in scope of that obligation. Delegating the operation of an identifier does not delegate the obligation, and the arrangements that make delegation visible to a verifier are set out under identifier control and key custody.

Two recommendations follow for registers and resolvers. Both are a change of posture rather than a clarification of existing text:

• A resolver serving identifiers issued under a national scheme SHOULD be operated within that jurisdiction, or under an arrangement that jurisdiction has accepted.
• A register SHOULD publish what metadata it retains about the identifiers it issues, and for how long. A verifier cannot assess its exposure to a register's holdings without knowing what they are.

Who bears responsibility for published UNTP data, and what happens when a hosting platform makes data inaccessible, are governance questions rather than protocol ones. They are open and tracked separately.

Example

A national agency adopts UNTP and satisfies itself that the arrangement is compliant with domestic residency law because every passport is published by a domestic issuer.

A closer look finds three further copies. Most of the smaller issuers use one software provider, which operates their identifiers and signs on their behalf from infrastructure in another country, so the signing keys and the DID documents are both offshore. The product identifier scheme the sector uses holds its own record of every identifier it has issued, including the product descriptions lodged at enrolment, under the law of the country where that scheme operates. And the resolver those identifiers point at is run by the scheme rather than by the agency, so every query about a domestic product is observable abroad.

None of this is a protocol failure, and the metadata involved is mostly not sensitive. But the residency assessment was wrong, and it was wrong because it counted the passports and nothing else. The fix is partly contractual, partly a decision about who runs the resolver.

Due diligence against data localisation

Challenge

A due-diligence regime in an importing country can require evidence that an exporting country requires to stay put. Several jurisdictions restrict the export of supply chain information they treat as sensitive or strategically significant. Both obligations are real law, and neither yields to the other.

Solution

UNTP cannot resolve a conflict between two bodies of law. What it can do is remove the need for the evidence to travel. An accredited assessor inside the jurisdiction holding the data examines it and issues a signed conclusion; only the conclusion crosses the border. The assessment commits to the evidence by digest, so a regulator can audit the assessor afterwards without the data having moved. That pattern and the two weaker ones beside it are described in Privacy-Preserving Verification, and it is the same mechanism the UN/CEFACT Digital Product Passport business requirements call trusted source-based verification.

This is the most useful thing to understand about UNTP and data localisation. A verifier usually needs a reliable answer rather than the underlying records, and an attestation from an accountable party is an answer that can cross a border when the records cannot.

Which disclosure level suits which class of interaction, regulatory against commercial against financial, is a governance judgement that UNTP provides the mechanisms for but no guidance on; the mechanisms are in Decentralised Access Control. Whether UNTP should publish a profile for a specific data-protection regime, rather than generic guidance, is an open request.

Example

A refinery operates in a jurisdiction that treats smelter input volumes and supplier identities as commercially and strategically sensitive, and prohibits their export. A battery manufacturer in an importing jurisdiction is subject to due-diligence rules requiring assurance that the refinery's inputs were responsibly sourced.

Publishing the traceability events would satisfy the importer and breach the exporter's law. Withholding them satisfies the exporter and leaves the importer unable to meet its obligation.

The refinery records its input shipments, production runs and output shipments as traceability events held under its own control, in jurisdiction. An assessor accredited in that jurisdiction examines the full set and issues a conformity credential attesting that output claims never exceed verified inputs, with a digest committing to the evidence bundle it examined. The battery manufacturer receives and verifies that credential. The events never cross the border, the importer has assurance it can act on, and if the attestation is later doubted the exporting jurisdiction's regulator can audit the assessor against the committed bundle.

Personal data in smallholder supply chains

Challenge

Most UNTP data is about products, facilities and organisations. Some is not. In supply chains based on smallholder production, the data that demonstrates compliance can identify individuals: a farmer, a plot, a household. Treating that as ordinary business confidentiality understates it, because the risk to an individual from disclosure differs in kind from the risk to a company.

Durable storage sharpens the problem, since content-addressable storage is designed not to forget and a right to erasure assumes something can be removed.

Solution

Carry an aggregate or an attestation where one will do, and keep individual-level records inside the jurisdiction and the organisation that collected them. Access control alone is a weaker answer here than derivation or masking, because granting a role access to personal data is still a decision about who may see an identified person, taken by whoever holds the data rather than by the person it concerns.

Personal data and the right to erasure sets out how to keep a graph verifiable after personal data is removed from it, which is the part that has to be designed in rather than retrofitted.

Example

A cooperative aggregates production from several hundred smallholders. Demonstrating deforestation-free sourcing requires plot boundaries and household-level records, which identify individuals, and the cooperative is both unwilling and in some cases not permitted to publish them.

The cooperative publishes a facility record and a conformity credential covering its aggregate production. An assessor accredited in the cooperative's own country examines the plot-level evidence on site and attests that the production is deforestation-free, committing to the evidence bundle by digest. The individual records never leave the cooperative. A buyer downstream receives an attestation it can verify and act on, and a regulator that doubts the attestation can audit the assessor rather than demand the underlying data. Because the personal data was never published, no erasure request can reach an immutable store.

Recognising another jurisdiction's registers

Challenge

The alternative to trusting another jurisdiction's registration is duplicating it. An exporter cannot enrol in a register operated by every country it sells into, and in some cases may not lawfully do so. Every importing jurisdiction verifying every foreign supplier itself produces identity assurance work that no register is resourced for, repeatedly, for the same supplier. The same holds for conformity: requiring re-verification of an assessment already performed to an international standard doubles the cost and changes the answer rarely.

Solution

A jurisdiction should rely on the registration performed by the authority actually competent to perform it. A company's own national business register knows whether that company exists, and no foreign register can know it better.

What a verifier needs is a way to tell which registers those are. grid.unece.org provides that for registers operated by authorities in member states, and the UNTP implementation registers do so for well-governed schemes that are not government-operated. The distinction is set out under authoritative registers.

For conformity, what UNTP changes is that the basis for a recognition decision becomes machine-readable. A conformity credential names the scheme, the criteria and the accreditation behind the assessor, so an importing authority can apply its own recognition rules automatically instead of requiring a fresh assessment by default. Recognition still has to be granted, and remains a matter of law or trade agreement rather than of protocol. UNTP makes it cheap to act on once it is.

Example

An exporter holds a greenhouse gas verification statement from a validation body accredited in its own country against the relevant ISO standard. The importing jurisdiction has historically required verification by a body it accredits itself, so the exporter faces a second verification of the same emissions.

UNTP does not make the importing jurisdiction accept the original. What it does is carry the statement as a conformity credential naming the standard assessed against, the criteria, and the accreditation held by the assessor, with that accreditation anchored to the accreditation body that granted it. An importing authority can then encode its own recognition rule, for example that it accepts statements from bodies accredited by a signatory to the relevant multilateral recognition arrangement, and apply it on arrival. The decision stays the importing jurisdiction's; the cost of acting on it falls to close to zero.

What a corridor agreement needs to settle

Two jurisdictions running a trade corridor on UNTP will generally want something written down between them. UNTP does not draft that agreement. It is an instrument between governments and the protocol has no standing to recommend its terms. What the protocol can usefully do is name the questions it leaves open, because those are the ones the agreement has to close:

• Which registers each side recognises, for identity and for conformity, and how a register is added to or removed from that list.
• Who operates the resolvers for each side's identifier schemes, where they run, and what happens to discovery if one side's resolver becomes unavailable.
• What metadata each side's registers retain, for how long, and who may query them.
• Which data may cross the border directly, and which must be handled by assessment inside the jurisdiction of origin.
• How long credentials and their supporting evidence must remain retrievable, and who is responsible when an issuer ceases to exist.
• How a dispute about a credential is raised and resolved, and what follows for a participant found to have published false data.

None of these has a protocol answer. All of them have a protocol mechanism the answer can be expressed in terms of, which is the point of settling them against a common specification rather than bilaterally from scratch.

What this page does not answer

UNTP cannot say whether a given access-control arrangement is adequate under a particular data-protection law. It can say that a payload is encrypted and that a key was released to a named role; whether that constitutes adequate control is a question for the law in question and the regulator applying it.

It cannot resolve a conflict between two jurisdictions' requirements. It can reduce how often one arises, by making an attestation serve where evidence cannot travel.

It cannot make one jurisdiction recognise another's registers or certificates. It can make the basis for recognition explicit enough to act on.