# UN Transparency Protocol

> Supporting governments and industry on practical measures to counter greenwashing by implementing supply chain traceability and transparency at the scale needed to achieve meaningful impacts on global sustainability outcomes.

This file contains all documentation content in a single document following the llmstxt.org standard.

## Audience

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

*Informative*

# UNTP — Who It's For

UNTP creates value differently depending on where an organisation sits in the value chain. The table below identifies each audience type and summarises the core benefit. Select your audience to go directly to the full description.

| Audience | Core Benefit |
|---|---|
| [Primary Producers & Manufacturers](#primary-producers--manufacturers) | Attach verified ESG evidence to every shipment, making it easier for customers to buy from you, harder for competitors to undercut on false claims, and simpler to meet export market requirements. |
| [Brands & Retailers](#brands--retailers) | Verify supplier ESG claims, meet due diligence obligations, and issue consumer-facing product passports — without locking your supply chain into a specific software system. |
| [Regulators](#regulators) | Issue verifiable digital identity and compliance credentials that reduce border friction for trusted traders, enable automated ESG compliance checks, and lower compliance costs for domestic industry. |
| [Financial Institutions](#financial-institutions) | Access the digital ESG evidence needed to release trade finance payments with confidence and link operational sustainability data directly to IFRS-based investment decisions. |
| [Accreditation & Certification Organisations](#accreditation--certification-organisations) | Make the chain of trust behind conformity certificates digitally verifiable, strengthening the value of accreditation credentials and differentiating certifiers who adopt UNTP. |
| [ESG Standards Organisations](#esg-standards-organisations) | Publishing ESG criteria as machine-readable vocabularies enables digital verification of conformity credentials and makes those credentials unambiguous and auditable. |
| [Industry Associations](#industry-associations) | Support members through industry-specific implementation profiles and training services, while gaining a new tool to combat fraud and protect sector integrity. |
| [Environmental & Human Welfare Organisations](#environmental--human-welfare-organisations) | Issuing UNTP accreditation credentials extends your trust mark into the digital verification infrastructure underpinning sustainable trade. |
| [Circular Performance](#circular-performance) | Make recycled-content claims verifiable, enabling manufacturers to meet mandatory thresholds and giving recyclers a way to demonstrate the value of their output. |
| [Transport & Logistics Providers](#transport--logistics-providers) | Make transport ESG credentials discoverable through consignment identifiers, positioning low-emission services to capture growing demand from sustainability-focused shippers. |
| [Consumers](#consumers) | Verify sustainability claims and product authenticity by scanning a barcode, shifting purchasing power toward products with credible ESG performance. |
| [Software Developers](#software-developers) | UNTP is a new capability requirement across ERP, ESG management, and traceability platforms — developers who implement it early serve a market growing with regulatory demand. |
| [Service Providers](#service-providers) | Build UNTP implementation skills now to serve the tens of millions of businesses that will need support integrating UNTP into existing systems. |

---

## Primary Producers & Manufacturers 

**Summary:** UNTP lets producers and manufacturers attach verified ESG evidence directly
to product shipments, making it easier for customers to buy from them, harder for
competitors to undercut them on false sustainability claims, and simpler to meet export
market requirements.

Most physical products derive from materials grown above ground or extracted below it.
Primary producers — farmers and miners — represent the starting point for most supply
chains. Manufacturers take raw or recycled materials and produce intermediate components
or final products. Together, they form the upstream feedstock supply chain for branded
consumer products.

- When producers and manufacturers issue B2B digital product passports (DPPs) and
  link them to every shipment, they provide customers with data — such as Scope 3 CO₂
  emissions — at the right granularity to incorporate into their own product environmental
  footprint.
- When producers and manufacturers issue UNTP traceability events linked to product
  passports, they provide evidence of provenance, supporting supply chain resilience and
  informing preferential treatment decisions by customers and export market regulators.
- When producers and manufacturers link third-party UNTP conformity credentials to their
  DPPs, they add credibility to their ESG claims, enhancing product value and market
  access.
- By issuing complete collections of passports, traceability events, and conformity
  credentials linked to product shipments, producers and manufacturers enable their
  downstream customers to meet ESG due diligence obligations easily and verifiably.
- When producers and manufacturers link their issuer identity to a strong identity
  credential — such as a government business registration or trademark ownership
  credential — and implement the UNTP anti-counterfeiting mechanism, they add robust
  anti-fraud protection and preserve the value of their sustainability investments.

UNTP confidentiality measures allow supply chain actors to selectively redact upstream
credentials before passing them downstream, enabling ESG evidence to be shared without
exposing commercially sensitive information.

---

## Brands & Retailers

**Summary:** UNTP gives brands and retailers a platform-neutral way to verify supplier ESG
claims, meet due diligence obligations, issue consumer-facing product passports, and
protect against counterfeiting — all without locking their supply chain into a specific
software system.

Consumer-market sales are heavily regulated in most developed economies, and other
economies are introducing digital product passport requirements to support informed
consumer choice and improve circularity. The threat of reputational damage and high fines
motivates brands and retailers to embed sustainable practices throughout their operations
and their entire supply chain.

1. When brands and retailers verify UNTP credentials linked to shipments from upstream
   suppliers, they can meet their due diligence obligations with confidence and obtain the
   verifiable information needed to issue consumer-centric digital product passports
   required under domestic regulations. UNTP is designed to complement, not conflict
   with, local laws. When international brands and retailers issue UNTP product passports,
   conformity credentials, and traceability events across all markets, they give consumers a
   consistent way to discover and verify ESG performance, establishing a strong framework
   for compliance with current and emerging regulations.

2. When brands and retailers request UNTP credentials from their upstream suppliers,
   they avoid imposing specific traceability software on their supply chain. They request
   conformance with a common standard, irrespective of software platform. Brands and
   retailers that have already invested in global identifier schemes can use the UNTP
   global identifier scheme binding to build on and reuse those existing assets.

3. When brands and retailers link their issuer identity to a strong identity credential — such
   as a government business registration or trademark ownership credential — and
   implement the UNTP anti-counterfeiting mechanism, they add robust anti-fraud
   protection and preserve the value of their sustainability investments.

---

## Regulators

**Summary:** UNTP lets regulators issue verifiable digital identity and compliance
credentials that reduce border friction for trusted traders, enable automated ESG compliance
checks, and lower compliance costs for domestic industry — while improving the integrity of
enforcement.

Regulators set rules, issue permissions, and manage compliance. UNTP enhances the value
of the permissions they issue and the efficiency and integrity of compliance operations.

When regulators issue digital, verifiable identity credentials under UNTP, they enable trading
businesses to attach strong, verifiable identity to their supply chain transactions. A verifiable
identity can facilitate green-lane pre-clearance at the import border, allowing trusted traders
with a good compliance record to clear customs more quickly and with less scrutiny — which
increases lending confidence among financial institutions. When ESG permits and
certificates are issued digitally, traders can attach that evidence to their transactions.
Regulators acting as digital trust anchors improve their trade balance by expanding export
market access and trade finance for their traders.

- By verifying increasingly transparent supply chain data, regulators can automate
  compliance assessments for most trade transactions rather than relying on unverifiable
  claims in regulatory reports audited at high cost. This leaves a much smaller volume of
  trade for manual enforcement.

National regulators developing environmental initiatives — such as consumer-centric digital
product passports — should base those initiatives on UNTP. Alignment with UNTP draws on
a tested body of work and significantly reduces compliance costs for domestic industry.

---

## Financial Institutions

**Summary:** UNTP product passports and conformity credentials give banks the digital ESG
evidence they need to release trade finance payments with confidence and to link
operational sustainability data directly to IFRS-based investment decisions.

Financial institutions face increasing pressure from regulators and investors to offer
favourable terms to sustainable businesses. Just as financial transactions — bills, invoices,
payments — aggregate into profit-and-loss statements and balance sheets, corporate
sustainability metrics are derived from operational data, including UNTP digital product
passports. At the consignment level, trade finance instruments such as documentary letters
of credit typically require compliance documentation before payment is released. Where
goods are held at the border for non-compliance with ESG regulations, financial institutions
require evidence of ESG compliance before releasing funds.

- UNTP product passports and conformity credentials enable banks to digitally verify ESG
  compliance for shipments covered by letters of credit, allowing payments to be released
  with greater confidence.
- When banks provide investment capital based on sustainability criteria, a direct link
  between UNTP-based operational processes and IFRS-based corporate ESG
  performance reduces the financial risk of the investment.

---

## Accreditation & Certification Organisations

**Summary:** UNTP makes the chain of trust behind conformity certificates digitally
verifiable — strengthening the value of accreditation credentials and making certifiers who
issue UNTP-standard digital credentials preferred over those who do not.

A global conformity assessment framework has operated for over 50 years. Independent
third parties (certifiers) assess products against recognised standards and issue conformity
certificates. A global network of mutually recognised national accreditation authorities
assesses those certifiers, ensuring that qualified organisations issue the certificates.

UNTP increases the verifiability of claims and disclosures through multiple verification
mechanisms, ensuring that claims rest on reliable, verifiable evidence covering the integrity,
provenance, and legitimacy of both the claims and the entities making or supporting them:

- Any assessments used to support a claim — such as certification — are conducted by
  parties holding appropriate authorisation and accreditation.
- Any certificate provided in support of a claim can be reliably linked to the product in
  question and has not been altered since issuance.

UNTP does not require every product claim to be third-party assessed, nor every third-party
certifier to be formally accredited. It does make the chain of trust visible where it exists, and
recognises less formal but still valuable chains of trust. A farmer's environmental land
management claims, for instance, might be verified by a community organisation endorsed
by a well-known global environmental body.

- When national accreditation authorities issue their accreditations as UNTP standard
  digital credentials, they create a digital identity anchor that enables verifiers of ESG
  conformity certificates to determine whether a given certificate can be trusted.
  Implementing UNTP enhances the value of both the certification and the accreditation
  authority's trust mark.
- When certifiers issue their ESG certificates as UNTP-standard digital credentials, they
  enable verifiers to confirm authenticity, integrity, and validity. A digital conformity
  certificate that links to the accreditation credential establishes the entire digital chain of
  trust. Conformity assessment bodies that issue UNTP-standard digital credentials will be
  preferred over those that do not.

---

## ESG Standards Organisations

**Summary:** The key task for standards authorities under UNTP is to publish their ESG
criteria as machine-readable vocabularies — enabling digital verification of conformity
credentials and making those credentials unambiguous and auditable.

Standards organisations — national and international authorities and industry-led bodies —
govern arrangements that determine the legitimacy and value of published standards. Unlike
regulators, standards bodies do not manage compliance, which can be self-assessed or
third-party audited. Hundreds of organisations collectively issue thousands of ESG standards,
most published as PDF documents.

- When ESG standards organisations publish their criteria as a machine-readable
  vocabulary, they enable certifiers to issue digital conformity credentials that
  unambiguously reference the scope of conformity claims. Those credentials can then be
  digitally verified, improving the efficiency and reliability of the entire process.

Standards authorities generally do not issue, receive, or verify digital credentials. However,
when they also accredit third-party certifiers conducting conformity assessments, they
become issuers of accreditation credentials.

---

## Industry Associations

**Summary:** UNTP gives industry associations a concrete way to support members through
industry-specific implementation profiles and training services, while also creating a new
tool to combat fraud and protect the integrity of their sector.

More than 100,000 industry associations operate worldwide, most representing specific
sectors within particular jurisdictions. They advocate for members, provide best-practice
guidance, and often establish quality standards and branding that differentiate members'
products — such as genuine Manuka honey. They help members navigate domestic and
international ESG standards and, by addressing fraudulent practices promptly, protect the
industry's reputation.

- Associations can develop industry-specific UNTP profiles offering targeted
  implementation guidance that addresses the unique needs of each industry and
  jurisdiction.
- Associations can create training and implementation services in partnership with local
  service providers, generating revenue while ensuring members are equipped to meet
  ESG standards.
- Associations may also serve as trusted independent quota managers to combat mass
  balance fraud. Accreditation by a national accreditation authority or a global
  environmental or humanitarian organisation would strengthen the independence and
  integrity of this service.

---

## Environmental & Human Welfare Organisations

**Summary:** When influential ESG trust marks issue UNTP accreditation credentials, they
become identity anchors in the digital trust ecosystem — extending their brand power into
the verification infrastructure that underpins sustainable trade.

Many national and international non-profit organisations promote environmental and human
welfare. Some trust marks, such as WWF's, carry significant global brand recognition.
Although these organisations lack regulatory enforcement powers, they can strongly influence
market success. A product carrying the WWF logo is likely to attract more environmentally
conscious consumers. Conversely, revoking a trust mark over unsustainable practices can
reduce sales.

When influential ESG trust marks establish well-governed accreditation frameworks and issue
or revoke UNTP accreditation credentials, they become key players in the digital trust
ecosystem — trusted entities that vouch for the authenticity and sustainability of products or
practices, leveraging their brand power to promote sustainable production.

---

## Circular Performance

**Summary:** UNTP supports recyclers and remanufacturers by making recycled-content
claims verifiable — enabling manufacturers to meet mandatory recycled-content thresholds
and giving recyclers a way to demonstrate the value of their output.

Recyclers reprocess end-of-use-cycle products into secondary raw materials for new
manufacturing. Refurbishers, repairers, and remanufacturers restore damaged or broken
products for additional use cycles. As regulators enforce minimum recycled-content
requirements, the current linear model — produce, use, dispose — will require significant
changes. UNTP supports circular economies by including verifiable recycled-content
information in product passports and incentivising manufacturers to design for recyclability.

- When manufacturers design for recyclability and share that information through UNTP
  passports, they enhance the end-of-use-cycle value of their products. This enables
  recyclers — especially for high-value items like electric vehicle batteries — to improve
  the efficiency of their recycling processes.
- When recyclers issue UNTP passports for recycled-material shipments, they enable
  manufacturers to make verifiable claims about recycled content, reducing due diligence
  burden and compliance risk. Consumers can verify recycled-content claims on products
  with confidence.

---

## Transport & Logistics Providers

**Summary:** UNTP makes transport-related ESG credentials discoverable through
consignment identifiers, giving logistics providers a way to demonstrate and monetise their
sustainability performance as shippers increasingly factor emissions into procurement
decisions.

Cargo movement by sea, air, and land accounts for approximately 10% of global emissions
and is projected to represent the largest share of global emissions by 2050 if the sector does
not decarbonise.

Just as UNTP makes ESG credentials discoverable through product batch identifiers, it
enables discovery of ESG credentials for transport services through consignment identifiers
such as waybill numbers. Responsibility for including transportation in an ESG footprint is
assigned by INCOTERMS — whoever pays for transportation is accountable. This prevents
gaps and double-counting and aligns incentives correctly.

When transport and logistics providers issue UNTP transport credentials and link them to
consignment identifiers, they give customers quantifiable, verifiable transport-related ESG
metrics. As producers, manufacturers, brands, and retailers work to improve their
sustainability performance, they will choose low-emission transport services — increasing the
value of sustainable transport per tonne-kilometre.

---

## Consumers

**Summary:** UNTP lets consumers verify sustainability claims and product authenticity by
scanning a barcode — shifting purchasing power toward products with credible ESG
performance and away from greenwashing.

Consumer sentiment around sustainable production is strong, with more than 70% of
consumers in some economies actively choosing sustainable goods. Rising concerns about
greenwashing are undermining the value of sustainability claims. As UNTP and national
regulations gain adoption, consumers will become familiar with product passports and ESG
verification.

- When consumers can verify a product's sustainability performance by scanning barcodes,
  QR codes, or RFID tags, they are more likely to choose products with verifiable ESG
  qualities over those making unverifiable claims.
- When products carry UNTP anti-counterfeiting measures, consumers can verify both ESG
  performance and product authenticity, ensuring counterfeits do not devalue genuine
  sustainability investments.

---

## Software Developers

**Summary:** UNTP is a new capability requirement across ERP, ESG management, and
traceability platforms — developers who implement it early will serve a market that is
growing with regulatory demand.

Software developers provide the tools needed to issue UNTP credentials and consume data
from credentials that are discovered and verified. UNTP implementation scales to
organisation size: large companies with highly customised systems may tailor it to specific
needs; smaller organisations will likely treat UNTP compliance as a new feature on their
release roadmap.

- ERP systems are the primary issuers of UNTP product passports and recorders of
  traceability events, managing the financial and logistical operations behind manufacturing,
  sales, and shipment.
- ESG management systems contribute data — such as carbon intensity — included in
  UNTP product passports alongside conformity credentials.
- Traceability platforms map the upstream supply chain, enabling data collection via
  verifiable linked data trails without requiring direct enrolment of upstream participants.

These three system types may exist as standalone products or as part of integrated
solutions. ERP systems will likely evolve — through native features, acquisitions, or
partnerships — to offer this integrated capability to their customers.

---

## Service Providers

**Summary:** UNTP adoption by large and medium-sized businesses will require
implementation support — service providers and system integrators that build UNTP skills
now will have a competitive advantage in a rapidly growing market.

Hundreds of millions of micro and small businesses will adopt UNTP as a standard feature
of their chosen business software. Tens of millions of medium- and large-sized businesses,
however, will require substantial business analysis and systems integration, and will turn to
experienced service providers for support. Service providers that invest in UNTP
implementation skills can offer compelling packages to existing clients and use those skills
to reach new customer bases and markets.

---

## FAQ

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

# UNTP – FAQ's
## United Nations Transparency Protocol  – Frequently Asked Questions

This FAQ addresses common questions and misconceptions about the United Nations Traceability Protocol (UNTP) — focusing on its unique characteristics, development methodology, and safeguards against misuse. For technical or architectural documentation, please refer to the official UNTP specification.

---

## General Background – Purpose and Positioning

### Is UNTP free to use?

Yes, the UNTP intellectual property is owned by the United Nations and is provided free of charge for use by anyone. Furthermore, any party may modify the UNTP for their own purposes. However if you want to create a formal and registered UNTP extension then you must follow the [extension methodology and governance rules](../tools-and-support/ExtensionsMethodology.md).

### Is UNTP a platform?
No. The UNTP is not a digital platform or service. It is a global, open-source traceability framework developed under the United Nations system to support transparent, interoperable, and credible supply chain data sharing — especially around sustainability claims.

### What is the current gap that the UNTP is trying to fill?
The UNTP addresses a critical gap in global supply chains, including the lack of a neutral, interoperable, and verifiable way to share sustainability-related product data across systems, sectors and borders.

While many traceability and certification schemes already exist, they are often limited to one sector or country; do not provide sufficient transparency about the criteria or verification processes; use different data models or definitions; or are vulnerable to greenwashing to due inconsistent assurance mechanisms.

The UNTP fills this gap by offering a public-good framework, developed under the UN, that provides:

* A shared language for sustainability claims (via the Conformity Vocabulary Catalogue (CVC)).
* A neutral trust model (aligned with ISO CASCO) for verifying those claims.
* A decentralized, credential-based architecture that allows product data to travel with the item, independent of specific platforms.
* Tools for mapping, aligning, and integrating diverse schemes and systems without replacing them.

In essence, UNTP aims to link credible data, independent verification and global interoperability, so that sustainability claims can be trusted, compared and acted upon at scale.

### How does the UNTP create value for brands and manufacturers?
Brands and manufacturers use the UNTP to meet growing sustainability expectations — from both regulators and consumers — while reducing operational complexity. The UNTP helps by:

* Reducing integration costs through open-source, standards-based traceability components.
* Enabling clear, verifiable, and credible product claims with tools like the Conformity Vocabulary Catalogue (CVC) and Digital Conformity Credential (DCC).
* Lowering the risk of greenwashing by ensuring performance claims are specific and traceable to recognized criteria.
* Supporting comparability across sustainability schemes via a shared ESG taxonomy.

With the UNTP, brands gain more reliable and transparent value chain data, allowing them to scale responsible sourcing and sustainability reporting efficiently.

### What value does the UNTP offer to upstream suppliers and producers?
Upstream suppliers and producers — especially small and medium enterprises — often face data overload, high compliance costs, and limited visibility. The UNTP levels the playing field by:

* Making it easier to share data once and use it many times across systems and buyers.
* Supporting credible sustainability claims through standardized vocabulary and digital credentials.
* Helping them demonstrate compliance with buyer or regulatory requirements using globally recognized conformity tools.
* Providing a path to engage in international markets without needing custom or proprietary systems.

By using the UNTP, suppliers can increase trust, reduce duplicative audits, and participate more fully in high-value, sustainability-focused supply chains.

### How does the UNTP support software providers and digital platform developers?
The UNTP provides a robust, open-source foundation that allows software providers to build scalable, standards-based solutions for traceability and sustainability. It offers:

* Open-source tools and standardized APIs to reduce the time and cost of developing traceability features.
* A modular architecture that integrates easily across systems, sectors, and geographies.
* A decentralized credential model, where sustainability data travels with the product, not just through direct system-to-system links.
* Tools like the Conformity Vocabulary Catalogue (CVC) and the Digital Conformity Credential (DCC), which standardize and verify sustainability claims.
* Alignment with globally recognized trust frameworks (like ISO CASCO), increasing credibility and market compatibility.

By using UNTP components, software providers can offer clients interoperable, future-proof systems without relying on proprietary lock-ins.

### How does the UNTP support governments and public regulatory bodies?
Governments benefit from the UNTP as a neutral, globally aligned infrastructure that supports policy enforcement, trade facilitation, and sustainable development goals. It contributes by:

* Offering a UN-governed, non-proprietary framework for interoperability across national and international systems.
* Reducing regulatory fragmentation through shared vocabularies and reference taxonomies.
* Supporting transparency and accountability in sustainability claims across borders.
* Allowing for alignment with national conformity assessment systems through its CASCO-based trust framework.

In essence, the UNTP helps public authorities ensure that sustainability data is credible, comparable, and actionable — without forcing alignment with any single proprietary or national model.

### What makes the UNTP different from other traceability initiatives?
Unlike many private or national initiatives, the UNTP:

* Is governed multilaterally under the United Nations
* Is openly available and free to adopt
* Uses globally recognized standards
* Is designed to complement, not replace, existing systems

Its purpose is to serve as a global reference framework for credible traceability — not as a competing commercial platform.

### Is the UNTP intended as the only implementation option?
No. The UNTP is a reference implementation, not an exclusive or mandatory one. It offers a practical example of how traceability standards can be operationalized using a neutral, public infrastructure. Policymakers, industries, and technical bodies remain free to use or adapt alternative approaches.

### Is the UNTP owned or controlled by a private company or government?
No. The UNTP is developed under the United Nations Economic Commission for Europe (UNECE), supported by the UN Digital Public Infrastructure (DPI) framework, and with contributions from public agencies, international organizations, technical experts, civil society and industry actors. It is governed by open, inclusive processes to ensure neutrality and accountability.

### Is the UNTP trying to replace national or private traceability systems?
Not at all. The UNTP is built for interoperability. It is designed to work alongside existing systems — whether national, private, or sectoral — and improve how they communicate, not replace them.

### Does referencing the UNTP compromise technology neutrality?
No. The UNTP is not a product or a vendor solution — it is a neutral, open-source, and standards-based framework developed under a multilateral UN process. It does not prescribe any specific technology or implementation approach. Instead, it offers a voluntary and interoperable structure that can be adapted or extended to meet various technical and regulatory needs.

### Does the UNTP lead to vendor lock-in?
No. The UNTP is licensed for unrestricted public use and is designed to be vendor-agnostic. Anyone — including governments, open-source communities, or private actors — can implement or extend it without licensing fees or exclusive control. Its design explicitly avoids dependencies on proprietary technologies.

---

## Governance and Development Process

### How is the UNTP developed?
The UNTP is developed through a transparent, iterative, and field-tested process under the UN/CEFACT Open Development Procedure, which includes:

* Field-testing in global value chains (e.g., fashion, agriculture)
* Collaboration with UN/CEFACT and national governments
* Public documentation and open-source contributions

It has been piloted in real-world supply chains and continues to evolve based on feedback. While no single model is universally complete, the UNTP offers a well-documented and extensible baseline for organizations seeking credible traceability infrastructure.

### Was the development of the UNTP inclusive of diverse stakeholders?
Yes. Under the UN/CEFACT Open Development Process, governments, technical experts, international organizations, and civil society contribute to the development of the UNTP. The protocol remains open to ongoing contributions via public comment, pilot feedback, and expert engagement.

### How is the UNTP aligning with other standard-setting bodies?
The UNTP actively seeks complementarity and alignment with existing standards such as those developed by ISO, ITU, and GS1. Its structure allows for easy mapping to external data models and certification frameworks. Dialogue and cooperation with standards bodies are part of its ongoing evolution.

### Will future changes to the UNTP include member State input?
Yes. Any updates or formal adoption into recommendations are subject to UN/CEFACT procedures, which prioritize consensus and member State engagement. National authorities play an essential role in shaping normative texts and implementation pathways.

### Why was the UNTP project migrated from GitHub to GitLab?
To ensure inclusive global participation and avoid access restrictions linked to proprietary or country-controlled platforms. GitLab allows all contributors to engage under UN-managed governance.

---

## Interoperability and Integration

### How does the UNTP support system integration?
The UNTP enables interoperability through:

* Standardized data models and APIs
* Semantic vocabularies for consistent understanding of terms
* Linkages with identifiers, certifications, and customs processes

This makes it easier for different systems to exchange verified traceability data.

### How does the UNTP differ from systems like Gaia-X?
While systems like Gaia-X rely on federated, direct API connections, the UNTP uses a credential-based model. Information travels with the product, rather than through fixed system-to-system links — much like a passport system, allowing data to be portable and verifiable across different networks.

## Digital Product Passports

### Can I issue a UNTP DPP for a product I haven't made yet?

Yes, one can can issue batch/item DPP a short time in advance so long as there is confidence in the identifiers and the claims for that batch. One can issue a model DPP well in advance of any DPPs that are batch/ item specific.

### Can I add late arriving information?

Eg I issued the DPP but then I just got my deforestation certificate and want to add a claim to already issued DPPs. This is a case of publishing an updated version that superseeds the previous version under the same model or batch/item ID. Here is an example: [Versioned Targets](../specification/IdentityResolver.md#versioned-targets).

### Can someone else add post-sale information to my DPP such as a repair event?

In this case it's not an updated DPP because it's not the product manufacturer adding the late arriving data - instead it's the authorised repair facility or verified owner of the thing adding an event to the bundle of data about the thing. Here is how it might be approached in [Linked Lifecycle Data](../design-patterns/LinkedLifecycleData.md).

---

## Sustainability and Vocabulary Catalogues

### How does the UNTP help prevent greenwashing? 

The UNTP includes safeguards to ensure that sustainability claims are:

* Verifiable and backed by trusted sources
* Clear and machine-readable
* Traceable to their origin and method of verification

Tools like the Digital Conformity Credential (DCC) and the Conformity Vocabulary Catalogue (CVC) support consistent, comparable disclosures aligned with international norms.

### How does the UNTP promote consistency in sustainability data?
It offers a shared structure to describe sustainability attributes across products, using recognized environmental and social indicators. This helps align different reporting schemes, making sustainability information more comparable and credible.

### What is the UNTP’s position on scheme integrity and trust frameworks?
The UNTP actively promotes independent, transparent, and trustworthy conformity assessment — particularly in the context of sustainability and environmental claims, where such practices are often inconsistent.

To do this, the UNTP aligns with the well-established ISO CASCO framework, which separates three critical roles:

* Standards developers (who define the criteria),
* Conformity assessment bodies (who independently verify claims), and
* Accreditation authorities (who ensure those verifiers are competent and impartial).

While this model is common in product quality and safety certification, many environmental schemes do not follow this separation of duties. Instead, scheme owners often issue the standard, conduct the audit, and accredit others — all under one roof. This can undermine credibility, even if the criteria are ambitious.

To address this, the UNTP introduces the Digital Conformity Credential (DCC) — a tool designed to help bring environmental and ESG-related claims into the globally trusted CASCO-aligned model. The DCC is being developed by experts with deep experience in conformity systems and is intended to help distinguish between robust schemes and those that rely primarily on self-assertion.

In short, the UNTP does not just focus on what sustainability standards say — it also supports how they are verified, aiming to reduce greenwashing and promote global confidence in sustainability data.

---

## Extension Methodology

### Can the UNTP be adapted for specific sectors or national needs?

The UNTP is designed to be:

* Modular – can be tailored for specific use cases or regulatory settings
* Scalable – works for both small producers and multinational firms
* Open – stakeholders can propose extensions through a structured, transparent process.

### Can the UNTP support complex or long-life-cycle products?
While initial pilots focused on shorter-cycle goods (e.g., textiles, food), the UNTP’s modular structure is adaptable to complex, long-term supply chains such as electronics, machinery, or vehicles. The extension methodology enables custom data attributes, lifecycle documentation, and compliance timelines suited to long-duration product use.

### Can I implement UNTP without an extension?

Yes. UNTP core works for any industry using generic credentials. Extensions add industry-specific conveniences but aren't required. Many implementers start with core and add extensions later when available.

### What if my industry doesn't have an extension?

Three options:
1. Implement UNTP core now (recommended if facing immediate needs)
2. Initiate extension development through your industry association
3. Adapt a related industry's extension with minor modifications

### How much does extension development cost?

Typical association-level investment: $200-500K over 6-8 months. Return on investment: 10-30x through member implementation savings (vs. each member building proprietary solutions).

### Who governs extensions?

Each extension is governed by its owner (typically an industry association or standards body). UNTP provides methodology and registers extensions, but doesn't control extension governance. This ensures industries own their standards.

### Can extensions work together across industries?

Yes—that's the core value. All extensions maintain interoperability with UNTP core, meaning credentials from any extension are readable by any other extension. A mining company's credential works seamlessly with a battery manufacturer's system.

### What's the difference between an extension and a custom implementation?

A registered extension is interoperable with all other UNTP extensions and provides value to an entire industry. A custom implementation may work for your company but won't necessarily interoperate with others and provides no industry-wide coordination benefits.

### How do I know an extension is legitimate?

Check the [Extensions Register](../implementations/ext/). Only extensions meeting UNTP methodology requirements are registered. Registration ensures interoperability, open governance, and conformance testing.

### Can there be multiple extensions for the same industry?

Yes. UNTP doesn't prevent overlapping extensions. Market typically consolidates around the most widely adopted extension, but multiple extensions can coexist since all remain interoperable with UNTP core.

### How long does extension development take?

Typical timeline: 4-8 months from initiation to registration, plus 3-6 months pilot phase before production release. Total: 7-14 months for fully mature extension.

### What happens if UNTP core changes?

Extensions are version-managed and linked to UNTP core versions. Major core updates announced 6-12 months in advance. Extension maintainers coordinate with core team to maintain compatibility. Migration guides provided for breaking changes.

---

## Piloting and Implementing

### Has the UNTP been tested in real-world supply chains?
Yes. Pilots have been conducted in sectors such as:

* Textiles and garments
* Agriculture and food systems
* Environmental reporting

These pilots validate that the protocol works in diverse contexts.

### What sectors can use the UNTP?
The UNTP is sector-agnostic. It can be adopted across industries where supply chain transparency and sustainability claims matter. Sectors with active interest include fashion, food, construction, and mining.

### What are the objectives of extension pilots?

*Example: Critical minerals pilot.*

It aims to prove that traceability and transparency in mineral supply chains can be scalable, cost-effective, and interoperable across sectors and systems.

The pilot seeks to validate:

* Digital verifiability of scheme owners’ claims via UNTP Conformity Vocabulary Catalogue (CVC).
* Interoperability across diverse software systems.
* Cross-sector extension compatibility (e.g., electronics and copper).
* Compliance with standards like the GBA Battery Passport and EU DPP.
* Bridging between UNTP and non-UNTP ecosystems (e.g., Catena-X).
* Cost-benefit effectiveness of the UNTP approach.

---

## Expert and Vendor Participation

### How can organizations contribute to the development of the UNTP?
Organizations can participate by:

* Contributing to the open-source codebase or specification
* Testing and implementing the protocol in their operations
* Proposing extensions or new vocabulary terms

Participation is open to governments, companies, researchers, and civil society.

### How do I become an official UN/CEFACT expert or observer?
You can apply through the UN/CEFACT expert registration portal, which outlines roles and expectations for active contributors:
[https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration](https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration)

### Is there a registry of vendors and systems using the UNTP?
Yes. A public registry is maintained on this site:

* [Software Tools](../implementations/swi/)
* [Identity Registers](../implementations/idr/)
* [Sustaiunability Schemes](../implementations/cvc/)

---

---

## Goals and Objectives

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

*Informative*

## Goals & Objectives

UNTP implements traceability technologies that give management teams detailed digital information about upstream suppliers, downstream partners, customers, and their processes. This visibility helps executives meet sustainability objectives, demonstrate regulatory compliance, and obtain provenance and sustainability certifications.

Companies need resilient networks to secure supply in a volatile business environment. Fast-changing consumer preferences demand flexibility and speed. Investors, consumers, and governments expect sustainable products and processes backed by credible certifications. Competing in the next decade requires a transparent, circular value chain—one that reduces or reuses materials and remanufactures or recycles products, cutting costs and waste.

[Recommendation 49](https://unece.org/documents/2025/12/recommendation-49-transparency-scale-fostering-sustainable-value-chains-0) sets out the following goals:

* Strengthen national economies and promote sustainable international trade through trustworthy product sustainability claims, corporate sustainability disclosures, and value chain traceability.
* Advance responsible business conduct by enabling risk-based due diligence on environmental, human rights, and social impacts in global value chains.
* Create a level playing field for compliant actors across the value chain.
* Improve export market access and boost competitiveness of domestic products in response to growing sustainability concerns.
* Reduce the complexity, time, and cost of data exchange when validating product conformity with sustainability standards.
* The recommendation also supports other stakeholders working toward sustainable consumption and production (SDG 12) and related goals of the 2030 Agenda, from upstream production through end-of-life disposal and material recovery.

Traceability is also essential for the circular economy. Embedding traceability in the value chain helps recyclers, policymakers, practitioners, and researchers make better decisions. Effective traceability promotes circularity by improving material identification, sorting practices, and industry-wide transparency.

## Success Measures

UNTP creates real impact only through uptake and implementation. Uptake is therefore the primary measure of success.

UNTP will measure uptake by counting the number of [implementations](../implementations/) and completed conformity tests—that is, actual implementations. Your active participation is essential. Uptake must exceed the minimum thresholds currently under review.

---

---

## Impact

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

*Informative*

UNTP delivers value beyond technical interoperability. By making supply chain data verifiable and tamper-evident, it addresses two broad classes of challenges that depend on trustworthy information: the **security and resilience** of supply chains themselves (provenance integrity, concentration risk, sanctions exposure, recall speed), and the **sustainability** of what those supply chains produce (environmental footprint, human rights, circular economy, ESG reporting). The sections below draw on independent research and regulatory analysis to describe what UNTP makes possible in each domain.

### Security and Resilience Outcomes

| Impact Domain | UNTP Contribution |
|---|---|
| [Anti-Corruption](#anti-corruption) | Verifiable material and money flow data lets regulators, investigators, and civil society detect irregularities, identify high-risk actors, and expose record manipulation. |
| [Counterfeit Detection and Product Authenticity](#counterfeit-detection-and-product-authenticity) | Cryptographically signed chain-of-custody records bound to physical product identifiers make counterfeits detectable at every handoff instead of only in post-incident forensics. |
| [Critical Minerals and Strategic Material Security](#critical-minerals-and-strategic-material-security) | Verifiable origin and processing records let governments and manufacturers track exposure to strategic-material supply risk and demonstrate compliance with critical-minerals sourcing rules. |
| [Recall, Contamination, and Incident Response](#recall-contamination-and-incident-response) | Traceability graphs combined with verifiable credential revocation turn recalls from broadcast notices into targeted, evidence-based operations that complete in hours rather than weeks. |
| [Sanctions, Export Controls, and Trade-Compliance Automation](#sanctions-export-controls-and-trade-compliance-automation) | Identity-anchored supply chain graphs let automated tooling screen the entire upstream for sanctioned actors and export-control violations at credential-issuance time, not only at the shipping manifest. |
| [Supply Chain Disruption and Concentration Risk](#supply-chain-disruption-and-concentration-risk) | N-tier visibility through linked credentials exposes single-source and geographic concentration dependencies, supporting government and industry contingency planning. |

### Sustainability Outcomes

| Impact Domain | UNTP Contribution |
|---|---|
| [Biodiversity Loss](#biodiversity-loss) | Traceability to source enables accurate ecological footprint assessment and reduces the risk of hidden deforestation or illegal resource extraction in deeper supply chain tiers. |
| [Circular Economy](#circular-economy) | Verified product composition, sourcing, and life history data supports accurate recyclability claims, better design decisions, and responsible material recovery. |
| [Human Rights / Welfare](#human-rights--welfare) | Supply chain traceability gives companies and regulators the evidence needed to identify and mitigate forced labour and human rights risks at scale. |
| [Product Transparency](#product-transparency) | Standardised, independently validated ESG and supply chain data lets buyers assess environmental and social impact, authenticity, and compliance with confidence. |
| [Reducing Greenwashing](#reducing-greenwashing) | An immutable audit trail behind every sustainability claim exposes misrepresentation and replaces marketing narratives with machine-verifiable evidence. |
| [Sustainability Standards Alignment](#sustainability-standards-csrd-csddd-ifrs-sasb-and-gri) | UNTP data maps directly to CSRD, CSDDD, IFRS, SASB, and GRI, reducing audit complexity and ensuring consistent disclosures across jurisdictions. |
| [Verifiable ESG Performance Data](#verifiable-esg-performance-data-for-financial-institutions-investors-and-ngos) | High-integrity, tamper-evident ESG data gives financial institutions, investors, and NGOs a common, reliable basis for risk assessment, portfolio analysis, and advocacy. |

---

## Anti-Corruption

UNTP enhances traceability and trackability, enabling analysis of money and material flows and identification of potential corruption.

By standardising how information is verified and shared, UNTP makes it harder for organisations to conceal unethical practices and easier for regulators, investors, and partners to detect irregularities. This strengthened integrity improves trust across transactions, supports compliance with anti-corruption regulations, and fosters a business environment where ethical behaviour is verifiable rather than assumed.

Where reliable data exists, companies and law enforcement, journalists, and civil society can overlay core traceability information with additional sources as part of anti-corruption due diligence:

- Data on a raw material's origin, processing, and transit can be overlaid with indicators on rule of law, corruption perceptions, and minerals sector governance to identify vulnerabilities and assess the reliability of government-issued documents.
- Chain of custody information can be combined with contracts and beneficial ownership data to identify high-risk actors — Politically Exposed Persons, military or police involvement, beneficial owners with criminal backgrounds, or companies lacking operational or financial qualifications.
- Plausibility checks on production and trade volumes, alongside contractual terms, can reveal discrepancies that signal record manipulation, underreporting, or other corrupt practices.

*Source: From Mine to Market: Using Traceability to Fight Mineral Sector Corruption*

---

## Biodiversity Loss

The World Economic Forum estimates that over 50% of global GDP depends on nature and the services it provides. Supply chain transparency for biodiversity means disclosing the origin of raw materials and associated ecological impacts throughout a company's value chain — covering not only direct suppliers but also upstream producers and the specific geographical areas from which nature-dependent commodities are sourced. High transparency is a core requirement for credible environmental reporting within ESG.

Achieving transparency requires implementing traceability systems such as UNTP to map and verify the origin of materials. Companies must collect and standardise data on land use, water consumption, and pollution at each stage of the supply chain, with regular third-party verification of both the data and the system's integrity.

This enables consumers, investors, and regulators to accurately assess a company's ecological footprint and hold it accountable for its nature-related commitments. Transparency also mitigates the risk of hidden deforestation or illegal resource extraction in deeper supply chain tiers and builds trust by providing verifiable evidence of responsible sourcing.

*Source: Supply Chain Transparency for Biodiversity*

---

## Circular Economy

The content, composition, and life history of a product are essential for assessing reuse pathways and engineering effective recovery and separation of raw materials or components. UNTP enhances the availability and comprehensiveness of this information through the product passport.

UNTP strengthens circular economy initiatives by providing verifiable, traceable data on product materials, sourcing, reuse cycles, and end-of-life pathways. Standardising how circularity metrics are recorded and validated lets businesses, consumers, and regulators track a product's lifecycle with confidence and ensure that claims about recyclability, reuse, or resource efficiency are accurate and tamper-evident. This transparency supports better design decisions, promotes responsible material recovery, and encourages markets to reward genuinely circular products.

---

## Counterfeit Detection and Product Authenticity

Counterfeit products cause an estimated USD 2 trillion in annual global economic damage and cause direct physical harm when they infiltrate pharmaceuticals, semiconductors, aerospace components, automotive safety parts, or food. Existing anti-counterfeiting measures — holograms, watermarks, tamper-evident packaging — are passive physical markers that can be copied or replicated. Supply chain audits and market surveillance catch counterfeits only after they surface, not before.

UNTP reframes product authenticity as a runtime cryptographic check. Each legitimate product carries a signed credential chain that binds it to its issuer, its facility of origin, its production batch, and any subsequent transformation or custody events. Physical identifiers such as GS1 Digital Link, DataMatrix codes, and NFC tags resolve to the signed credential rather than to a static database record. A counterfeit item either carries no credential, carries a credential that does not cryptographically chain back to a legitimate issuer, or attempts to reuse a valid credential on multiple items — each of which fails verification at scan time. For high-value and safety-critical goods, this converts authenticity from a periodic audit question into a per-item, per-handoff check.

*Source: OECD / EUIPO Global Trade in Fakes 2021; US Drug Supply Chain Security Act.*

---

## Critical Minerals and Strategic Material Security

A secure and resilient supply of critical minerals — lithium, cobalt, copper, nickel, rare earths, graphite, and similar — has become a central pillar of industrial policy in the EU, US, Japan, Australia, Canada, and Korea. Regulations such as the EU Critical Raw Materials Act, the US Inflation Reduction Act and Defense Production Act provisions, and Australia's Critical Minerals Strategy set domestic-content thresholds, "trusted partner" sourcing preferences, and restrictions on material originating from high-risk jurisdictions. Meeting these rules at industrial scale requires proof of where materials came from, who processed them, and under what governance — a form of evidence that voluntary assurances and manual audits cannot sustain.

UNTP provides the infrastructure for that evidence. Digital Product Passports carry verifiable origin and refinement history; Digital Facility Records anchor processing sites to identifiers that regulators can cross-check; Digital Conformity Credentials link claims to accredited third-party assessments. Buyers can demonstrate compliance with trusted-partner and domestic-content rules at the moment of procurement. Governments can audit aggregate national exposure to single-source or adversarial-aligned suppliers without requiring confidential disclosures from individual firms. Upstream producers benefit from a verifiable premium for sovereign-compliant material in markets that previously could not distinguish it.

*Source: EU Critical Raw Materials Act (Regulation 2024/1252); US Inflation Reduction Act §30D; Australia's Critical Minerals Strategy 2023–2030.*

---

## Human Rights / Welfare

Governments worldwide have introduced regulations against modern slavery and human rights violations. Companies must treat supply chain transparency and ethical sourcing as both a legal obligation and a moral duty. Legislation increasingly requires firms not only to avoid profiting from forced labour but to actively report and mitigate any risks of it in their production and sourcing.

The United Nations Economic Commission for Europe (ECE) member states mandated the development of Recommendation 49 — Transparency at Scale: Fostering Sustainable Value Chains — to advance the circular and digital transformations for sustainable development. This reflects a growing consensus on the importance of responsible, equitable, and interoperable data governance for achieving development objectives, safeguarding human rights, fostering innovation, and driving economic growth.

UNTP supports governments and industry with practical measures by implementing supply chain traceability and transparency at the scale needed to achieve meaningful sustainability outcomes.

---

## Product Transparency: B2C Consumers and B2B End Users {#product-transparency}

UNTP provides comprehensive information on the composition and sourcing of materials used to design and manufacture a product, giving buyers access to environmental, social, and sustainability credentials.

By linking product claims to standardised, independently validated ESG and supply chain data, UNTP enables buyers to assess environmental and social impact, authenticity, and compliance with confidence. This reduces misinformation, strengthens trust in sustainability labels, and empowers consumers and businesses to make procurement decisions aligned with their values, regulatory requirements, and risk expectations.

---

## Recall, Contamination, and Incident Response

Supply chain resilience depends not only on preventing incidents but on responding quickly when they occur. Food contamination, pharmaceutical defects, battery safety issues, compromised electronic components, and cyber-physical attacks all share a common response problem: identifying exactly which batches are affected, which parties currently hold them, and which downstream products contain them. Today this typically takes weeks of manual supplier outreach, during which affected goods continue to circulate and consumer trust erodes.

UNTP enables targeted response through two mechanisms working together. The Digital Traceability Event log maintains a verifiable record of every production, movement, and transformation event linked to the Digital Product Passports involved — so downstream holders can be identified by graph traversal rather than by phone calls. The W3C Bitstring Status List built into UNTP's credential model lets the original issuer revoke or flag affected credentials in a single action; holders that check credential status routinely see the revocation propagate within minutes. The combination converts a recall from a broadcast notice to the entire industry into a targeted operation that identifies affected parties by name and scopes the response to actual exposure.

*Source: WHO Good Traceability Practices for Medical Products; FDA Food Safety Modernization Act Rule 204.*

---

## Reducing Greenwashing

UNTP ensures traceability across sourcing, checking, and confirming — or refuting — the claims of product manufacturers and distributors.

UNTP reduces greenwashing by requiring that sustainability claims be backed by verifiable information. Data is recorded, validated, and shared with an immutable audit trail that exposes inconsistencies and prevents companies from misrepresenting their impact. This builds trust among investors, financial institutions, regulators, and civil society, who can rely on machine-verifiable evidence rather than marketing narratives.

---

## Sanctions, Export Controls, and Trade-Compliance Automation

Sanctions regimes — OFAC, EU restrictive measures, UK financial sanctions, UN Security Council lists, and sectoral export controls under frameworks such as ITAR, EAR, and the Wassenaar Arrangement — are both more numerous and more dynamic than ever before. Most current compliance tooling operates at the shipment level: screening a single counterparty on a single transaction. That approach misses upstream exposure. A finished product's tier-3 supplier can be sanctioned without any direct relationship to the ultimate buyer; by the time the exposure surfaces in an audit, product has already been delivered and the buyer is liable.

UNTP's Digital Identity Anchor binds legal entities, beneficial owners, and facilities to globally resolvable identifiers. Because every credential in a UNTP supply chain graph cites those identifiers, automated tooling can traverse the complete upstream of any product passport and screen every referenced party against sanctions and restricted-party lists. The check happens at credential issuance, at procurement, or continuously — not only at the shipping manifest. The same mechanism supports export-control end-use and end-user verification, and provides the audit trail regulators increasingly expect as evidence of "knowing your extended supply chain."

*Source: OFAC Compliance Guidance; EU Dual-Use Regulation 2021/821; G7 statements on trusted supply chains.*

---

## Supply Chain Disruption and Concentration Risk

Supply chain disruption — from natural disaster, pandemic, conflict, infrastructure failure, or deliberate economic coercion — reveals hidden dependencies only after they bite. The pandemic exposed single-source semiconductor and active-pharmaceutical-ingredient concentration; the 2021 Suez Canal blockage exposed routing fragility; more recent events have exposed concentration of rare-earth processing, mature-node chips, critical agricultural inputs, and maritime shipping insurance. In every case, buyers and governments discovered after the fact that a dependency they believed to be diversified actually converged at a single upstream node.

UNTP makes those dependencies visible before the disruption. Each product passport links to the facility record for its production site, which in turn links to input-material passports, which link to their own upstream facility and input records, and so on recursively. The result is an N-tier dependency graph that buyers, governments, and industry associations can analyse for geographic concentration, single-source exposure, and shared-upstream risk that cascades across seemingly independent suppliers. Unlike private mapping services that capture only what one buyer can see, UNTP is distributed and cross-referencing: every participating actor contributes a verifiable piece of the graph, and any actor with the appropriate credential access links can walk it. This is the shape of evidence that national resilience reviews, industrial policy, and insurance underwriting have increasingly needed but struggled to obtain.

*Source: OECD Supply Chain Resilience Policy Handbook 2024; US National Security Council supply chain resilience reports.*

---

## Sustainability Standards: CSRD, CSDDD, IFRS, SASB, and GRI

UNTP provides access to product information and verified credentials from supply chain actors. This information maps directly to sustainability standards including CSRD, CSDDD, IFRS, SASB, and GRI, allowing organisations to report ESG data in a verifiable, interoperable, and tamper-evident format.

By linking these major standards to a common transparency layer, UNTP improves data reliability, reduces audit costs and complexity, and ensures consistent disclosures across jurisdictions and frameworks.

---

## Verifiable ESG Performance Data for Financial Institutions, Investors, and NGOs

UNTP provides a traceability framework covering a comprehensive set of verified credentials along the value chain, giving all actors access to high-integrity, tamper-evident ESG data.

Financial institutions gain clearer insight into risk and compliance. Investors benefit from comparable, independently validated metrics for more accurate portfolio analysis. NGOs gain a transparent evidence base to hold companies accountable and strengthen advocacy. By establishing a common, verifiable standard for ESG performance, UNTP aligns all stakeholders around credible, data-driven sustainability action.

---

## Related Standards and Initiatives

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

*Informative*

## Overview

UNTP builds upon existing work rather than re-inventing standards, maximising interoperability with similar initiatives. This page catalogues the standards, regulations, inter-governmental instruments, and industry initiatives that UNTP relates to — and is an initial assessment by the UNTP community that describes the nature of each relationship.

| Category | UNTP Strategy |
|---|---|
| [**Standards**](#standards) | Re-use rather than re-invent. UNTP builds upon existing standards wherever possible, normatively referencing or profiling established specifications to maximise interoperability and minimise duplication. |
| [**Regulations**](#regulations) | Provide the lowest-cost, highest-integrity, and most scalable implementation instrument. UNTP credentials and the transparency graph give regulators and regulated entities a ready-made digital infrastructure for compliance. |
| [**UN and IGO Instruments**](#un-and-igo-instruments) | Map to the outcomes they target so that UNTP becomes the preferred tool for concrete implementation and national capability building. |
| [**Industry Initiatives**](#industry-initiatives) | Partner so that industry sustainability and resilience goals are most easily met through UNTP community activation, reducing the cost and complexity of initiative-specific tooling. |

---

## Summary

### Standards

*Re-use rather than re-invent. UNTP builds upon existing standards wherever possible, normatively referencing or profiling established specifications to maximise interoperability and minimise duplication.*

| Reference | Authority | Summary |
|---|---|---|
| [W3C VCDM](#w3c-verifiable-credentials-data-model) | [W3C](https://www.w3.org/) | UNTP requires all credentials be issued as W3C VCs (v2.0 JSON-LD compacted form). |
| [W3C DID](#w3c-decentralised-identifiers) | [W3C](https://www.w3.org/) | UNTP requires W3C DIDs as issuer identifiers for all credentials. |
| [W3C JSON-LD](#w3c-json-ld) | [W3C](https://www.w3.org/) | UNTP uses JSON-LD syntax for all credential data representation. |
| [IETF JOSE](#ietf-jose) | [IETF](https://www.ietf.org/) | UNTP mandates JOSE enveloping proof for VC integrity. |
| [IETF SD-JWT](#ietf-sd-jwt) | [IETF](https://www.ietf.org/) | UNTP does not preclude SD-JWT but uses variant-based disclosure as the primary mechanism. |
| [ISO/IEC 15459](#isoiec-15459) | [ISO/IEC](https://www.iso.org/) | UNTP leverages the 15459 series for globally unique identifier encoding in data carriers. |
| [ISO/IEC 18975](#isoiec-18975) | [ISO/IEC](https://www.iso.org/) | UNTP Identity Resolver implements ISO 18975 for structured identifier resolution. |
| [ISO 59040](#iso-59040-product-circularity-data-sheet) | [ISO](https://www.iso.org/) | UNTP DPP provides a digital mechanism to convey ISO 59040 circularity criteria. |
| [IFRS S1/S2](#ifrs-s1s2) | [IFRS Foundation](https://www.ifrs.org/) | UNTP performance metrics taxonomy enables roll-up to IFRS sustainability disclosures. |
| [GRI Standards](#gri-standards) | [GRI](https://www.globalreporting.org/) | UNTP metrics map to GRI indicator categories for enterprise reporting. |
| [GHG Protocol](#ghg-protocol) | [WRI / WBCSD](https://ghgprotocol.org/) | UNTP emissions metrics directly aligned with GHG Protocol scopes 1–3. |
| [ISO 17000](#iso-17000) | [ISO/CASCO](https://www.iso.org/) | UNTP DCC conformity assessment vocabulary directly implements ISO 17000 terminology. |
| [ISO 17011](#iso-17011) | [ISO/CASCO](https://www.iso.org/) | UNTP DCC trust hierarchy implements the ISO 17011 accreditation model. |
| [ISO 19987](#iso-19987) | [ISO/IEC](https://www.iso.org/) | UNTP DTE is a conformant, simplified profile of ISO 19987 traceability events. |
| [CEN/CENELEC JTC24](#cencenelec-jtc24) | [CEN/CENELEC](https://www.cencenelec.eu/) | UNTP and the European Norms (EN) for the EU DPP system are highly interoperable; CIRPASS-2 alignment review confirms this high level of interoperability. |
| [DIN DKE SPEC 99100](#din-dke-spec-99100) | [DIN/DKE](https://www.din.de/) | UNTP DPP maps all 88 battery passport data attributes defined by this specification. |

### Regulations

*Provide the lowest-cost, highest-integrity, and most scalable implementation instrument. UNTP credentials and the transparency graph give regulators and regulated entities a ready-made digital infrastructure for compliance.*

| Reference | Authority | Summary |
|---|---|---|
| [EU ESPR](#eu-ecodesign-for-sustainable-products-regulation-espr) | [European Commission](https://commission.europa.eu/) | UNTP DPPs are architecturally interoperable with ESPR product passport requirements. |
| [EU Battery Regulation](#eu-battery-regulation) | [European Commission](https://commission.europa.eu/) | UNTP DPP maps all battery passport data attributes defined by DIN DKE SPEC 99100. |
| [EU CBAM](#eu-carbon-border-adjustment-mechanism-cbam) | [European Commission](https://commission.europa.eu/) | UNTP DPPs and DFRs carry the product-level embedded emissions data CBAM requires. |
| [EU EUDR](#eu-deforestation-regulation-eudr) | [European Commission](https://commission.europa.eu/) | UNTP DTEs and DFRs with geolocation support EUDR traceability to plot of origin. |
| [EU CSRD / ESRS](#eu-corporate-sustainability-reporting-csrdesrs) | [European Commission](https://commission.europa.eu/) | UNTP metrics taxonomy enables roll-up of supply chain data to ESRS disclosures. |
| [EU CSDDD](#eu-corporate-sustainability-due-diligence-directive-csddd) | [European Commission](https://commission.europa.eu/) | UNTP transparency graph provides the value chain visibility CSDDD due diligence requires. |
| [EU Forced Labour Regulation](#eu-forced-labour-regulation) | [European Commission](https://commission.europa.eu/) | UNTP supply chain traceability and social audit DCCs support forced labour due diligence. |
| [EU Critical Raw Materials Act](#eu-critical-raw-materials-act) | [European Commission](https://commission.europa.eu/) | UNTP DPPs carry critical raw material composition and recycled content data. |
| [EU Conflict Minerals Regulation](#eu-conflict-minerals-regulation) | [European Commission](https://commission.europa.eu/) | UNTP DTEs trace mineral flows; DCCs verify responsible sourcing from smelters. |
| [US UFLPA](#us-uyghur-forced-labor-prevention-act-uflpa) | [US Congress](https://www.congress.gov/) | UNTP transparency graph provides the complete supply chain tracing UFLPA demands. |
| [US Dodd-Frank Section 1502](#us-dodd-frank-act-section-1502) | [US Congress](https://www.congress.gov/) | UNTP DTEs and DCCs support conflict minerals supply chain traceability and reporting. |
| [California SB 253 / SB 261](#california-climate-disclosure-sb-253--sb-261) | [California Legislature](https://leginfo.legislature.ca.gov/) | UNTP emissions metrics support Scope 1–3 reporting required by SB 253. |
| [German Supply Chain Due Diligence Act (LkSG)](#german-supply-chain-due-diligence-act-lksg) | [German Federal Government](https://www.bmas.de/) | UNTP transparency graph supports multi-tier supply chain due diligence. |
| [UK Modern Slavery Act](#uk-modern-slavery-act) | [UK Parliament](https://www.legislation.gov.uk/) | UNTP credentials provide verifiable evidence for modern slavery statements. |
| [Australian Modern Slavery Act](#australian-modern-slavery-act) | [Australian Parliament](https://www.legislation.gov.au/) | UNTP credentials provide verifiable evidence for modern slavery statements. |
| [Australian Climate Disclosure](#australian-mandatory-climate-disclosure) | [Australian Treasury](https://treasury.gov.au/) | UNTP metrics taxonomy supports ISSB-aligned Scope 3 supply chain disclosures. |
| [Canada Forced Labour Act (S-211)](#canada-fighting-against-forced-labour-and-child-labour-act) | [Parliament of Canada](https://www.parl.ca/) | UNTP supply chain traceability supports annual reporting and import compliance. |

### UN and IGO Instruments

*Map to the outcomes they target so that UNTP becomes the preferred tool for concrete implementation and national capability building.*

| Reference | Authority | Summary |
|---|---|---|
| [UN SDGs](#un-sustainable-development-goals) | [United Nations](https://www.un.org/) | UNTP conformity topics and metrics map to SDG targets, enabling product-level contribution tracking. |
| [UNFCCC Paris Agreement](#unfccc-paris-agreement) | [UNFCCC](https://unfccc.int/) | UNTP emissions metrics support measurement and verification of nationally determined contributions. |
| [UNEP Digital Product Information System](#unep-digital-product-information-system) | [UNEP](https://www.unep.org/) | UNTP provides the decentralised credential infrastructure for UNEP's product information vision. |
| [UNIDO Global Quality and Standards Programme](#unido-global-quality-and-standards-programme) | [UNIDO](https://www.unido.org/) | UNTP provides digital tools for developing-country enterprises to demonstrate conformity to market requirements. |
| [OECD Due Diligence Guidance](#oecd-due-diligence-guidance) | [OECD](https://www.oecd.org/) | UNTP transparency graph operationalises the OECD five-step due diligence framework at scale. |
| [IEA Critical Minerals Traceability](#iea-critical-minerals-traceability-framework) | [IEA](https://www.iea.org/) | UNTP DTEs and DCCs implement the traceability and assurance the IEA framework calls for. |
| [WTO TBT Agreement](#wto-tbt-agreement) | [WTO](https://www.wto.org/) | UNTP's use of international standards and mutual recognition aligns with TBT non-discrimination principles. |
| [WCO AEO Programme](#wco-authorised-economic-operator-programme) | [WCO](https://www.wcoomd.org/) | UNTP Digital Identity Anchors and DCCs can underpin AEO trusted-trader credentialing. |
| [ILO Fundamental Conventions](#ilo-fundamental-conventions) | [ILO](https://www.ilo.org/) | UNTP DCC social conformity topics map directly to ILO core labour standards. |
| [UN Guiding Principles on Business and Human Rights](#un-guiding-principles-on-business-and-human-rights) | [OHCHR](https://www.ohchr.org/) | UNTP transparency graph provides the supply chain visibility the UNGPs' due diligence pillar requires. |
| [UNECE Recommendation 49](#unece-recommendation-49) | [UNECE](https://unece.org/) | UNTP implements the transparency and traceability framework defined by Recommendation 49. |

### Industry Initiatives

*Partner so that industry sustainability and resilience goals are most easily met through UNTP community activation, reducing the cost and complexity of initiative-specific tooling.*

| Reference | Authority | Summary |
|---|---|---|
| [CIRPASS-2](#cirpass-2) | [European Commission](https://commission.europa.eu/) | CIRPASS-2 alignment review confirms architectural interoperability with UNTP across 14 topics. |
| [Battery Pass](#battery-pass) | [Battery Pass Consortium](https://thebatterypass.eu/) | Battery Pass content guidance maps directly to UNTP DPP data model for battery credentials. |
| [GBA](#global-battery-alliance) | [Global Battery Alliance](https://www.globalbattery.org/) | GBA Battery Passport is registered as a UNTP extension; GBA rules map to UNTP DPP and DCC. |
| [GDST](#global-dialogue-on-seafood-traceability) | [GDST](https://traceability-dialogue.org/) | GDST Key Data Elements align with UNTP DTEs for seafood supply chain traceability. |
| [Catena-X](#catena-x) | [Catena-X Automotive Network](https://catena-x.net/) | Catena-X decentralised data exchange architecture is conceptually aligned with UNTP transparency graph. |
| [RMI / RMAP](#responsible-minerals-initiative--rmap) | [RMI](https://www.responsiblemineralsinitiative.org/) | RMAP smelter audit results can be issued as UNTP DCCs; RMI is a registered UNTP conformity scheme. |
| [Coppermark](#coppermark) | [Coppermark](https://coppermark.org/) | Coppermark responsible production criteria map to UNTP DCC conformity topics; registered UNTP scheme. |
| [ASI](#aluminium-stewardship-initiative) | [ASI](https://aluminium-stewardship.org/) | ASI performance and chain-of-custody standards align with UNTP DCC and DTE models. |
| [Textile Exchange](#textile-exchange) | [Textile Exchange](https://textileexchange.org/) | Textile Exchange fibre standards map to UNTP DPP material composition and DCC conformity claims. |
| [RSPO](#roundtable-on-sustainable-palm-oil) | [RSPO](https://rspo.org/) | RSPO supply chain certification aligns with UNTP DTE traceability and DCC conformity models. |

---

## Detailed Sections

### W3C Verifiable Credentials Data Model

**Standard overview**

Credentials — driver's licences, diplomas, visas, permits, invoices — are integral to daily life. [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/) let these credentials be expressed on the web in a cryptographically secure, privacy-respecting, and machine-verifiable way.

**UNTP relationship**

UNTP issues all credentials (product passports (DPP), facility records (DFR), conformity attestations (DCC), traceability events (DTE)) as Verifiable Credentials to ensure security and integrity, regardless of how they are exchanged. UNTP also requires VC rendering templates, ensuring that all UNTP credentials are both human- and machine-readable. The UNTP [VC Profile specification](../specification/VerifiableCredentials.md) provides further detail.

---

### W3C Decentralised Identifiers

**Standard overview**

[W3C Decentralised Identifiers (DIDs)](https://www.w3.org/TR/did-core/) are an identifier type that enables verifiable, decentralised digital identity. A DID refers to any subject — a person, organisation, thing, data model, or abstract entity — as determined by the DID's controller. The design lets the DID owner prove control without requiring permission from any other party. DIDs are commonly used as the issuer identifier for Verifiable Credentials.

**UNTP relationship**

The UNTP Verifiable Credentials Profile requires W3C DIDs as the issuer ID for all credentials (DPP, DCC, DTE, etc.), providing cryptographic, non-repudiable proof of issuer identity. In some cases — similar to well-known websites — a verifier can map a DID to a known identity. In most cases the DID will not be known to the verifier; UNTP therefore defines a Digital Identity Anchor that provides a high-integrity link between a DID and an identity in an authoritative register, such as a national business register.

---

### W3C JSON-LD

**Standard overview**

[JSON-LD](https://www.w3.org/TR/json-ld11/) is a W3C standard for encoding linked data using JSON syntax. It adds a `@context` mechanism that maps JSON keys to globally unique IRIs, enabling semantic interoperability across independently developed systems without requiring a shared schema registry.

**UNTP relationship**

JSON-LD is the linked-data syntax for all UNTP credentials. The UNTP core vocabulary publishes versioned `@context` files that map every UNTP term to its canonical IRI. This enables semantic interoperability and graph-native data querying across the entire transparency graph, allowing verifiers and analytics tools to merge credentials from different issuers without lossy translation.

---

### IETF JOSE

**Standard overview**

The [JOSE (JSON Object Signing and Encryption)](https://datatracker.ietf.org/doc/rfc7515/) family of IETF standards — including JWS (RFC 7515) and JWE (RFC 7516) — defines compact, URL-safe representations for digitally signing and encrypting JSON payloads. JOSE is widely deployed in web infrastructure and supported by every major programming language.

**UNTP relationship**

UNTP mandates JOSE enveloping proof (JWS / RFC 7515) for all Verifiable Credentials. JOSE is preferred over Data Integrity proofs for simplicity and because verification does not depend on `@context` resolution at proof-checking time. This design choice lowers the barrier for implementers and aligns with mainstream web-security tooling.

---

### IETF SD-JWT

**Standard overview**

[SD-JWT (Selective Disclosure for JWTs)](https://datatracker.ietf.org/doc/rfc9449/) is an IETF specification that enables a holder to selectively disclose individual claims from a signed JWT without revealing the entire payload, preserving issuer signatures while supporting privacy.

**UNTP relationship**

UNTP acknowledges SD-JWT but uses variant-based disclosure as the primary selective-disclosure mechanism. Because DPP issuers control credential content, holder-redaction patterns have limited utility in most supply-chain scenarios. There is no incompatibility — SD-JWT can be used alongside UNTP credentials where holder privacy is a requirement.

---

### ISO/IEC 15459

**Standard overview**

[ISO/IEC 15459](https://www.iso.org/standard/54779.html) is a multi-part standard that defines a system of globally unique identifiers for items, transport units, returnable assets, and groupings. It establishes Issuing Agency Codes (IACs) that guarantee uniqueness across identifier schemes.

**UNTP relationship**

UNTP leverages the ISO/IEC 15459 Issuing Agency Code registry for globally unique identifier encoding in barcodes and RFID tags. The UNTP [Identity Resolver specification](../specification/IdentityResolver.md) references 15459 as the foundation for parsing data carriers and extracting structured identifiers.

---

### ISO/IEC 18975

**Standard overview**

[ISO/IEC 18975](https://www.iso.org/standard/85540.html) defines a structured resolution protocol for identifiers encoded in data carriers — 1D barcodes, QR codes, RFID, and digital documents. It specifies how to construct resolution URLs from identifier components and how resolvers return typed links to associated resources.

**UNTP relationship**

ISO 18975 is foundational for the UNTP [Identity Resolver specification](../specification/IdentityResolver.md). The IDR implements the ISO 18975 structured-path syntax and link-type negotiation, enabling any product, facility, or organisation identifier to resolve to its associated UNTP credentials.

---

### ISO 59040 Product Circularity Data Sheet

**Standard overview**

[ISO 59040](https://www.iso.org/standard/82056.html) (the Product Circularity Data Sheet) defines a standard set of measures and a reporting format for product circularity. It covers circular content — the extent to which a product is made from recycled materials — and circular design — the extent to which a product has been designed to facilitate repair, remanufacture, repurposing, and recycling.

**UNTP relationship**

UNTP does not re-invent any ISO 59040 criteria. Instead, the UNTP Digital Product Passport provides a mechanism to digitalise product circularity data while remaining ISO 59040-compliant. The DPP data model includes the organisation, facility, and product metadata ISO 59040 requires. The `conformityClaim` structure within the DPP conveys each specific circularity criterion. Because UNTP DPPs are both human- and machine-readable and carry other sustainability information — such as carbon footprint — manufacturers can issue a single DPP that conforms to multiple sustainability standards.

---

### IFRS S1/S2

**Standard overview**

[IFRS S1 (General Sustainability Disclosures)](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s1-general-requirements/) and [IFRS S2 (Climate-related Disclosures)](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s2-climate-related-disclosures/) are the IFRS Foundation's sustainability reporting standards. They require entities to disclose material sustainability-related risks, opportunities, and climate metrics for investor decision-making.

**UNTP relationship**

The UNTP performance metrics taxonomy is designed so that product- and facility-level sustainability data can be automatically aggregated (rolled up) to enterprise-level IFRS S1 and S2 disclosures. By capturing granular metrics at the point of production, UNTP enables organisations to build IFRS-compliant corporate reports from verifiable, supply-chain-sourced data rather than top-down estimates.

---

### GRI Standards

**Standard overview**

The [GRI Standards](https://www.globalreporting.org/standards/) are the world's most widely used sustainability reporting standards. They define disclosure topics and indicators across environmental (emissions GRI 305, energy 302, water 303, waste 306, biodiversity 304), social (labour 401–409), and governance (anti-corruption 205, supplier environmental 308, supplier social 414) dimensions.

**UNTP relationship**

UNTP metrics categories map directly to GRI indicator families. Product- and facility-level data captured in UNTP credentials can be aggregated to satisfy GRI disclosure requirements, complementing the enterprise-level focus of GRI with verifiable supply-chain evidence.

---

### GHG Protocol

**Standard overview**

The [GHG Protocol](https://ghgprotocol.org/), developed by the World Resources Institute (WRI) and the World Business Council for Sustainable Development (WBCSD), is the most widely used international standard for measuring and reporting greenhouse gas emissions. It defines three scopes: Scope 1 (direct emissions), Scope 2 (purchased energy), and Scope 3 (value-chain emissions).

**UNTP relationship**

UNTP emissions metrics directly implement GHG Protocol scopes 1–3. Digital Facility Records (DFR) capture Scope 1 and 2 emissions at the facility level; Digital Product Passports (DPP) convey embedded (Scope 3) emissions per product. The transparency graph enables verifiers to trace and verify emissions claims across the value chain.

---

### CEN/CENELEC JTC24

**Standard overview**

[CEN/CENELEC JTC24](https://www.cencenelec.eu/) is the joint technical committee responsible for delivering the technical standards — data carriers, identifiers, data exchange — that support the European Commission's Eco-design for Sustainable Products Regulation (ESPR). The committee's outputs define:

- **Unique identifiers** — a system supporting both centralised and decentralised identifiers at model, batch, or item level.
- **Data carriers** — format, error correction, encoding methods, and printing and durability requirements for product data carriers such as QR codes.
- **Data exchange protocols** — an open, secure, high-integrity protocol for exchanging DPP data between systems, including access control for sensitive data.

**UNTP relationship**

An architectural review between UNTP and CEN/CENELEC JTC24 across a 14-topic assessment has confirmed string alignment. Both frameworks use W3C Verifiable Credentials, linked-data semantics, and content-negotiated identity resolution. Operational pilots will planned for Q3 2026 will confirm that the assessed alignment works in practice.

- **Identifiers and carriers:** UNTP maintains a human- and machine-readable register of organisation, facility, and product identifier schemes, including data on how to parse data carriers, resolve identifiers to discover passports, and verify identifier ownership and passport integrity. EU product registers implementing CEN standards are added to the UN register of schemes.
- **Data exchange protocol:** UNTP leverages open technical standards including JSON Schema, W3C JSON-LD semantics, and IETF Linksets. UNTP maps Digital Product Passport data to well-established semantic vocabularies — including vocabulary.uncefact.org and schema.org — and maintains mappings to EU-specific passport data semantics to ensure semantic interoperability.

---

### DIN DKE SPEC 99100

**Standard overview**

[DIN DKE SPEC 99100](https://www.din.de/en/getting-involved/standards-committees/dke/standards/wdc-beuth:din21:372438898) is a German national standard that specifies the content and structure of the battery passport required by the EU Battery Regulation. It defines 88 mandatory and recommended data attributes across seven clusters — general information, carbon footprint, supply chain due diligence, material composition, circularity, performance, and state of health — providing the detailed data model that battery passport implementations must follow.

**UNTP relationship**

The UNTP DPP specification includes a complete attribute-level mapping to all 88 DIN DKE SPEC 99100 data attributes with no gaps. Battery manufacturers implementing UNTP DPPs can satisfy DIN DKE SPEC 99100 requirements directly, using the DPP as the technical vehicle for EU Battery Regulation compliance while maintaining interoperability with global supply chain partners through UNTP's open standards.

---

### ISO 17000

**Standard overview**

[ISO 17000](https://www.iso.org/standard/73029.html) (Conformity assessment — Vocabulary and general principles) defines the terminology and concepts used across the entire ISO/CASCO conformity assessment framework. It establishes the vocabulary for attestation, conformity assessment bodies, accreditation, certification, inspection, and testing — providing the conceptual foundation on which standards such as ISO 17011, 17020, 17021, and 17065 are built.

**UNTP relationship**

The UNTP Digital Conformity Credential (DCC) directly implements ISO 17000 terminology. DCC data model concepts — attestation type, conformity assessment body, assessment level, and the relationship between accreditation and certification — map to ISO 17000 definitions. This ensures that UNTP conformity credentials are semantically consistent with established international conformity assessment practice.

---

### ISO 17011

**Standard overview**

[ISO 17011](https://www.iso.org/standard/67198.html) (Conformity assessment — Requirements for accreditation bodies accrediting conformity assessment bodies) defines the requirements for accreditation bodies that evaluate and accredit conformity assessment bodies (CABs). It establishes a trust hierarchy: a national or international accreditation authority accredits a CAB, which in turn certifies or inspects products, facilities, or management systems.

**UNTP relationship**

The UNTP Digital Conformity Credential (DCC) implements the ISO 17011 accreditation trust hierarchy. The DCC `issuingAuthority` and `accreditationBody` fields model the chain from accreditation authority to conformity assessment body to attestation. This allows verifiers to trace the trust chain from a conformity claim on a product or facility back through the accredited CAB to the accreditation authority, providing machine-verifiable assurance that the assessment was conducted by an accredited body.

---

### ISO 19987

**Standard overview**

[ISO/IEC 19987:2024](https://www.iso.org/standard/78760.html) (EPC Information Services) is a well-established standard for supply chain traceability. It defines six event types that combine to describe a value chain from raw material to finished product: Object Event (e.g. an inspection), Transaction Event (e.g. a shipment from seller to buyer), Aggregation Event (e.g. loading packages onto a pallet), Transformation Event (e.g. a manufacturing process that consumes inputs to create outputs), and Association Event (e.g. linking products to other products or facilities).

**UNTP relationship**

The UNTP Digital Traceability Event (DTE) is a conformant, simplified profile of ISO 19987, identifying the minimum subset needed to support value chain transparency. The DTE profile is optimised for packaging as verifiable credentials and for discovery as linked data, rather than the machine-to-machine API mechanisms the ISO standard defines.

---

### EU Ecodesign for Sustainable Products Regulation (ESPR)

**Regulation overview**

[Regulation (EU) 2024/1781](https://eur-lex.europa.eu/eli/reg/2024/1781) establishes the framework for Digital Product Passports across most product categories placed on the EU market, setting ecodesign requirements covering durability, repairability, recyclability, energy efficiency, and carbon footprint. Sector-specific delegated acts phase in from 2026 (iron and steel) through 2030, with batteries, textiles, and electronics among the earliest categories.

**UNTP relationship**

UNTP DPPs are architecturally interoperable with ESPR product passport requirements. The CIRPASS-2 alignment review confirmed compatibility between UNTP and the CEN/CENELEC JTC24 standards implementing ESPR across 14 assessment topics. UNTP provides a global, decentralised implementation framework that can carry EU-specific ecodesign data alongside other sustainability information, enabling manufacturers to serve both EU regulatory and global voluntary transparency requirements with a single credential.

---

### EU Battery Regulation

**Regulation overview**

[Regulation (EU) 2023/1542](https://eur-lex.europa.eu/eli/reg/2023/1542) requires a digital battery passport (accessible via QR code) for EV and industrial batteries above 2 kWh from February 2027. The passport must convey carbon footprint, recycled content, state of health, material composition, and supply chain due diligence information across a 10-year record.

**UNTP relationship**

The UNTP DPP specification already maps all 88 battery passport data attributes defined by DIN DKE SPEC 99100 (the German national standard implementing the EU Battery Regulation). The Global Battery Alliance extension is registered as a UNTP extension. UNTP provides the interoperable framework for battery passport data exchange, enabling battery data to flow across international supply chains.

---

### EU Carbon Border Adjustment Mechanism (CBAM)

**Regulation overview**

[Regulation (EU) 2023/956](https://eur-lex.europa.eu/eli/reg/2023/956) puts a carbon price on imports of cement, iron and steel, aluminium, fertilisers, electricity, and hydrogen based on embedded emissions. From 2026, importers must purchase CBAM certificates corresponding to the carbon price that would have been paid had the goods been produced under the EU Emissions Trading System. At least 80% of reported emissions must be based on actual data from upstream producers.

**UNTP relationship**

UNTP DPPs carry product-level emissions intensity data, and Digital Facility Records capture Scope 1 and 2 emissions at the facility level. Digital Conformity Credentials from accredited assessors can verify emissions claims. The transparency graph enables tracing embedded emissions back through the supply chain, providing the actual-data evidence CBAM demands.

---

### EU Deforestation Regulation (EUDR)

**Regulation overview**

[Regulation (EU) 2023/1115](https://eur-lex.europa.eu/eli/reg/2023/1115) prohibits placing products linked to post-2020 deforestation on the EU market. It covers seven commodity groups — soy, cattle, palm oil, coffee, cocoa, rubber, and timber — and requires due diligence including geolocation traceability to the plot of land where the commodity was produced.

**UNTP relationship**

UNTP Digital Traceability Events trace commodity flows from origin through transformation events (processing, manufacturing). Digital Facility Records capture facility and plot-of-origin geolocation data. DPPs can carry deforestation-free claims verified by Digital Conformity Credentials from accredited assessors. The transparency graph enables end-to-end traceability from forest or farm to finished product.

---

### EU Corporate Sustainability Reporting (CSRD/ESRS)

**Regulation overview**

[Directive (EU) 2022/2464](https://eur-lex.europa.eu/eli/dir/2022/2464) (CSRD) and the [European Sustainability Reporting Standards (ESRS)](https://eur-lex.europa.eu/eli/reg_del/2023/2772) require large companies to report on sustainability matters across environmental (E1–E5), social (S1–S4), and governance (G1) topics. Scope 3 value chain emissions are a core disclosure requirement, phased in from 2024 to 2028.

**UNTP relationship**

The UNTP performance metrics taxonomy is designed so that product- and facility-level sustainability data can be automatically aggregated to satisfy ESRS disclosures. Product-level DPP data and facility-level DFR data provide the verifiable Scope 3 supply chain evidence that CSRD reporting demands, replacing top-down estimates with bottom-up measured data.

---

### EU Corporate Sustainability Due Diligence Directive (CSDDD)

**Regulation overview**

[Directive (EU) 2024/1760](https://eur-lex.europa.eu/eli/dir/2024/1760) requires large companies to conduct human rights and environmental due diligence across their value chains, with obligations to identify, prevent, mitigate, and account for adverse impacts. Member states must transpose by July 2026.

**UNTP relationship**

UNTP provides the data infrastructure for value chain due diligence. The transparency graph of linked credentials — DPPs, DFRs, DCCs, and DTEs — across multi-tier supply chains gives companies the visibility needed to identify risks and demonstrate due diligence. Digital Conformity Credentials from social and environmental auditors provide verifiable evidence of remediation actions.

---

### EU Forced Labour Regulation

**Regulation overview**

[Regulation (EU) 2024/3015](https://eur-lex.europa.eu/eli/reg/2024/3015) prohibits placing on the EU market any product made using forced labour, regardless of origin. It applies to all economic operators regardless of size from December 2027. Enforcement follows a risk-based approach, with competent authorities empowered to investigate and order product withdrawals.

**UNTP relationship**

UNTP's transparency graph enables tracing products back through the supply chain to verify labour conditions at source. Digital Conformity Credentials from social auditors can attest to forced labour elimination. The UNTP conformity topic taxonomy includes forced labour criteria, and the multi-tier traceability provided by DTEs supports the due diligence that the regulation demands.

---

### EU Critical Raw Materials Act

**Regulation overview**

[Regulation (EU) 2024/1252](https://eur-lex.europa.eu/eli/reg/2024/1252) sets 2030 benchmarks for EU domestic extraction (10%), processing (40%), and recycling (25%) of strategic raw materials. It requires supply chain risk assessments for large manufacturers of strategic technologies and mandates traceability and recycled content requirements for permanent magnets.

**UNTP relationship**

UNTP DPPs can carry critical raw material composition and recycled content data. The Critical Raw Materials Transparency Protocol is already registered as a UNTP extension. Digital Traceability Events trace mineral supply chains from extraction through processing. Digital Facility Records capture extraction and processing facility data including geolocation for supply chain risk assessment.

---

### EU Conflict Minerals Regulation

**Regulation overview**

[Regulation (EU) 2017/821](https://eur-lex.europa.eu/eli/reg/2017/821) requires EU importers of tin, tantalum, tungsten, and gold (3TG) to conduct supply chain due diligence following OECD guidance. It applies to direct importers and covers minerals originating from all conflict-affected and high-risk areas worldwide — a broader geographic scope than the US Dodd-Frank equivalent.

**UNTP relationship**

UNTP Digital Traceability Events trace mineral flows through transformation events (smelting, refining). Digital Facility Records capture facility data with geolocation for conflict zone assessment. Digital Conformity Credentials from audited smelters and refiners verify responsible sourcing. The mass balance chain-of-custody design pattern directly addresses mineral traceability requirements.

---

### US Uyghur Forced Labor Prevention Act (UFLPA)

**Regulation overview**

The [Uyghur Forced Labor Prevention Act](https://www.congress.gov/bill/117th-congress/house-bill/6256) (2022) creates a rebuttable presumption that goods mined, produced, or manufactured wholly or in part in the Xinjiang Uyghur Autonomous Region are made with forced labour. Importers must provide complete supply chain tracing documentation to US Customs and Border Protection (CBP) to rebut the presumption. High-priority sectors include cotton, polysilicon, tomatoes, copper, lithium, and steel.

**UNTP relationship**

UNTP provides exactly the kind of supply chain tracing evidence UFLPA requires. Digital Traceability Events document product origin and transformation; Digital Facility Records establish facility locations; Digital Conformity Credentials from social auditors verify labour conditions. The transparency graph enables the complete, verifiable tracing documentation that CBP demands for rebuttal.

---

### US Dodd-Frank Act Section 1502

**Regulation overview**

[Section 1502 of the Dodd-Frank Act](https://www.congress.gov/bill/111th-congress/house-bill/4173) (2010) requires US-listed companies to determine whether their products contain tin, tantalum, tungsten, or gold (3TG) originating from the Democratic Republic of Congo or adjoining countries. Companies must conduct due diligence on the source and chain of custody and file annual conflict minerals reports with the SEC.

**UNTP relationship**

UNTP Digital Traceability Events trace mineral flows from extraction through smelting and manufacturing. Digital Conformity Credentials from audited smelters (e.g. RMAP-certified) verify responsible sourcing. The transparency graph enables companies to demonstrate chain of custody from mine to product, supporting SEC reporting obligations.

---

### California Climate Disclosure (SB 253 / SB 261)

**Regulation overview**

[SB 253](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320240SB253) (Climate Corporate Data Accountability Act, 2023) requires companies with revenues over $1 billion doing business in California to report Scope 1, 2, and 3 greenhouse gas emissions. [SB 261](https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320240SB261) (Climate-Related Financial Risk Act) requires companies with revenue over $500 million to report climate-related financial risks.

**UNTP relationship**

UNTP emissions metrics align with GHG Protocol scopes 1–3. Product-level DPP data and facility-level DFR data can be aggregated to corporate-level Scope 3 disclosures. UNTP provides verifiable, supply-chain-sourced evidence for emissions claims, supporting the assurance requirements that SB 253 phases in over time.

---

### German Supply Chain Due Diligence Act (LkSG)

**Regulation overview**

The [Lieferkettensorgfaltspflichtengesetz (LkSG)](https://www.gesetze-im-internet.de/lksg/) (2023) requires companies headquartered or operating in Germany with 1,000 or more employees to establish risk management systems for human rights and environmental protection across their supply chains. The Federal Office for Economic Affairs and Export Control (BAFA) enforces compliance with administrative fines and public procurement exclusions.

**UNTP relationship**

UNTP provides the supply chain transparency data infrastructure that LkSG compliance requires. The transparency graph makes it possible to trace human rights and environmental risks through multi-tier supply chains. Digital Conformity Credentials from social and environmental auditors provide verifiable evidence of due diligence measures at the supplier level.

---

### UK Modern Slavery Act

**Regulation overview**

The [Modern Slavery Act 2015](https://www.legislation.gov.uk/ukpga/2015/30), Section 54, requires commercial organisations with annual turnover above GBP 36 million operating in the UK to publish annual modern slavery statements describing steps taken to ensure no slavery or human trafficking exists in their operations or supply chains.

**UNTP relationship**

UNTP transparency data can underpin modern slavery statements with verifiable evidence rather than self-declarations. Digital Conformity Credentials from social auditors provide third-party verification of labour conditions. The transparency graph enables companies to demonstrate multi-tier supply chain visibility — the depth of investigation that regulators and civil society increasingly expect.

---

### Australian Modern Slavery Act

**Regulation overview**

The [Modern Slavery Act 2018 (Cth)](https://www.legislation.gov.au/Details/C2018A00153) requires entities based or operating in Australia with consolidated revenue over AUD 100 million to publish annual modern slavery statements identifying risks in their operations and supply chains and describing actions taken to address them.

**UNTP relationship**

UNTP credentials provide verifiable evidence for modern slavery statements. Digital Conformity Credentials from social auditors verify labour conditions at supplier facilities. Digital Facility Records establish the identity and location of facilities in the supply chain. The transparency graph enables the multi-tier supply chain visibility needed to identify and address modern slavery risks.

---

### Australian Mandatory Climate Disclosure

**Regulation overview**

The [Treasury Laws Amendment (Financial Market Infrastructure and Other Measures) Act 2024](https://www.legislation.gov.au/C2024A00056) requires large Australian businesses and financial institutions to prepare annual sustainability reports with mandatory climate-related financial disclosures aligned with ISSB/IFRS S1 and S2. Reporting is phased in from January 2025, with Scope 3 emissions and reasonable assurance requirements introduced progressively.

**UNTP relationship**

The UNTP performance metrics taxonomy is designed for roll-up to IFRS S1/S2 disclosures, which Australia's framework is aligned to. Product- and facility-level data from UNTP credentials provides the Scope 3 supply chain evidence needed. Because UNTP metrics are ISSB-aligned by design, Australian companies using UNTP can aggregate supply chain data directly into their mandatory climate reports.

---

### Canada Fighting Against Forced Labour and Child Labour Act

**Regulation overview**

The [Fighting Against Forced Labour and Child Labour in Supply Chains Act (S-211)](https://laws-lois.justice.gc.ca/eng/acts/F-10.6/) (2024) requires Canadian entities and government institutions meeting revenue or asset thresholds to report annually on measures taken to prevent and reduce the risk of forced or child labour in their supply chains. Canada also prohibits the import of goods produced by forced or child labour.

**UNTP relationship**

UNTP credentials provide the supply chain tracing evidence needed for annual reporting and import compliance. Digital Traceability Events document product origin and transformation. Digital Conformity Credentials from social auditors verify labour conditions. The transparency graph enables the multi-tier visibility needed to identify forced and child labour risks across complex supply chains.

---

### UN Sustainable Development Goals

**Instrument overview**

The [UN Sustainable Development Goals (SDGs)](https://sdgs.un.org/goals) are 17 interconnected goals adopted by all UN member states in 2015 as a shared blueprint for peace and prosperity. Each goal has specific targets and indicators covering poverty, hunger, health, education, climate, environmental degradation, justice, and partnerships. The SDGs frame the global sustainability agenda through 2030.

**UNTP relationship**

UNTP conformity topics and performance metrics map to SDG targets, enabling product- and facility-level sustainability data to be aggregated as evidence of contribution to specific goals. For example, emissions metrics support SDG 13 (Climate Action), labour conformity topics support SDG 8 (Decent Work), and deforestation-free claims support SDG 15 (Life on Land). UNTP provides the verifiable, granular data layer that turns high-level SDG commitments into measurable supply chain outcomes.

---

### UNFCCC Paris Agreement

**Instrument overview**

The [Paris Agreement](https://unfccc.int/process-and-meetings/the-paris-agreement) (2015) is a legally binding international treaty under the UNFCCC. It commits 196 parties to limit global warming to well below 2°C (preferably 1.5°C) above pre-industrial levels. Each party submits nationally determined contributions (NDCs) setting out its emissions reduction targets and reports progress through a transparency framework.

**UNTP relationship**

UNTP emissions metrics — aligned with GHG Protocol scopes 1–3 — support measurement and verification of the supply chain emissions that underpin national climate targets. Product-level DPP data and facility-level DFR data provide the granular, verifiable evidence needed for the enhanced transparency framework the Paris Agreement demands. By enabling bottom-up emissions tracking across global supply chains, UNTP contributes to the accuracy of national greenhouse gas inventories.

---

### UNEP Digital Product Information System

**Instrument overview**

The [UNEP Digital Product Information System (DPIS)](https://www.unep.org/) initiative explores how digital product information — covering environmental footprint, circularity, and social impact — can be standardised and shared globally to support sustainable consumption and production (SDG 12). DPIS envisions interoperable product information flowing across borders and regulatory jurisdictions.

**UNTP relationship**

UNTP provides the decentralised credential infrastructure for UNEP's product information vision. UNTP Digital Product Passports carry exactly the environmental, circularity, and social data DPIS targets. The identity resolution layer enables discovery of product information from any data carrier. The use of W3C Verifiable Credentials and JSON-LD semantics ensures the interoperability across jurisdictions that DPIS requires.

---

### UNIDO Global Quality and Standards Programme

**Instrument overview**

The [UNIDO Global Quality and Standards Programme (GQSP)](https://www.unido.org/) builds the quality infrastructure — metrology, standardisation, accreditation, and conformity assessment — of developing countries. It helps small and medium enterprises meet the technical requirements of international markets, improving their competitiveness and integration into global value chains.

**UNTP relationship**

UNTP provides digital tools for developing-country enterprises to demonstrate conformity to international market requirements at low cost. Digital Conformity Credentials issued by accredited conformity assessment bodies give SMEs verifiable proof of compliance. The UNTP architecture — built on open standards and designed for low-cost implementation — aligns with UNIDO's goal of inclusive participation in global trade.

---

### OECD Due Diligence Guidance

**Instrument overview**

The [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/en/topics/sub-issues/due-diligence-guidance-for-responsible-business-conduct.html) (2018) provides a five-step framework for companies to identify, prevent, mitigate, and account for adverse human rights, environmental, and governance impacts in their operations and supply chains. Sector-specific annexes cover minerals, garments and footwear, and agriculture. The guidance is endorsed by 50+ governments and forms the operational basis for most national due diligence legislation.

**UNTP relationship**

UNTP operationalises the OECD five-step framework at scale. The transparency graph provides the supply chain mapping and risk identification that steps 1–2 require. Digital Conformity Credentials document the prevention and mitigation actions of step 3. The verifiable, auditable nature of UNTP credentials supports the tracking and communication obligations of steps 4–5. Most national due diligence regulations reference the OECD guidance, making UNTP a common implementation layer across jurisdictions.

---

### IEA Critical Minerals Traceability Framework

**Instrument overview**

The [IEA Critical Minerals Traceability Framework](https://www.iea.org/) addresses the need for transparent, resilient supply chains for minerals essential to the clean energy transition — lithium, cobalt, nickel, rare earths, and copper. It calls for traceability systems that verify provenance, environmental performance, and social conditions from mine to manufactured product.

**UNTP relationship**

UNTP Digital Traceability Events trace mineral flows from extraction through processing and manufacturing. Digital Facility Records capture mine and refinery data including geolocation, emissions, and operating conditions. Digital Conformity Credentials from auditors verify responsible sourcing. The UNTP Critical Raw Materials extension and mass balance chain-of-custody design pattern directly implement the traceability and assurance the IEA framework calls for.

---

### WTO TBT Agreement

**Instrument overview**

The [WTO Agreement on Technical Barriers to Trade (TBT)](https://www.wto.org/english/tratop_e/tbt_e/tbt_e.htm) ensures that technical regulations, standards, and conformity assessment procedures do not create unnecessary obstacles to international trade. It requires members to use international standards where they exist, to apply regulations on a non-discriminatory basis, and to accept conformity assessments from other members through mutual recognition.

**UNTP relationship**

UNTP's design aligns with TBT principles. By building on international standards (W3C, ISO, IETF) rather than creating jurisdiction-specific protocols, UNTP avoids creating technical barriers. The Digital Conformity Credential architecture supports mutual recognition of conformity assessments — a conformity credential issued in one country can be verified and trusted in another. This enables developing-country producers to demonstrate compliance with importing-country requirements without duplicating assessments.

---

### WCO Authorised Economic Operator Programme

**Instrument overview**

The [WCO SAFE Framework of Standards](https://www.wcoomd.org/) establishes the Authorised Economic Operator (AEO) concept, under which customs administrations grant trusted-trader status to supply chain participants that meet security and compliance standards. AEO status provides trade facilitation benefits including expedited clearance, fewer inspections, and mutual recognition between customs authorities.

**UNTP relationship**

UNTP Digital Identity Anchors can link an economic operator's decentralised identifier to their AEO status in a national customs register, providing machine-verifiable proof of trusted-trader credentialing. Digital Conformity Credentials can carry AEO certification evidence. The transparency graph gives customs authorities supply chain visibility that supports both risk assessment and the expedited processing AEO operators expect.

---

### ILO Fundamental Conventions

**Instrument overview**

The [ILO Declaration on Fundamental Principles and Rights at Work](https://www.ilo.org/declaration/lang--en/index.htm) identifies eight fundamental conventions covering freedom of association (C87, C98), forced labour elimination (C29, C105), child labour abolition (C138, C182), and non-discrimination (C100, C111). These conventions define the core labour standards that all ILO member states are expected to respect regardless of ratification status.

**UNTP relationship**

UNTP Digital Conformity Credential social conformity topics map directly to ILO core labour standards. Conformity assessment bodies auditing against forced labour (C29), child labour (C182), freedom of association (C87/C98), and non-discrimination (C100/C111) criteria can issue DCCs that provide machine-verifiable evidence of compliance. The UNTP conformity topic taxonomy includes these ILO-aligned categories, enabling supply chain actors to demonstrate adherence to fundamental labour rights.

---

### UN Guiding Principles on Business and Human Rights

**Instrument overview**

The [UN Guiding Principles on Business and Human Rights (UNGPs)](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf), endorsed by the UN Human Rights Council in 2011, establish a three-pillar framework: the state duty to protect human rights, the corporate responsibility to respect human rights, and access to remedy for victims. The second pillar requires businesses to conduct human rights due diligence — identifying, preventing, mitigating, and accounting for adverse human rights impacts across their operations and value chains.

**UNTP relationship**

UNTP provides the supply chain visibility that the UNGPs' due diligence pillar requires. The transparency graph of linked credentials enables companies to identify human rights risks across multi-tier supply chains. Digital Conformity Credentials from social auditors provide verifiable evidence of prevention and mitigation actions. The UNGPs are the foundational framework behind the OECD Due Diligence Guidance and most national due diligence legislation — UNTP serves as a common digital implementation layer for all of them.

---

### UNECE Recommendation 49

**Instrument overview**

[UNECE Recommendation 49](https://unece.org/trade/uncefact/guidance-material) (Transparency at Scale) provides a framework for transparent, traceable, and sustainable value chains. It defines principles and guidelines for using verifiable credentials, decentralised identifiers, and linked data to exchange sustainability and traceability information across international supply chains. Recommendation 49 was developed by UN/CEFACT as the policy foundation for the UNTP technical specification.

**UNTP relationship**

UNTP is the technical implementation of UNECE Recommendation 49. Every UNTP specification — Digital Product Passport, Digital Conformity Credential, Digital Traceability Event, Digital Facility Record, Digital Identity Anchor, and Identity Resolver — implements the architecture and principles that Recommendation 49 defines. The recommendation provides the policy mandate and governance framework; UNTP provides the technical standards, data models, and interoperability protocols.

---

### CIRPASS-2

**Initiative overview**

[CIRPASS-2](https://cirpassproject.eu/) is the EU-funded coordination and support action that develops the standardisation roadmap and interoperability framework for Digital Product Passports under the ESPR. Building on the original CIRPASS project, CIRPASS-2 conducts alignment assessments with international DPP initiatives and defines the technical architecture for EU product passports across priority sectors.

**UNTP relationship**

The CIRPASS-2 alignment review assessed UNTP against 14 topics and confirmed architectural interoperability. Both frameworks share W3C Verifiable Credentials, linked-data semantics, and content-negotiated identity resolution. CIRPASS-2 operates as a compatible EU regulatory profile within the broader UNTP architecture — an EU manufacturer implementing UNTP can satisfy ESPR DPP requirements with minimal additional effort, and vice versa.

---

### Battery Pass

**Initiative overview**

The [Battery Pass](https://thebatterypass.eu/) consortium (2022–2025), funded by the German Federal Ministry for Economic Affairs and Climate Action, developed the content guidance and technical standards for the EU Battery Regulation's battery passport. It defined 88 mandatory and recommended data attributes across seven clusters and produced a reference implementation demonstrating data exchange between supply chain actors.

**UNTP relationship**

The Battery Pass content guidance maps directly to the UNTP DPP data model. The UNTP DPP specification includes a complete attribute-level mapping to DIN DKE SPEC 99100 (which codified the Battery Pass outputs). Battery manufacturers can use UNTP DPPs as the technical vehicle for issuing battery passports that satisfy EU Battery Regulation requirements while remaining interoperable with global supply chain partners.

---

### Global Battery Alliance

**Initiative overview**

The [Global Battery Alliance (GBA)](https://www.globalbattery.org/) is a public-private partnership of 200+ organisations working to establish a sustainable and responsible battery value chain. GBA defines the Battery Passport rulebook covering greenhouse gas emissions, human rights, child labour, recycled content, and responsible sourcing across the battery lifecycle.

**UNTP relationship**

The GBA Battery Passport is registered as a UNTP extension. GBA rulebook criteria map to UNTP DPP sustainability metrics and DCC conformity topics. By activating through the UNTP community, GBA members can issue interoperable battery credentials that satisfy both GBA rules and regulatory requirements (EU Battery Regulation, CBAM) using a single technical framework.

---

### Global Dialogue on Seafood Traceability

**Initiative overview**

The [Global Dialogue on Seafood Traceability (GDST)](https://traceability-dialogue.org/) is an international, business-to-business platform that developed interoperability standards for seafood traceability. GDST defines Key Data Elements (KDEs) and Critical Tracking Events (CTEs) for wild-capture and aquaculture supply chains, built on GS1/EPCIS foundations.

**UNTP relationship**

GDST Key Data Elements and Critical Tracking Events align with UNTP Digital Traceability Events, which are themselves a simplified profile of ISO 19987 (EPCIS). Seafood supply chain actors using GDST standards can issue UNTP DTEs as verifiable credentials, adding cryptographic integrity and linked-data discoverability to existing traceability data. UNTP DPPs can carry species, catch area, and sustainability certification data relevant to seafood markets.

---

### Catena-X

**Initiative overview**

[Catena-X](https://catena-x.net/) is the automotive industry's collaborative data ecosystem for secure, sovereign data exchange across the value chain. It defines standards for data models, digital twins, and decentralised data exchange covering use cases including carbon footprint tracking, circularity, traceability, and supply chain resilience. Catena-X operates through certified operating companies and data exchange infrastructure.

**UNTP relationship**

Catena-X's decentralised data exchange architecture is conceptually aligned with the UNTP transparency graph — both enable multi-tier supply chain data sharing without centralised platforms. Catena-X product carbon footprint data models overlap with UNTP DPP emissions metrics. The partnership opportunity lies in cross-industry interoperability: automotive supply chains intersect with mining, metals, chemicals, and electronics sectors where UNTP is also active.

---

### Responsible Minerals Initiative / RMAP

**Initiative overview**

The [Responsible Minerals Initiative (RMI)](https://www.responsiblemineralsinitiative.org/) provides tools and resources for companies to make sourcing decisions that improve regulatory compliance and support responsible mineral production. The Responsible Minerals Assurance Process (RMAP) is an independent third-party audit programme that assesses smelter and refiner management systems against responsible sourcing standards for tin, tantalum, tungsten, gold, cobalt, and mica.

**UNTP relationship**

RMI is a registered UNTP conformity scheme. RMAP smelter audit results can be issued as UNTP Digital Conformity Credentials, providing machine-verifiable proof that a smelter or refiner has been independently assessed against responsible sourcing criteria. UNTP Digital Traceability Events trace mineral flows through RMAP-audited facilities, enabling downstream manufacturers to demonstrate responsible sourcing for Dodd-Frank, EU Conflict Minerals, and OECD Due Diligence compliance.

---

### Coppermark

**Initiative overview**

[Coppermark](https://coppermark.org/) is a comprehensive assurance framework for the copper, molybdenum, nickel, and zinc value chains. It assesses mine sites and downstream facilities against 32 ESG criteria covering community, business, environmental, labour, and governance issues, aligned with the UN SDGs and referenced by major industry buyers.

**UNTP relationship**

Coppermark is a registered UNTP conformity scheme. Coppermark's 32 ESG criteria map to UNTP DCC conformity topics across environmental, social, and governance dimensions. Coppermark assessment results can be issued as UNTP Digital Conformity Credentials, enabling mine operators and processors to provide machine-verifiable proof of responsible production to downstream buyers, regulators, and investors.

---

### Aluminium Stewardship Initiative

**Initiative overview**

The [Aluminium Stewardship Initiative (ASI)](https://aluminium-stewardship.org/) operates two certification standards: the Performance Standard (covering governance, environment, social, and material stewardship at facility level) and the Chain of Custody Standard (tracking responsible aluminium through the value chain using mass balance or market credits). ASI certification is increasingly referenced by automotive and construction buyers and relevant to EU CBAM compliance.

**UNTP relationship**

ASI Performance Standard criteria align with UNTP DCC conformity topics. ASI Chain of Custody certification aligns with UNTP DTE chain-of-custody design patterns. ASI-certified facilities can issue UNTP Digital Conformity Credentials as machine-verifiable proof of certification. UNTP DPPs for aluminium products can carry embedded emissions data (supporting CBAM) alongside ASI certification claims.

---

### Textile Exchange

**Initiative overview**

[Textile Exchange](https://textileexchange.org/) develops and manages a suite of fibre and materials standards — including the Organic Content Standard (OCS), Recycled Claim Standard (RCS), Global Recycled Standard (GRS), and Responsible Wool Standard (RWS). These standards provide chain-of-custody certification for sustainable fibres from source to finished textile product.

**UNTP relationship**

Textile Exchange fibre standards map to UNTP DPP material composition data and DCC conformity claims. Chain-of-custody certification at each supply chain stage can be issued as UNTP Digital Traceability Events and Conformity Credentials. As the EU ESPR phases in textile DPP requirements, Textile Exchange certification data can flow through UNTP credentials to satisfy both voluntary buyer requirements and regulatory obligations.

---

### Roundtable on Sustainable Palm Oil

**Initiative overview**

The [Roundtable on Sustainable Palm Oil (RSPO)](https://rspo.org/) is a multi-stakeholder initiative that develops and implements global standards for sustainable palm oil. RSPO certification covers environmental criteria (no deforestation, no peat, no fire), social criteria (labour rights, community consent), and supply chain models (identity preserved, segregated, mass balance, book and claim).

**UNTP relationship**

RSPO supply chain certification aligns with UNTP DTE traceability and DCC conformity models. RSPO's supply chain models — particularly identity preserved and segregated — map to UNTP chain-of-custody design patterns. UNTP DTEs can trace palm oil from plantation through mill to refinery with geolocation data supporting EUDR compliance. RSPO certification can be issued as UNTP DCCs, providing machine-verifiable proof of sustainable sourcing.

---

## Requirements

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

*Normative*

## UNTP Business Requirements

This page summarises the high-level business requirements for UNTP, grouped into seven categories. Each requirement links to the page where its solution is defined.

| Category | Focus |
|---|---|
| [1. Governance Requirements](#1--governance-requirements) | UNTP is governed openly and transparently, is freely available to all, and is extensible to meet specific industry and jurisdictional needs. |
| [2. Architectural Requirements](#2--architectural-requirements) | UNTP is scalable enough to achieve global implementation at volumes sufficient to have a material impact on traceability. |
| [3. Traceability & Transparency Requirements](#3--traceability--transparency-requirements) | UNTP provides the traceability and transparency data each supply chain actor needs to meet due diligence obligations and customer expectations. |
| [4. Trust & Integrity Requirements](#4--trust--integrity-requirements) | UNTP provides data that is trustworthy and resilient to scrutiny. |
| [5. Security & Confidentiality Requirements](#5--security--confidentiality-requirements) | UNTP protects the security and confidentiality of supply chain data, letting each actor choose their own balance between traceability and transparency. |
| [6. Compatibility & Interoperability Requirements](#6--compatibility--interoperability-requirements) | UNTP is compatible with existing standards for technology, ESG criteria, and supply chain practices so that implementers can maximise existing investments. |
| [7. Implementation Requirements](#7--implementation-requirements) | UNTP is implementable at the lowest possible cost, gives early implementers a market advantage, and allows the impact of implementations to be tracked. |

---

### 1 — Governance Requirements

UNTP must be governed openly and transparently, freely available to all, and extensible to meet specific industry and jurisdictional needs.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| GV.01 | Consensus-driven process | UNTP development MUST follow a transparent, consensus-driven process open to all stakeholders, so that implementers can be confident UNTP will meet their requirements. | [Governance](../governance) |
| GV.02 | Freely available | The UN MUST own UNTP intellectual property, and access and use MUST remain permanently free, so that implementers face no fees or IP infringement claims. | [Governance](../governance) |
| GV.03 | Backwards compatible | New minor versions of UNTP MUST be backwards compatible within the same major version. Each major version MUST remain active and supported for at least two years, so that implementers can rely on the durability of their investment. | [Governance](../governance) |
| GV.04 | Open source | UNTP implementation tools, including reference implementations and test services, MUST be available under open source and royalty-free licensing, so that implementers can minimise their own implementation costs. | [Tools & Support](../tools-and-support/index.md) |
| GV.05 | Extensible | UNTP MUST define a non-breaking extensions methodology, so that UNTP can be extended to meet specific jurisdictional or industry requirements and implementers of a registered extension can be confident their implementation is interoperable with UNTP core. | [Extensions Methodology](../tools-and-support/ExtensionsMethodology.md) |
| GV.06 | Reusable extensions | Industry and jurisdictional extensions to UNTP SHOULD be governed by an open process and released under royalty-free licence terms, so that extension implementers have the same fees and IP confidence as with UNTP core. | [Extensions Methodology](../tools-and-support/ExtensionsMethodology.md) |
| GV.07 | Implementation register | UNTP MUST provide a mechanism for implementers to register their planned and actual implementations, so that implementers can publish their sustainability commitment and conformant solutions for discovery by a global community of users and customers. | [Implementations](../implementations/) |

---

### 2 — Architectural Requirements

UNTP must scale to global implementation volumes sufficient to have a material impact on traceability. Building on existing industry systems and using the simplest framework that meets the goals makes this achievable.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| AR.01 | Protocol over platform | UNTP MUST define a standard protocol that any business software system can implement, so that every supply chain actor can continue using their preferred software without requiring upstream or downstream actors to agree on shared platforms. | [Architecture](../specification/Architecture.md) |
| AR.02 | Decentralisation | UNTP MUST define a decentralised protocol in which data is stored wherever the owner chooses, so that supply chain actors retain control of their data and can monetise their evidence of sustainable behaviour. | [Architecture](../specification/Architecture.md) |
| AR.03 | Natural business identifiers | UNTP MUST accommodate existing natural business, product, batch, and shipment identifiers, so that UNTP implementation imposes minimal disruption to existing business processes and can leverage existing business and product registers. | [Identifiers](../specification/IdentityResolver.md) |
| AR.04 | Technical maturity | UNTP MUST accommodate varying levels of technical maturity — from paper-based documents to fully digitalised systems — so that any implementer can proceed without depending on the capability or readiness of upstream or downstream actors. | [Human Rendering](../specification/VerifiableCredentials#render-method), [resolvability](../specification/IdentityResolver#resolution-and-linksets) |
| AR.05 | Simplest possible core | UNTP MUST prioritise simplicity by specifying only the minimum that represents common core needs across different jurisdictions and industries, so that implementation costs are minimised and interoperability is maximised. | [Architecture](../specification/Architecture.md) |
| AR.06 | Re-use, not re-invent | UNTP MUST re-use existing open and free standards — such as W3C Verifiable Credentials and UN vocabularies — wherever they are fit for purpose, so that interoperability is maximised and existing software investments are reused. | [Architecture](../specification/Architecture.md) |

---

### 3 — Traceability & Transparency Requirements

UNTP must provide the traceability and transparency data each supply chain actor needs to meet due diligence obligations and customer expectations for verifiable evidence of sustainable practices.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| TT.01 | Data carriers | UNTP MUST define consistent methods for discovering product data from both new and existing data carriers — ID barcodes, 2D matrix codes, QR codes, and RFID tags — so that any party holding only a product batch ID or shipment ID can find ESG data for that product or shipment. | [Identity Resolver](../specification/IdentityResolver) |
| TT.02 | Item/batch granularity | UNTP MUST provide data at the granularity of individual items or batches in a shipment, so that downstream actors can aggregate material inputs — such as Scope 3 emissions — into their own ESG performance data. | [Digital Product Passport](../specification/DigitalProductPassport.md)  |
| TT.03 | End-to-end traceability | Subject to privacy and confidentiality constraints, the UNTP traceability model MUST trace value chains from finished product to raw materials across any number of commercial boundaries (sale of goods), logistics boundaries (consolidation and deconsolidation), and process boundaries (manufacturing transformation of inputs to outputs), so that the provenance and ESG footprint of goods can be verified as the sum of parts. | [Traceability Events](../specification/DigitalTraceabilityEvents.md) |
| TT.04 | Sustainability data | UNTP MUST provide a consistent, straightforward way to access and verify all available sustainability metrics — carbon intensity, deforestation, water usage, fair work, etc. — for a given product item or batch, so that product buyers can meet their sustainability and due diligence obligations. | [Digital Product Passport](../specification/DigitalProductPassport.md), [Conformity Credential](../specification/ConformityCredential.md)|
| TT.05 | Provenance data | UNTP MUST provide verifiable provenance information — raw material content and manufacturing origin countries — for a given product item or batch, so that product buyers can meet supply chain resilience and goods origin controls. | [Digital Product Passport](../specification/DigitalProductPassport.md), Guarantee of Origin |
| TT.06 | Circularity data | UNTP MUST provide a simple mechanism to access circularity data — including recycled content metrics and end-of-life recycling information — so that product buyers can meet recycled content goals and recyclers can optimise their processes. | [Digital Product Passport](../specification/DigitalProductPassport.md), Circularity Data |
| TT.07 | ESG vocabulary | Given the volume and diversity of ESG standards and regulations, UNTP MUST define a scalable, straightforward mechanism to determine both the precise meaning and the general category of ESG claims, so that downstream actors can map either the specific criteria or the general category of ESG data with confidence. | [Vocabulary](../specification/ConformityVocabularyCatalog.md) |
| TT.08 | Rules as code | UNTP MUST define a mechanism to simplify compliance assessment of entities, products, and processes against the fast-growing set of ESG standards and regulations, so that any actor's investment in sustainable ESG practices can be tested against multiple criteria. | [ESG Rules](../specification/ConformityVocabularyCatalog) |

---

### 4 — Trust & Integrity Requirements

UNTP must provide data that is trustworthy and resilient to scrutiny.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| TI.01 | Trust anchors | Trust in the authenticity of sustainability claims can be established through third-party audits, attestation by trusted authorities, or long-standing evidence of sustainable behaviour. UNTP MUST provide a mechanism to link ESG claims to any or all of these trust anchors, so that downstream actors can be confident that claimed ESG performance is genuine. | [Trust anchors](../design-patterns/TrustGraphs.md) |
| TI.02 | Identity integrity | UNTP MUST provide a mechanism to verify that ESG claims about products, locations, or entities are made by actors who genuinely own the identifiers or are their authorised delegates, so that downstream actors can be sure parties are genuinely authorised to make such claims. | [Identity Anchors](../specification/IdentityResolver.md) |
| TI.03 | Accreditation | Third-party audits and assessments add trust. Where a verifier does not know the auditor or certifier, UNTP MUST provide a mechanism to link third-party certifiers to the accreditation authority under which they operate, so that downstream actors can trust certificates even when they do not know the certifiers. | [Conformity](../specification/ConformityCredential.md) |
| TI.04 | Document verification | UNTP MUST define standard, interoperable mechanisms to prevent spoofing or tampering with any documents issued by upstream actors, so that downstream actors can be confident that claimed identity and genuine ESG credentials have not been altered. | [Verifiable Credentials](../specification/VerifiableCredentials.md) |
| TI.05 | Graph verification | ESG performance evidence in supply chains is not concentrated in a single document but distributed throughout the value chain. UNTP MUST define a mechanism to describe and verify evidence available from chains of linked documents, so that downstream actors can ascertain the complete ESG footprint and provenance data for any shipment. | [Trust Graphs](../design-patterns/TrustGraphs.md) |
| TI.06 | Product substitution | As the brand value of verifiably sustainable products increases, so does the incentive to attach fake products to genuine sustainability evidence. UNTP MUST define an anti-counterfeiting mechanism so that downstream actors can confirm they have purchased genuine goods. ||
| TI.07 | Mass balance fraud | Mass balance fraud occurs when a supply chain actor blends sustainable materials with cheaper non-sustainable materials and then claims the manufactured product is 100% sustainable. UNTP MUST define mechanisms to detect mass balance fraud, so that downstream actors can be confident in the integrity of their sustainable supply chain and that the value of sustainable products is maintained. | [Chain of Custody](../design-patterns/MassBalance.md) |

---

### 5 — Security & Confidentiality Requirements

UNTP must protect the security and confidentiality of supply chain data, letting each actor choose their own balance between traceability and transparency.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| SC.01 | Transparency vs confidentiality | UNTP MUST allow every supply chain actor to choose their own balance between transparency and confidentiality, so that each actor can share only what delivers value while protecting information they deem confidential. | [Confidentiality](../specification/DecentralisedAccessControl.md)   |
| SC.02 | Multi-layered security | Product information ranges from public to highly confidential. UNTP MUST provide a range of data protection mechanisms that supply chain actors can apply appropriately to choose the right protection level for specific data sets. | [Confidentiality](../specification/DecentralisedAccessControl.md)   |
| SC.03 | Selective redaction | ESG data and credentials from sellers may contain information buyers do not want to pass on to their customers. UNTP MUST define a selective redaction method that lets any supply chain actor redact information — without affecting cryptographic integrity — from upstream credentials before passing them to downstream customers, so that verifiable ESG data can flow without leaking commercially sensitive data. | [Confidentiality](../specification/DecentralisedAccessControl.md)   |
| SC.04 | Revocation | UNTP MUST provide a mechanism to revoke previously issued conformity certificates when an actor is found non-compliant, so that downstream actors can be confident in the currency of the ESG assessments they receive. | [Verifiable Credentials](../specification/VerifiableCredentials.md) |
| SC.05 | Availability | UNTP MUST define a mechanism to ensure high availability and long-term durability of ESG evidence, so that verifiers can access data even when source systems are down — and so that data for long-use-cycle products such as batteries or building materials remains accessible long after source systems are retired. | [Verifiable Credentials](../specification/VerifiableCredentials.md) |
| SC.06 | Cryptography | UNTP MUST support flexibility in cryptographic methods so that new algorithms can be adopted as they emerge to meet new challenges such as quantum computing. | [Verifiable Credentials](../specification/VerifiableCredentials.md) |
| SC.07 | Key management | UNTP MUST provide mechanisms for discovering public keys, protecting private keys, and rotating key pairs, so that keys remain secure and can be re-chained if compromised. | [Verifiable Credentials](../specification/VerifiableCredentials.md) |

---

### 6 — Compatibility & Interoperability Requirements

UNTP must be compatible with existing standards for technology, ESG criteria, and supply chain practices so that implementers can maximise the leverage of existing investments.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| CI.01 | National regulations | UNTP-conformant data SHOULD be straightforward to map to national ESG regulations, so that it can provide upstream B2B ESG evidence to support national B2C product conformance. | [Vocabulary](../specification/ConformityVocabularyCatalog), [Extensions Methodology](../tools-and-support/ExtensionsMethodology.md) |
| CI.02 | Entity ESG reporting | UNTP-conformant ESG data on products and shipments MUST be straightforward to map to entity-level ESG reporting obligations, so that transaction-level UNTP data can be easily aggregated to inform annual ESG reporting conforming to standards such as IFRS Sustainability. | [Vocabulary](../specification/ConformityVocabularyCatalog) |
| CI.03 | ESG standards | UNTP MUST support ESG claims against criteria from any ESG standard and MUST provide a mechanism to map those claims to a common vocabulary, so that implementers can align with standards of their choice and verifiers can interpret claims even when unfamiliar with specific standard criteria. | [Vocabulary](../specification/ConformityVocabularyCatalog) |
| CI.04 | Credential interoperability | The verifiable credential landscape is fast-moving. UNTP MUST work with multiple technical credential standards — including W3C VCs, IETF JWT, and ISO mDL — and MUST specify a minimal, simple profile of each, so that interoperability between different implementations is maximised. |[Verifiable Credentials](../specification/VerifiableCredentials.md), Other Profiles TBD |
| CI.05 | Blockchain independence | Whilst some implementers MAY choose blockchain technologies, UNTP MUST NOT require blockchain for conformant implementations, so that implementers who wish to avoid the costs and complexity of blockchain are free to do so. | — |
| CI.06 | Product identifier compatibility | UNTP MUST allow industry to continue using its preferred existing product identifier schemes and MUST NOT favour one scheme over another. | [Identity Resolver](../specification/IdentityResolver) |
| CI.07 | Business and facility identifier compatibility | UNTP MUST define a mechanism to support existing identity registers, so that implementers can continue to leverage business identifiers such as tax registration numbers, facility identifiers, and location identifiers under UNTP. | [Identity Resolver](../specification/IdentityResolver), [Identifier Registers](../implementations/idr/) |

---

### 7 — Implementation Requirements

UNTP must be implementable at the lowest possible cost, give early implementers a market advantage, and allow the impact of implementations to be tracked.

| ID | Name | Requirement | Solution |
|---|---|---|---|
| IM.01 | Business case | Every UNTP implementer needs confidence that implementation benefits outweigh costs. UNTP SHOULD provide business case templates for each stakeholder type so that decision-makers can fast-track their decision to proceed. | [Business Case](../business-case/index.md) |
| IM.02 | Open source tools | UNTP MUST include an open-source reference implementation that any supply chain actor can embed in their solutions to fast-track implementation. | [Tools](../tools-and-support/ReferenceImplementation.md) |
| IM.03 | Conformity testing | UNTP MUST include a conformance test suite and test service so that implementers can self-assess conformance and be confident their implementations will be interoperable. | [Test service](../tools-and-support/TestService.md) |
| IM.04 | Implementation support | UNTP MUST provide mechanisms for implementers to obtain community or professional support to minimise implementation risk. | [Support](../tools-and-support/HelpAndSupport.md) |
| IM.05 | Tracking implementations | UNTP MUST provide a mechanism to track implementations so that uptake and impact can be measured and early implementers can publicise their solutions. | [Implementations](../implementations/)  |
| IM.06 | Tracking extensions | UNTP MUST provide a mechanism to track and publish industry and jurisdictional extensions so that new extensions can find and reuse relevant work. | [Extensions Register](../implementations/ext/) |
| IM.07 | Tracking outcomes | Uptake is a straightforward measure of success, but UNTP's real purpose is to lift the value of sustainable practices. UNTP MUST develop a set of KPIs to track and assess whether it achieves material impact. | [Greenwashing KPIs](../business-case/ImpactAssessmentFramework.md) |

---

**Key changes:**

- **Requirement statements tightened throughout:** Redundant preamble removed from the start of each statement — "The UNTP MUST define a standard protocol that is easy to implement" → "UNTP MUST define a standard protocol that any business software system can implement."
- **Active voice in requirement statements:** "can be established", "is stored", "are made by actors" recast where the subject was clear.
- **Omit needless words:** "in a straightforward and consistent way", "in any way", "both…and" constructions tightened throughout.
- **Numbering anomaly corrected:** TT.07 Rules as Code appeared in the Architectural Requirements section in the source — moved to Traceability & Transparency where it belongs, renumbered as TT.08, and a placeholder AR row removed.
- **Column header "Requirement Statement" → "Requirement":** Shorter and unambiguous.
- **Category introductions:** Each rewritten as a single plain sentence rather than a passive description of intent.
- **PDF formatting artefacts removed:** Broken words, missing spaces, and run-together text from PDF extraction cleaned throughout.

---

## About the UNTP

import Disclaimer from '../\_disclaimer.mdx';
import YouTube from '@site/components/YouTube';

<Disclaimer />

*Informative*

## The United Nations Transparency Protocol (UNTP)

UNTP provides a solution to the transparency challenges facing the world's supply chains. By implementing a simple protocol that can be supported by existing business systems, stakeholders will realise immediate benefits and will become visible contributors to the sustainability of global supply chains. 

Crucially, **UNTP is a protocol,** *not a platform*. The UNTP focuses on interoperability standards that allow any technology platform to participate in interoperable and sustainable value chains. The UNTP defines an architecture comprising standards for [product data](../specification/DigitalProductPassport.md), [facility data](../specification/DigitalFacilityRecord.md), [traceability data](../specification/DigitalTraceabilityEvents.md), [conformity data](../specification/ConformityCredential.md), and [identity data](../specification/DigitalIdentityAnchor.md). 

Each supply chain actor can independently implement UNTP without imposing technical dependencies on any other upstream or downstream actor. In this way, the traceability and transparency information describing arbitrarily complex value chains can "emerge" in a bottom-up manner, like pixels illuminating one by one on a TV screen. Additonally, the UNTP includes security and confidentiality tools that allow each actor to choose their own balance between confidentiality and transparency.  

The diagram below provides a conceptual model for the scope of UNTP and the value chain picture that it can reveal.

![UNTP Value Chain](UNTP-ValueChainModel.png)

## UN/CEFACT Recommendation 49

*Recommendation 49: Transparency at Scale – Fostering Sustainable Value Chains* was developed in response to an increasing demand for policy action to leverage and enhance the trust in sustainability information. Its development was motivated by
the practical challenges2 that United Nations (UN) Member States face in advancing
implementation of the Sustainable Development Goal (SDG) 12 of the UN 2030 Agenda for ensuring sustainable consumption and production patterns through traceability in value chains.

In July 2025, The UN/CEFACT Plenary Member States adopted [Recommendation No. 49: Transparency at Scale – Fostering Sustainable Value Chains](https://unece.org/trade/documents/2025/07/session-documents/revised-recommendation-no-49-transparency-scale-fostering).

*The UNTP is the practical application of Recommendation 49.*

Watch a 6 minute overview of UNTP:

<YouTube id="vVWYDxUA9IE" />

## Incentives for sustainable supply chains are on the rise

Incentives for sustainable supply chains continue to increase.

* Regulations such as the European [Regulation on Deforestation](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en) (EUDR) and [Carbon Border Adjustment Mechanism](https://taxation-customs.ec.europa.eu/carbon-border-adjustment-mechanism_en) (CBAM) will present market access barriers or increased border tariffs for non-sustainable produce.
* These regulations impose [due diligence obligations](https://commission.europa.eu/business-economy-euro/doing-business-eu/corporate-sustainability-due-diligence_en) on entire supply chains, not just final products. Penalties for repeated non-compliance can be as high as 4% of global revenue.
* Financial institutions are rapidly moving to ensure that capital is preferentially focussed on ESG assets. [According to Bloomberg](https://www.bloomberg.com/professional/blog/esg-assets-may-hit-53-trillion-by-2025-a-third-of-global-aum/), within a few years, around $50 Trillion or one third of all global assets under management will be ESG assets.
* Consumer sentiment is driving purchasing decisions to favour sustainable products. At the same time, consumers are increasingly mistrustful of unverifiable claims and look for third party certification based on trusted standards.

## Challenges

The world's supply chains must reach to the point where digitally verifiable traceability and transparency information is available to meet regulatory compliance, satisfy investors, and motivate consumers for the majority of products on the market. However, achieving transparency at that scale presents some challenges.

* **Which software to choose?** There are many traceability & transparency solutions on the marketplace. Many expect all actors in a given value chain to subscribe to the same platform in order to collect the data for end-to-end traceability. However, just as expecting your customers and suppliers to create accounts at your bank so that you can pay them is not rational or practical (that's why inter-bank payment standards exist), so the adoption of all actors in value chains to one platform is also not feasible or scalable. 
As the UNTP is a protocol standard, not a platform, it assumes that supply chain data remains with each natural owner. So the answer to "which software to choose?" is "Pick any, so long as it conforms to the UNTP".

* **Coping with a growing mountain of ESG standards and regulations.** The number of ESG standards and regulations worldwide currently exceeds 1,000. These standards and regulations are specific to particular commodities, jurisdictions, or ESG criteria and some cover multiple dimensions. There is a significant overlap between them but very little formal mutual recognition. The consequence is that it becomes very challenging for supply chain actors that sell to multiple export markets to know which criteria matter and how to demonstrate compliance. The UNTP does not add to the complexity by defining more ESG standards. Rather it seeks to minimise cost of compliance by making it simpler to test on-site ESG processes and data against multiple ESG criteria. Essentially this is about implementing a sustainable practice once and then re-using it to satisfy multiple overlapping criteria.

* **Protecting confidential information.** "Sunlight is the best auditor" and so verifiable transparency is the best greenwashing counter-measure. However, increased supply chain transparency for ESG purposes also risks exposure of commercially sensitive information. A viable transparency protocol must allow supply chain actors to share ESG evidence whilst protecting sensitive information. Rather than dictate what must be shared and what should not, the UNTP includes a suite of confidentiality measures that allow every supply chain actor to choose their own balance between confidentiality and transparency. The basic principle is that actors should be empowered to share only what delivers value.

* **Making a business case for implementation.** Each supply chain actor (or their software provider) will need to make a viable business case for implementation of the UNTP. The transparency incentives discussed in this section represent the benefit side of the equation. To keep the cost side as low as practical, UNTP has a strong "keep it simple" focus and offers a suite of implementation tools to further reduce cost. Some sample business case templates are provided to help actors make their case for action.

![Transparency Challenges](TransparencyChallenges.png)

## Presentations & Videos

|Title|Duration|Description|Presentation|Video|
|--|--|--|--|--|
|Business Overview|5:45 min|UNTP Overview for non-technical consumers - the problem of scalable automated supply chain compliance assessment and how UNTP solves it|[PPT](../assets/files/untp.business-overview.pptx)|[Youtube](https://youtu.be/vVWYDxUA9IE)|
|Technical Overview| |UNTP overview for technical consumers - the UNTP architecture and technical specifications.|coming soon|coming soon|

---

## Case for Schemes and Registers

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Purpose

The purpose of this page is to provide a structured framework for building a business case for UNTP conformance by the services that form the trust infrastructure on which UNTP depends. While the [business case for industry](BusinessCaseIndustry.md) and [business case for government](BusinessCaseGovernment.md) address the demand side — organisations that produce, trade, and regulate goods — this page addresses the supply side: the services that issue credentials, publish vocabularies, and operate the identity infrastructure that makes UNTP work at scale.

Without these services, UNTP cannot function:

- Without **conformity schemes** publishing digital criteria vocabularies, Digital Conformity Credentials (DCCs) cannot reference standardised conformity topics and performance metrics.
- Without **conformity assessment bodies (CABs)** issuing DCCs, there is no third-party verification of sustainability claims.
- Without **identity registers** issuing Digital Identity Anchors (DIAs), there is no trust anchor linking DIDs to verified legal entities.
- Without **identity resolver operators** hosting resolver infrastructure, there is no discovery mechanism for DPPs, DCCs, and DTEs.

This page makes the case for each of these service types to invest in UNTP conformance, using the same cost/benefit structure as the industry and government pages.

Note: The economic impacts described in this document are projections based on available data and economic models. Actual results will vary. Regular monitoring and evaluation through the UNTP [Impact Assessment Framework (IAF)](ImpactAssessmentFramework.md) is recommended.

## Benefits — Revenue and Market Growth

### Expanded Market Reach

**Description** — As UNTP adoption grows across industries and jurisdictions, supply chains will increasingly require UNTP-conformant services as their default providers. Conformity schemes whose credentials are machine-readable and interoperable become the natural choice for regulated supply chains. CABs that issue verifiable DCCs become preferred over those issuing only paper certificates. Registers and resolver operators that conform to UNTP standards become essential infrastructure. Non-conformant services risk losing market share to competitors who have invested in UNTP conformance.

**How UNTP helps** — UNTP creates a network effect: as more industry participants adopt UNTP, the value of being a UNTP-conformant service provider increases. Schemes listed in the UNTP [Conformity Vocabulary Catalog (CVC)](../specification/ConformityCredential) registry, CABs that issue DCCs, and registers that issue DIAs are discoverable and usable by any UNTP participant — expanding addressable market without bilateral integration.

**Quantification** — Primarily a market positioning benefit. Early-mover conformity schemes and CABs are likely to capture disproportionate market share as UNTP adoption accelerates, particularly in sectors subject to EU and US sustainability regulations.

**Key variables**
- Current market share and competitive positioning
- Pace of UNTP adoption in served industry sectors
- Competitor investment in UNTP conformance
- Geographic exposure to regulated markets (EU, US, Japan, Australia)

### Multi-Scheme Recognition

**Description** — Conformity schemes that publish their criteria as digital vocabularies enable mutual recognition across supply chains. When scheme criteria are expressed as standardised conformity topics with measurable performance metrics, it becomes possible to map overlapping requirements across schemes — allowing a single assessment to satisfy multiple scheme requirements. This makes the scheme usable across more supply chain contexts without requiring duplicative assessments.

**How UNTP helps** — The UNTP [Conformity Vocabulary Catalog](../specification/ConformityCredential) provides a structured format for schemes to publish their criteria as machine-readable conformity topics and performance metrics. When multiple schemes publish in this format, automated comparison and mapping of requirements becomes possible. This enables multi-scheme mutual recognition — where a CAB assessment against one scheme can demonstrably satisfy overlapping requirements of other schemes.

**Quantification** — Schemes with digital vocabularies can serve 2–5x more supply chain contexts than those with paper-only criteria. Mutual recognition reduces total assessment volume while maintaining scheme revenue through broader applicability.

**Key variables**
- Degree of overlap with other major schemes in the same sector
- Number of supply chain contexts where the scheme is currently applicable
- Willingness of peer schemes to participate in mutual recognition
- Complexity and specificity of scheme criteria

### New Revenue Streams

**Description** — UNTP conformance opens new fee-based service opportunities for each service type. CABs can offer digital credential issuance as a value-added service alongside traditional assessment. Identity registers can offer DIA issuance and resolver hosting as subscription services. Conformity schemes can offer vocabulary licensing or registry listing fees. These represent incremental revenue from existing relationships rather than entirely new customer acquisition.

**How UNTP helps** — UNTP defines the credential formats (DCCs, DIAs) and infrastructure standards (identity resolvers) that create these service opportunities. The standardised approach means that service providers can build capabilities once and serve all UNTP-participating supply chains, rather than implementing bespoke solutions for each buyer or jurisdiction.

**Quantification** — $5–$20 per credential issued (volume-dependent) for CABs. Resolver hosting and DIA issuance as subscription services for registers. Revenue scales with UNTP adoption volume in served sectors.

**Key variables**
- Volume of assessments, registrations, or resolutions per year
- Pricing model (per-credential, subscription, bundled with existing services)
- Competitive landscape for digital credential services
- Client willingness to pay for digital value-added services

## Benefits — Operational Efficiency

### Assessment Efficiency

**Description** — When conformity schemes publish their criteria as structured digital vocabularies with defined conformity topics and measurable performance metrics, CABs benefit from reduced ambiguity in interpreting requirements. Assessment checklists can be generated programmatically from scheme vocabularies, evidence requirements become explicit, and semi-automated assessment workflows become possible.

**How UNTP helps** — UNTP's [Conformity Vocabulary Catalog](../specification/ConformityCredential) format structures scheme criteria into conformity topics and performance metrics with defined measurement methods, units, and thresholds. CABs can consume these vocabularies to auto-generate assessment templates, validate evidence against explicit criteria, and reduce the manual interpretation that currently adds time and cost to every assessment.

**Quantification** — 20–30% reduction in per-assessment effort when scheme criteria are machine-readable. The benefit is greatest for schemes with large numbers of criteria and for CABs assessing against multiple schemes.

**Key variables**
- Number of schemes the CAB assesses against
- Complexity and volume of criteria per scheme
- Current level of assessment automation
- Availability of structured evidence from assessed entities

### Reduced Duplication

**Description** — Many supply chains require conformity with multiple schemes that have substantially overlapping requirements. Without mutual recognition, each scheme requires a separate assessment — even where the same evidence satisfies multiple requirements. This duplication increases costs for assessed entities and reduces CAB throughput.

**How UNTP helps** — When schemes publish digital vocabularies, overlapping requirements become identifiable through automated comparison of conformity topics and metrics. Multi-scheme mutual recognition allows a single CAB assessment to satisfy requirements from multiple schemes, increasing CAB throughput without reducing assessment rigour.

**Quantification** — Overlapping requirements across common schemes in sectors such as mining, agriculture, and textiles can reduce total audit effort by 15–25% when mutual recognition is in place.

**Key variables**
- Degree of criteria overlap across schemes served
- Number of multi-scheme clients
- Current proportion of duplicative assessment effort
- Mutual recognition agreements in place or under negotiation

### Automated Credential Lifecycle

**Description** — Traditional certificate management — issuance, distribution, renewal, revocation, and status checking — is largely manual. Paper or PDF certificates must be emailed, tracked, renewed before expiry, and manually revoked if an entity loses conformity. This administrative burden scales linearly with the number of active certificates.

**How UNTP helps** — Digital Conformity Credentials and Digital Identity Anchors support automated lifecycle management. Issuance can be triggered by assessment completion, distribution is instant via identity resolvers, renewal can be automated based on surveillance schedules, and revocation is immediate and verifiable. Status checking by relying parties is automated through standard credential verification.

**Quantification** — 50–70% reduction in administrative overhead for credential management. The benefit is most significant for CABs and registers with large active credential portfolios (thousands of active certificates).

**Key variables**
- Number of active credentials under management
- Current administrative cost per credential lifecycle
- Renewal and revocation frequency
- Integration capability with existing management systems

## Benefits — Trust and Credibility

### Verifiable Authority

**Description** — Identity registers that issue Digital Identity Anchors provide cryptographically verifiable proof that a DID is controlled by a verified legal entity with specific attributes (legal name, jurisdiction, registration number). This is fundamentally stronger than paper-based registration certificates, which can be forged, and database lookups, which can be spoofed. Verifiable authority strengthens the entire trust chain that UNTP depends on.

**How UNTP helps** — UNTP's [Digital Identity Anchor](../specification/DigitalIdentityAnchor) specification defines how registers issue verifiable credentials that bind a DID to a verified identity. These credentials are cryptographically signed by the register, timestamped, and verifiable by any relying party without contacting the register. This creates a scalable trust anchor that works across jurisdictions.

**Quantification** — Primarily a qualitative trust benefit. Registers that issue DIAs become authoritative trust anchors in the UNTP ecosystem, strengthening their institutional role and relevance in digital trade.

**Key variables**
- Current authority and recognition of the register
- Volume of registrations and identity verifications
- Demand for verifiable identity in served jurisdictions
- Existing digital identity infrastructure

### Transparency of Scheme Governance

**Description** — Conformity schemes that publish their criteria digitally demonstrate governance transparency. When criteria, assessment methodologies, and performance thresholds are publicly available in machine-readable form, stakeholders can evaluate scheme rigour, compare schemes, and make informed decisions about which schemes to rely on. This transparency attracts more CABs willing to assess against the scheme and more industry participants willing to adopt it.

**How UNTP helps** — Publishing scheme criteria as a UNTP Conformity Vocabulary Catalog makes governance visible and auditable. Criteria changes are versioned and trackable. Industry participants, regulators, and peer schemes can independently evaluate the rigour and relevance of the scheme's requirements.

**Quantification** — Primarily a qualitative governance benefit. Schemes with transparent, machine-readable criteria are more likely to be referenced in regulatory frameworks and adopted by industry, increasing scheme relevance and sustainability.

**Key variables**
- Current transparency of scheme criteria and governance
- Stakeholder demand for governance visibility
- Regulatory interest in referencing scheme criteria
- Competitive positioning relative to peer schemes

## Costs — Implementation

### Vocabulary Publication (Conformity Schemes)

**Description** — Digitising scheme criteria into UNTP Conformity Vocabulary Catalog format requires mapping existing criteria to conformity topics and, optionally, defining performance metrics with measurement methods, units, and thresholds. The effort depends on scheme complexity and the desired level of digital maturity.

**How UNTP helps** — UNTP defines three maturity levels for vocabulary publication: (1) scheme-level registration only, (2) criteria expressed as conformity topics, and (3) full vocabulary with performance metrics. Schemes can start at level 1 and progressively deepen their digital vocabulary, spreading costs over time.

**Quantification** — $20K–$100K depending on scheme complexity and target maturity level. Level 1 (registration) is near-zero cost. Level 2 (topics) typically $20K–$50K. Level 3 (full vocabulary with metrics) $50K–$100K for complex schemes.

**Key variables**
- Number and complexity of scheme criteria
- Target maturity level (registration, topics, or full vocabulary)
- Existing digital representation of criteria (if any)
- Availability of technical expertise for vocabulary modelling

### Credential Issuance Capability (CABs)

**Description** — Implementing DCC issuance requires cryptographic key management, credential signing infrastructure, integration with assessment workflows, and staff training. The integration complexity depends on the CAB's existing IT landscape and the assessment management software in use.

**How UNTP helps** — UNTP specifies standard credential formats and issuance protocols that are increasingly supported by commercial assessment management platforms. CABs that use such platforms may find that UNTP credential issuance is available as a configuration option rather than a custom development project.

**Quantification** — $30K–$150K integration cost depending on existing IT maturity and whether issuance is delivered through existing software vendors or custom development. Cost is at the lower end when existing assessment management software supports UNTP credential issuance.

**Key variables**
- Existing assessment management software and its UNTP readiness
- IT team capability and capacity
- Volume and diversity of schemes assessed against
- Number of assessment offices and assessors

### Digital Identity Anchor Issuance (Registers)

**Description** — Implementing DIA issuance requires DID authentication capabilities, credential signing infrastructure, integration with registration workflows, and governance processes for credential lifecycle management (issuance, renewal, revocation).

**How UNTP helps** — UNTP provides a standard [DIA specification](../specification/DigitalIdentityAnchor) that defines the credential structure, issuance process, and lifecycle management requirements. This reduces design effort and ensures interoperability with other UNTP infrastructure.

**Quantification** — $50K–$200K depending on register scope, existing IT maturity, and governance complexity. Business registers with modern IT infrastructure will be at the lower end; registers with legacy systems will require more investment.

**Key variables**
- Existing IT infrastructure and modernisation plans
- Scale of the register (number of registered entities)
- Governance requirements for credential issuance
- Integration complexity with existing registration workflows

### Identity Resolver Deployment (Resolver Operators)

**Description** — Deploying ISO/IEC 18975 conformant resolver infrastructure requires implementing the link resolution protocol, hosting linkset responses, and ensuring high availability. Resolvers are the discovery mechanism that connects product identifiers to their associated credentials (DPPs, DCCs, DTEs).

**How UNTP helps** — UNTP specifies resolver requirements based on the [ISO/IEC 18975](../specification/IdentityResolver) standard, with reference implementations and conformity test suites available. Resolver infrastructure can be shared at community or national level, reducing per-operator costs.

**Quantification** — $30K–$100K initial deployment. Significantly lower when using existing resolver platforms or shared infrastructure at community or national level.

**Key variables**
- Whether deploying standalone or leveraging shared infrastructure
- Expected resolution volume (queries per day)
- Availability requirements (uptime SLA)
- Existing hosting and DevOps capabilities

## Costs — Ongoing Operations

### Vocabulary Maintenance (Conformity Schemes)

**Description** — Scheme criteria evolve as regulations change, scientific understanding advances, and stakeholder expectations shift. Digital vocabularies must be updated to reflect these changes, with version management to ensure backward compatibility.

**How UNTP helps** — UNTP vocabulary formats support versioning, allowing schemes to publish updates while maintaining references to previous versions. This enables smooth transitions for CABs and industry participants using the vocabulary.

**Quantification** — $10K–$30K/year depending on frequency of criteria changes and vocabulary complexity.

**Key variables**
- Frequency of scheme criteria updates
- Complexity of vocabulary (number of topics and metrics)
- Stakeholder consultation requirements for changes
- Technical capacity for vocabulary management

### Credential Operations (CABs and Registers)

**Description** — Ongoing costs include cryptographic key management, credential issuance processing, revocation management, system maintenance, and security operations. Scale depends on the volume of active credentials and the frequency of issuance and revocation events.

**How UNTP helps** — Standardised credential formats and protocols mean that operational processes are consistent and can be automated. Key management follows established best practices for verifiable credentials. Operational tooling is increasingly available from commercial vendors.

**Quantification** — $20K–$100K/year depending on credential volume, key management requirements, and whether operations are managed in-house or through a managed service.

**Key variables**
- Number of credentials issued per year
- Active credential portfolio size
- Key management and security requirements
- In-house vs managed service delivery model

### Resolver Hosting (Resolver Operators)

**Description** — Ongoing costs include infrastructure hosting, uptime monitoring, standards compliance maintenance, and capacity management. Resolvers must maintain high availability as they are a critical component of the UNTP discovery mechanism.

**How UNTP helps** — UNTP resolver specifications are based on widely implemented web standards, allowing operators to use standard cloud hosting and monitoring tools. Shared infrastructure models at community or national level distribute costs across multiple participants.

**Quantification** — $10K–$50K/year depending on resolution volume and availability requirements. Lower when infrastructure is shared across multiple organisations or operated at community/national level.

**Key variables**
- Resolution volume (queries per day/month)
- Availability and performance requirements
- Whether infrastructure is dedicated or shared
- Hosting model (cloud, on-premises, managed service)

## Business Case Templates

Downloadable business case templates are available for each service type:

- [Business Case Template — Conformity Schemes](../assets/files/UNTP-Business-Case-Template-Schemes.docx) — for scheme owners considering publishing digital vocabularies
- [Business Case Template — Identity Registers](../assets/files/UNTP-Business-Case-Template-Registers.docx) — for register operators considering DIA issuance and resolver services

The templates are designed to be populated using the benchmark ranges above combined with organisation-specific operational and financial data — including with the assistance of AI tools as described below.

## Generate Your Own Business Case

You can use a frontier AI model (such as ChatGPT, Claude, or Gemini) to generate a first-draft business case for your scheme or register. Upload your organisation's annual report, strategic plan, or published scheme documentation (PDF) alongside the appropriate prompt below. The AI will extract relevant operational data, apply the UNTP benchmark ranges, and produce a complete draft business case.

**Prerequisites:** This prompt requires a frontier AI model with a large context window (100K+ tokens) and the ability to process PDF attachments and fetch web content. You will likely need a professional-tier subscription (e.g. ChatGPT Plus/Pro, Claude Pro, Gemini Advanced) to handle the combined size of your documentation, the UNTP cost/benefit framework, and the business case template in a single session.

**Important disclaimer:** The generated business case is only an initial draft. AI models may misinterpret operational data, misjudge your scheme's or register's competitive position, or make unfounded assumptions about ecosystem readiness and adoption timelines. The output should be thoroughly reviewed and adjusted by your organisation's leadership and technical experts before being used for any decision-making purpose.

### For Conformity Schemes

**How to use:** Copy the prompt below, open your preferred AI assistant, attach your scheme documentation or annual report PDF, paste the prompt, and submit.

:::info[Business Case Generation AI Prompt]

You are preparing a first-draft UNTP business case for a conformity scheme (a standards body, certification programme, or industry scheme that defines criteria against which conformity is assessed). The attached document describes the scheme.

**Input documents**

1. **Scheme documentation** — attached PDF (annual report, scheme rules, criteria documentation, or strategic plan). Extract: scheme name, scope (sectors, geographies, product types), number of certified entities, number of CABs operating under the scheme, criteria structure (number and complexity of requirements), current digital maturity, and any mentions of mutual recognition with other schemes.

2. **UNTP cost/benefit framework** — fetch from https://untp.unece.org/business-case/BusinessCaseDependentServices and use the benchmark ranges for conformity scheme benefits and costs.

3. **Business case template** — fetch from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Schemes.docx and use this as the output structure. Fill in every section and every bracketed placeholder.

**How to weight each benefit category**

IMPORTANT: Always err on the side of conservatism. Use the lower end of each benchmark range unless there is strong, specific evidence to justify a higher figure. A credible business case with conservative estimates is far more useful than an optimistic one that loses credibility under scrutiny. When in doubt, round down. If evidence for a benefit category is weak or absent, use the minimum of the range or exclude it entirely.

Weight each benefit based on the scheme's specific context:

- **Expanded market reach** — weight HIGH if the scheme operates in sectors heavily affected by EUDR, CBAM, ESPR, or CSDDD, and if UNTP adoption is accelerating among the scheme's user base. Weight LOW if the scheme serves primarily domestic or unregulated sectors.
- **Multi-scheme recognition** — weight HIGH if the scheme's criteria overlap significantly with peer schemes (e.g. multiple sustainability standards in the same sector) and mutual recognition would expand the scheme's applicability. Weight LOW if the scheme is unique in its domain with little overlap.
- **New revenue streams** — weight HIGH if the scheme has a large certified base and can add digital vocabulary licensing or registry listing fees. Weight LOW if the scheme is small or revenue is primarily membership-based.
- **Assessment efficiency (for CABs)** — weight HIGH if the scheme has many complex criteria that would benefit from machine-readable expression. Weight LOW if criteria are simple and few.
- **Reduced duplication** — weight HIGH if certified entities frequently hold multiple overlapping certifications. Weight LOW if the scheme is standalone.
- **Governance transparency** — weight HIGH if the scheme faces scrutiny about the rigour of its criteria or if regulators are considering referencing the scheme. Weight LOW if governance credibility is already well established.

For costs, adjust based on:

- **Criteria complexity** — schemes with hundreds of criteria and detailed performance metrics will face higher vocabulary publication costs than simple registration schemes.
- **Existing digital maturity** — reduce costs if the scheme already has criteria in a structured digital format (database, API) rather than only in PDF documents.
- **CAB ecosystem** — the value of vocabulary publication depends on CABs being ready to consume it. Assess the digital maturity of the scheme's CAB network.

**Output requirements**

1. Populate the full template — every section, every table, every placeholder.
2. Assess the three CVC maturity levels (registration only, criteria with topics, full vocabulary with metrics) and recommend a target level with phasing.
3. Identify the specific peer schemes with overlapping criteria and the mutual recognition potential.
4. Assess CAB readiness to consume digital vocabularies and issue DCCs.
5. In the financial model, note that scheme business cases are typically smaller in absolute terms than industry cases — focus on benefit-cost ratio rather than absolute values.
6. Throughout, show your working — explain why you chose a particular point in a benchmark range.

**Output format**

Download the business case template from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Schemes.docx and produce the output as a completed version of that Word document. Fill in every bracketed placeholder, populate every table, and replace all instructional text with scheme-specific content. The output should be a ready-to-review Word document that can be presented to the scheme's board or governance body without further formatting.

:::

### For Identity Registers

**How to use:** Copy the prompt below, open your preferred AI assistant, attach your register documentation or annual report PDF, paste the prompt, and submit.

:::info[Business Case Generation AI Prompt]

You are preparing a first-draft UNTP business case for an identity register (a business register, product identifier register, facility register, trademark register, or industry association membership register). The attached document describes the register.

**Input documents**

1. **Register documentation** — attached PDF (annual report, strategic plan, or governance documentation). Extract: register name, type (business, product, facility, trademark, association), jurisdiction, number of registered entities, registration volume (new registrations per year), current digital services offered, existing identifier schemes used (e.g. GS1 GTIN, GLN, LEI), and any existing resolver or API services.

2. **UNTP cost/benefit framework** — fetch from https://untp.unece.org/business-case/BusinessCaseDependentServices and use the benchmark ranges for identity register benefits and costs.

3. **Business case template** — fetch from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Registers.docx and use this as the output structure. Fill in every section and every bracketed placeholder.

**How to weight each benefit category**

IMPORTANT: Always err on the side of conservatism. Use the lower end of each benchmark range unless there is strong, specific evidence to justify a higher figure. A credible business case with conservative estimates is far more useful than an optimistic one that loses credibility under scrutiny. When in doubt, round down. If evidence for a benefit category is weak or absent, use the minimum of the range or exclude it entirely.

Weight each benefit based on the register's specific context:

- **Expanded market reach** — weight HIGH if registered entities operate in sectors with growing UNTP adoption and need verifiable identity for issuing or receiving credentials. Weight LOW if registered entities are primarily in domestic, non-exporting sectors.
- **New revenue streams (resolver services)** — weight HIGH if the register manages product or facility identifiers that would benefit from resolution to DPPs or DFRs, and if the register can offer resolver hosting as a fee-based service. Weight LOW if the register manages only legal entity identifiers with limited resolution demand.
- **New revenue streams (DIA issuance)** — weight HIGH if the register has well-governed membership or registration processes that make its attestation valuable as a trust anchor. Weight LOW if the register's verification processes are minimal (e.g. self-registration with no vetting).
- **Automated credential lifecycle** — weight HIGH if the register manages a large portfolio of registrations with frequent changes (new registrations, updates, deregistrations). Weight LOW if the portfolio is small and stable.
- **Verifiable authority** — weight HIGH if the register is an authoritative source for its jurisdiction (e.g. national business register, national IP office). Weight LOW if the register is a voluntary or non-authoritative listing.

For costs, adjust based on:

- **Existing IT infrastructure** — reduce costs significantly if the register already has modern APIs, digital identity capabilities, or an existing resolver service.
- **Register scale** — larger registers (millions of entities) face higher initial investment but lower per-entity costs and stronger revenue potential.
- **Governance requirements** — registers with strict governance needs (e.g. government business registers) will face higher costs for DIA issuance policy development, key management, and liability frameworks.
- **Shared infrastructure** — reduce resolver hosting costs if the register can participate in shared national or regional resolver infrastructure.

**Output requirements**

1. Populate the full template — every section, every table, every placeholder.
2. Assess both the resolver service (IDR) and trust anchor (DIA) value propositions separately — not all registers will pursue both.
3. Map the register type to the DIA Application matrix in the template appendix (register type, DIA assertions, IDR resolution targets).
4. Assess governance requirements for DIA issuance — issuance policy, revocation procedures, scope definitions, liability, and key management.
5. Identify specific UNTP-adopting industries that would benefit from this register's services.
6. Throughout, show your working — explain why you chose a particular point in a benchmark range.

**Output format**

Download the business case template from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Registers.docx and produce the output as a completed version of that Word document. Fill in every bracketed placeholder, populate every table, and replace all instructional text with register-specific content. The output should be a ready-to-review Word document that can be presented to the register's board or governing authority without further formatting.

:::

---

## Business Case for Government

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Purpose

The purpose of this page is to provide a structured framework for building a quantified business case for UNTP implementation at the national or agency level. The cost/benefit model, benchmark data, and template below are designed so that any government agency or national trade body can combine them with their own trade and economic data to produce a customised business case — including with the assistance of AI tools.

The UNTP is supported by UNECE policy [Recommendation 49 — Transparency at Scale](https://unece.org/trade/documents/2024/07/session-documents/draft-recommendation-no-49-transparency-scale) that defines specific recommendations for member states that wish to reap the economic benefits of increased supply chain traceability, transparency, and trust.

We also provide a separate [cost/benefit model and business case template for industry](BusinessCaseIndustry.md).

Note: The economic impacts described in this document are projections based on available data and economic models. Actual results will vary depending on existing trade infrastructure, regulatory environment, and level of digitalisation. Regular monitoring through the UNTP [Impact Assessment Framework (IAF)](ImpactAssessmentFramework.md) is recommended.

## Government Cost Benefit Model

The high level model shown below breaks benefits into two categories (economic impact and national impact) and costs into two categories (implementation and ongoing operations).

* Benefits accrue through direct economic gains (trade cost reduction, improved revenue collection, increased investment) and broader national impacts (trade facilitation, compliance outcomes, fraud prevention, international cooperation, and SDG advancement).
* Costs are incurred through one-off implementation activities (change management, legislative reform, transition period) and ongoing operational expenditure (IT infrastructure, capacity building, communications).

![Cost benefit model](GovCostBenefitModel.jpg)

## Benefits — Economic Impact

### Trade Cost Reduction

**Description** — Trade transaction costs — including documentation, border procedures, inspections, and administrative compliance — represent a significant drag on trade, particularly for developing countries where they can reach 10–15% of trade value. Digitalisation and standardisation of trade data can substantially reduce these costs, making domestic producers more competitive in international markets.

**How UNTP helps** — UNTP standardises the digital credentials (DPPs, DCCs, DTEs) that accompany goods across borders. Machine-readable, verifiable data replaces paper documentation and manual verification. This enables automated risk assessment, faster clearance, and reduced administrative overhead for both traders and customs authorities.

**Quantification** — Trade costs in developing countries average 10–15% of trade value; digitalisation through UNTP can reduce this by 2–5 percentage points. For a country with $10B in trade, this represents $200M–$500M in annual savings distributed across all trading entities. References: [WTO Trade Facilitation Agreement](https://www.wto.org/english/tratop_e/tradfa_e/tradfa_e.htm), [OECD trade cost estimates](https://www.oecd.org/trade/topics/trade-costs-and-trade-facilitation/).

**Key variables**
- Current trade costs as percentage of trade value
- Volume of international trade (imports + exports)
- Existing level of trade digitalisation
- Number and complexity of border agencies involved in clearance

### Enhanced Revenue Collection

**Description** — Customs revenue leakage through fraud, misclassification, and undervaluation is a significant fiscal challenge, particularly in developing countries where customs duties represent a major share of government revenue. Estimates suggest 5–10% of customs revenue is lost to various forms of non-compliance.

**How UNTP helps** — Verifiable Digital Product Passports provide customs authorities with trusted product data (origin, composition, value, classification) that can be cross-referenced against declarations. Digital Conformity Credentials from accredited bodies provide independent verification of claimed product attributes. This makes fraud detection more systematic and less reliant on physical inspection.

**Quantification** — 5–10% customs revenue leakage in developing countries; verifiable credentials can reduce leakage by 20–40%. Net improvement: 1–3% of total customs revenue. References: [WCO Revenue Package](https://www.wcoomd.org/), [IMF revenue mobilisation studies](https://www.imf.org/en/Topics/fiscal-policies/revenue-mobilization).

**Key variables**
- Total customs revenue (duties, taxes, fees)
- Estimated leakage rate (fraud, misclassification, undervaluation)
- Current inspection and verification capabilities
- Proportion of trade subject to preferential tariff arrangements

### Foreign Direct Investment

**Description** — Countries with transparent, predictable, and digitally enabled trade environments are more attractive to foreign investors. A well-functioning digital trade infrastructure signals regulatory maturity, reduced corruption risk, and lower cost of doing business — all factors that influence FDI decisions.

**How UNTP helps** — National UNTP implementation demonstrates commitment to international standards, transparent governance, and digital trade facilitation. This positions the country favourably in investment climate assessments such as the World Bank B-READY rankings. The verifiable nature of UNTP credentials also reduces due diligence costs for foreign investors evaluating local supply chains.

**Quantification** — Countries with advanced digital trade infrastructure attract 10–20% more FDI than comparable peers. The effect is strongest for manufacturing and agricultural FDI where supply chain transparency directly affects investment decisions. References: [World Bank B-READY](https://www.worldbank.org/en/programs/business-enabling-environment/b-ready), [UNCTAD World Investment Report](https://unctad.org/topic/investment/world-investment-report).

**Key variables**
- Current FDI inflows and trends
- Target sectors for FDI attraction
- Existing digital trade infrastructure maturity
- Regional competitive positioning

## Benefits — National Impact

### Trade Facilitation and Efficiency

**Description** — Border clearance times and inspection rates directly affect trade competitiveness and cost. Lengthy clearance procedures create delays, increase storage costs, damage perishable goods, and reduce the predictability that modern supply chains require. Risk-based targeting — focusing inspections on high-risk consignments — is more effective and less disruptive than blanket physical inspection.

**How UNTP helps** — UNTP credentials enable customs authorities to implement more effective risk-based targeting. Consignments accompanied by verifiable DPPs and DCCs can be assessed automatically, allowing pre-clearance for low-risk shipments and focusing inspection resources on genuinely high-risk consignments. Digital Traceability Events provide chain of custody evidence that supports origin verification.

**Quantification** — 10–15% reduction in average clearance times. 20–30% reduction in physical inspection rates through improved risk-based targeting — without reducing compliance effectiveness. References: [WTO TFA implementation studies](https://www.wto.org/english/tratop_e/tradfa_e/tradfa_e.htm), [WCO time release studies](https://www.wcoomd.org/).

**Key variables**
- Current average clearance times (hours/days)
- Current physical inspection rate
- Volume of border transactions per year
- Existing IT infrastructure at border posts

### Compliance and Regulatory Oversight

**Description** — Governments face an increasing burden of verifying that imported goods comply with sustainability regulations, product safety standards, and trade rules. Paper-based verification is slow, unreliable, and difficult to scale. Detection rates for non-conforming imports remain low in most jurisdictions.

**How UNTP helps** — Digital Conformity Credentials provide machine-verifiable evidence of compliance from accredited conformity assessment bodies. This enables automated screening of consignments against regulatory requirements, flagging non-conforming goods for inspection while clearing compliant goods faster. The verifiable nature of credentials makes document fraud significantly more difficult.

**Quantification** — 20–40% improvement in detection rates for non-conforming imports when using digital verification vs paper-based processes. This translates to better protection of domestic consumers, industries, and the environment. References: [WCO compliance studies](https://www.wcoomd.org/), EU customs risk management frameworks.

**Key variables**
- Volume and diversity of imports subject to regulatory requirements
- Current detection rates for non-conforming goods
- Number of regulatory requirements that apply at the border
- Existing capability for digital verification

### Fraud and Counterfeit Prevention

**Description** — Counterfeit and illicit goods represent an estimated 2–5% of imports globally, causing economic harm through lost tax revenue, unfair competition with legitimate producers, and risks to consumer health and safety. Certain product categories (pharmaceuticals, electronics, luxury goods) are disproportionately affected.

**How UNTP helps** — UNTP's verifiable product identity, linked through identity resolvers to Digital Product Passports issued by the legitimate manufacturer, enables customs authorities to verify product authenticity at the border. Digital Traceability Events provide chain of custody evidence that is difficult to forge. This makes it significantly harder for counterfeit goods to enter through legitimate trade channels.

**Quantification** — Counterfeit imports estimated at 2–5% of import value. Digital verification can reduce counterfeit penetration by 30–50% for product categories where verification is applied. Net benefit: 0.5–2% of import value for targeted product categories. References: [OECD/EUIPO counterfeit reports](https://www.oecd.org/en/topics/sub-issues/illicit-trade-in-counterfeit-goods.html).

**Key variables**
- Import value and composition (proportion in high-counterfeit categories)
- Current counterfeit detection capabilities
- Revenue loss from counterfeit imports (duties, taxes, legitimate market displacement)
- Consumer safety risk profile

### International Cooperation and Trust

**Description** — Mutual recognition of testing, inspection, and certification results between trading partners reduces duplicative compliance costs and trade friction. However, mutual recognition requires a foundation of trust in the integrity and verifiability of partner country credentials.

**How UNTP helps** — UNTP provides a common standard for digital credentials that enables mutual recognition without requiring bilateral negotiation of every credential type. Digital Conformity Credentials from accredited bodies in one country can be automatically verified and accepted by authorities in another, provided both operate within the UNTP framework. This strengthens bilateral and multilateral trade relationships.

**Quantification** — Qualitative: reduced trade friction, strengthened bilateral and multilateral relationships, improved positioning in trade negotiations. Mutual recognition agreements typically reduce compliance costs by 10–20% for affected product categories.

**Key variables**
- Number and value of existing mutual recognition agreements
- Key trading partner relationships and negotiation priorities
- Current duplication in compliance requirements across markets
- Participation in regional trade facilitation initiatives

### SDG Advancement

**Description** — The Sustainable Development Goals (SDGs) provide a shared framework for national development priorities. Transparent, verifiable supply chain data enables governments to measure and demonstrate progress toward SDG targets — particularly those related to responsible production and consumption, climate action, and decent work.

**How UNTP helps** — UNTP metrics and credentials map directly to SDG indicators, enabling data-driven measurement of national progress. Digital Product Passports contain sustainability metrics (emissions, labour practices, environmental impacts) that can be aggregated to national level. This moves SDG reporting from estimates to evidence-based measurement.

**Quantification** — UNTP metrics map to SDG indicators across goals 8 (decent work), 9 (industry and infrastructure), 12 (responsible production and consumption), 13 (climate action), 15 (life on land), and 17 (partnerships). Verifiable data enables more credible national SDG reporting. References: [UN SDG indicator framework](https://sdgs.un.org/goals).

**Key variables**
- National SDG priorities and targets
- Current SDG reporting maturity and data availability
- Alignment between trade sectors and priority SDG indicators
- International reporting commitments

## Costs — Implementation

### Change Management

**Description** — UNTP implementation requires coordination across multiple government agencies (customs, trade, environment, health, agriculture), stakeholder engagement with industry, and training of government personnel. The complexity depends on the number of agencies involved and the existing level of inter-agency coordination.

**How UNTP helps** — UNTP's modular design allows phased implementation, starting with a single agency or product category and expanding over time. The open standards approach reduces vendor lock-in and enables incremental capability building.

**Quantification** — $500K–$2M depending on government complexity, number of agencies involved, and existing coordination mechanisms. Includes stakeholder consultation, project management, and initial training programs.

**Key variables**
- Number of government agencies involved in border management
- Existing level of inter-agency coordination and shared IT systems
- Scale and complexity of the trading environment
- Availability of technical expertise within government

### Legislative and Regulatory Change

**Description** — Recognising digital credentials as legally equivalent to paper documents may require legislative or regulatory reform. Customs procedures, product safety regulations, and trade facilitation laws may need updating to accommodate digital verification. The timeline for legislative change varies significantly by jurisdiction.

**How UNTP helps** — UNTP aligns with existing international frameworks (WTO TFA, WCO data model, UN/CEFACT standards) which many countries have already committed to implement. This provides a policy foundation that can accelerate legislative change. Model regulatory language and implementation guides from UNECE reduce the policy development burden.

**Quantification** — 12–24 months legislative timeline depending on jurisdiction. $200K–$500K in policy development, legal drafting, and consultation costs. Can be reduced where existing e-commerce or digital trade legislation provides a foundation.

**Key variables**
- Existing legal framework for digital documents and e-signatures
- Legislative process complexity and timeline
- Political will and priority for digital trade reform
- Alignment with existing international commitments

### Transition Period

**Description** — During the transition from paper-based to digital verification, parallel systems must operate to accommodate trading partners at different levels of digital maturity. This creates a temporary cost premium as both old and new systems run simultaneously.

**How UNTP helps** — UNTP's design supports graceful degradation — digital credentials can coexist with paper processes during transition. The phased implementation approach means the transition period can be managed by product category or trading partner, reducing the scope of parallel operations at any given time.

**Quantification** — 12–36 months transition period. 10–20% premium over steady-state operational costs during transition due to parallel system operation and additional support requirements.

**Key variables**
- Trading partner digital readiness
- Scope of initial implementation (all trade vs specific categories)
- Existing IT infrastructure and modernisation plans
- Available support from international development partners

## Costs — Ongoing Operations

### Operations

**Description** — Ongoing operational costs include IT infrastructure for credential verification, identity resolver hosting, system maintenance, software licensing, and technical support. Scale depends on trade volume and the number of connected systems.

**How UNTP helps** — UNTP's open standards approach avoids proprietary platform lock-in and enables competitive procurement. Shared infrastructure (e.g. regional identity resolvers) can reduce per-country costs. Cloud-based deployment options reduce the need for on-premises infrastructure.

**Quantification** — $200K–$1M/year depending on trade volume, number of connected systems, and whether infrastructure is national or shared regionally. Typically decreases as a percentage of trade value as volumes increase.

**Key variables**
- Annual trade volume and transaction count
- Number of connected government and private sector systems
- Choice of infrastructure model (national vs regional/shared)
- Existing government IT operations budget

### Capacity Building

**Description** — Customs officers, trade compliance staff, and industry partners need ongoing training to effectively use digital verification tools and interpret UNTP credentials. Capacity building is highest in the first 3 years and declines as competencies become embedded.

**How UNTP helps** — UNTP provides standardised training materials and certification programs. The consistent credential format across all product categories means that training is transferable — officers trained on one product category can apply the same verification approach to others.

**Quantification** — 15–25% of initial implementation cost annually for the first 3 years, declining to 5–10% thereafter as competencies become embedded and training becomes part of standard onboarding.

**Key variables**
- Size of the customs and trade compliance workforce
- Existing digital skills baseline
- Staff turnover rate
- Availability of train-the-trainer programs

### Communications

**Description** — Public awareness campaigns, industry guidance documents, international reporting, and ongoing stakeholder engagement are necessary to drive adoption and maintain momentum. Effective communication is particularly important during the early adoption phase to build industry confidence.

**How UNTP helps** — UNTP provides template communications materials and case studies from early adopter countries. The [Community Activation Program (CAP)](../governance/CommunityActivationProgram.md) methodology provides a structured approach to industry engagement that governments can leverage.

**Quantification** — $100K–$300K/year for communications, industry guidance, and international reporting. Higher in the first 2–3 years during active adoption promotion, declining as UNTP becomes standard practice.

**Key variables**
- Size and diversity of the trading community
- Number of languages required
- Existing government communications infrastructure
- Level of industry awareness and readiness

## Government Business Case Template

A downloadable [business case template](../assets/files/UNTP-Business-Case-Template-Government.docx) with quantification summary table and narrative structure is available as a Word document. The template is designed to be populated using the benchmark ranges above combined with national trade and economic data — including with the assistance of AI tools as described below.

## Generate Your Own Business Case

You can use a frontier AI model (such as ChatGPT, Claude, or Gemini) to generate a first-draft business case for your country or agency. Upload your agency's annual report or strategic plan (PDF) alongside the prompt below. The AI will extract relevant trade and economic data, apply the UNTP benchmark ranges weighted to your country's specific profile, and produce a complete draft business case using the template above.

**Prerequisites:** This prompt requires a frontier AI model with a large context window (100K+ tokens) and the ability to process PDF attachments and fetch web content. You will likely need a professional-tier subscription (e.g. ChatGPT Plus/Pro, Claude Pro, Gemini Advanced) to handle the combined size of the agency report, country-level data, the UNTP cost/benefit framework, and the business case template in a single session.

**Important disclaimer:** The generated business case is only an initial draft. AI models may misinterpret economic data, apply benchmark ranges inappropriately, or make unfounded assumptions about your country's regulatory environment, institutional readiness, or trading partner dynamics. Trade statistics, customs revenue figures, and FDI data should be verified against official national sources. The output should be thoroughly reviewed and adjusted by trade policy experts and relevant agency officials before being used for any decision-making purpose.

**How to use:** Copy the prompt below, open your preferred AI assistant, attach your agency report or national trade strategy PDF, paste the prompt, and submit.

:::info[Business Case Generation AI Prompt]

You are preparing a first-draft UNTP business case for a national government. The agency report or national trade strategy attached provides institutional context. You should also draw on publicly available country-level data (trade statistics, customs revenue, FDI, World Bank indicators) to populate the financial model.

**Input documents**

1. **Agency report or national trade strategy** — attached PDF. Extract: country name, institutional structure, trade volumes, customs revenue, key export/import sectors, existing trade facilitation measures, digital infrastructure maturity, international commitments, and any mentions of sustainability regulations affecting national trade.

2. **Country-level public data** — use your knowledge and, where possible, fetch current data for the country from these sources:
   - Trade statistics (imports + exports by sector) from national statistics or [UN Comtrade](https://comtradeplus.un.org/)
   - Customs revenue from national budget or IMF data
   - FDI inflows from [UNCTAD](https://unctad.org/topic/investment/world-investment-report)
   - World Bank [B-READY](https://www.worldbank.org/en/programs/business-enabling-environment/b-ready) or Doing Business ranking
   - WTO [Trade Facilitation Agreement](https://www.wto.org/english/tratop_e/tradfa_e/tradfa_e.htm) implementation status
   - [OECD trade cost](https://www.oecd.org/trade/topics/trade-costs-and-trade-facilitation/) estimates for the country or region

3. **UNTP cost/benefit framework** — fetch from https://untp.unece.org/business-case/BusinessCaseGovernment and use the benchmark ranges for each benefit and cost category.

4. **Business case template** — fetch from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Government.docx and use this as the output structure. Fill in every section and every bracketed placeholder.

**How to weight each benefit category**

IMPORTANT: Always err on the side of conservatism. Use the lower end of each benchmark range unless there is strong, country-specific evidence to justify a higher figure. A credible business case with conservative estimates is far more useful than an optimistic one that loses credibility under scrutiny. When in doubt, round down. If evidence for a benefit category is weak or absent, use the minimum of the range or exclude it entirely.

Weight each benefit category based on the country's specific economic profile, institutional maturity, and trade structure:

- **Trade cost reduction** — weight HIGH for developing countries with trade costs above 10% of trade value, paper-based border processes, and low WTO TFA implementation. Weight LOW for developed countries with mature single windows and high TFA scores.
- **Revenue collection** — weight HIGH for countries where customs duties represent a significant share of government revenue (common in developing countries), and where audit data suggests material leakage. Weight LOW for developed countries with established compliance frameworks.
- **FDI uplift** — weight HIGH for countries actively competing for manufacturing or agricultural FDI, particularly where peer countries in the region are investing in digital trade infrastructure. Weight LOW for countries where FDI decisions are driven primarily by other factors (resource endowment, market size, labour costs).
- **Border efficiency** — weight HIGH for countries with long clearance times (days rather than hours), high physical inspection rates (>20%), and multiple uncoordinated border agencies. Weight LOW for countries with efficient, digitally enabled border processes.
- **Counterfeit prevention** — weight HIGH for countries with significant pharmaceutical, electronics, or luxury goods imports and limited detection capability. Weight LOW for countries with strong existing enforcement.
- **Compliance and regulatory oversight** — weight HIGH for countries facing new sustainability verification requirements (e.g. need to verify CBAM certificates, EUDR due diligence from trading partners). Weight MEDIUM for most trading nations.
- **Mutual recognition** — weight HIGH for countries actively negotiating trade agreements or regional integration. Weight LOW for relatively isolated trading economies.
- **SDG advancement** — weight HIGH for countries with strong SDG commitments and current data gaps. Weight LOW if SDG reporting is already mature.

For costs, adjust based on:

- **Country income level** — LDCs and developing countries typically face lower absolute costs (smaller workforce, fewer border posts) but may have less existing infrastructure to build on.
- **Existing digital infrastructure** — reduce costs significantly if the country already has a functioning single window, modern customs IT system (e.g. ASYCUDA World), or national identity infrastructure.
- **Development partner support** — reduce net costs if international development partners (World Bank, regional development banks, bilateral donors) are likely to provide technical and financial support.
- **Regional approach** — reduce costs if shared infrastructure (e.g. regional identity resolvers, shared verification platforms) is available or planned through regional integration bodies.

**Output requirements**

1. Populate the full template — every section, every table, every placeholder. Use actual data from the agency report and public sources where available; use informed estimates (with reasoning) where not.
2. In section 2.2 (Regulatory and Policy Context), map specific international regulations affecting the country's trade, with estimated trade values at risk. Also identify domestic policy alignment (WTO TFA status, UNECE Rec 49, regional agreements, national strategies).
3. In section 4.4 (Estimation Assumptions), assign a confidence level (H/M/L) to each benefit and explain your reasoning based on the country's specific data availability and institutional context.
4. In section 4.3 (Net Value and Payback), provide conservative, base case, and optimistic scenarios. Use benefit-cost ratio (not ROI) as the primary metric — this is standard for public sector investment appraisal.
5. In section 6 (Dependencies), assess the actual readiness of the country's institutions, trading partners, and domestic industry. Name specific agencies, systems, and international development partners.
6. In section 7 (Risk Analysis), pay particular attention to institutional and political risks (legislative reform delays, inter-agency coordination, political continuity, funding) — these typically outweigh technical risks in government implementations.
7. In Appendix A (Regulatory Alignment Matrix), map UNTP capabilities to the specific international agreements and frameworks the country is party to.
8. Throughout, show your working — explain why you chose a particular point in a benchmark range, citing specific evidence from the agency report, public data, or your knowledge of the country's economic context.

**Output format**

Download the business case template from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Government.docx and produce the output as a completed version of that Word document. Fill in every bracketed placeholder, populate every table, and replace all instructional text with country-specific content. The output should be a ready-to-review Word document that can be presented to a minister or budget authority without further formatting.

:::

---

## Business Case for Industry

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Purpose

The purpose of this page is to provide a structured framework for building a quantified business case for UNTP implementation at the individual company level. The cost/benefit model, benchmark data, and template below are designed so that any organisation can combine them with their own financial data (e.g. annual report, management accounts) to produce a customised business case. The quantification benchmarks and template below are designed so that any organisation can combine them with their own financial data to produce a customised business case — including with the assistance of AI tools.

We also provide a separate [cost/benefit model and business case template for government](BusinessCaseGovernment.md).

Note: The economic impacts described in this document are projections based on available data and economic models. Actual results will vary. Regular monitoring and evaluation through the UNTP [Impact Assessment Framework (IAF)](ImpactAssessmentFramework.md) is recommended.

## Industry Cost Benefit Model

The high level model shown below breaks benefits into three categories and costs into two categories.

* Benefits accrue through increasing revenue and/or decreasing cost. Improved margins contribute to corporate value, alongside less tangible benefits such as brand reputation and improved regulatory standing.
* Costs are incurred through changes to production processes to achieve greater sustainability and the implementation of traceability and transparency systems to communicate that verifiable sustainability.

![Cost benefit model](CostBenefitModel.png)

## Benefits — Revenue Uplift

### Market Access

**Description** — A growing wave of sustainability regulations (EUDR, CBAM, UFLPA, ESPR, CSDDD) is creating mandatory compliance requirements for market access. In many cases these regulations reverse the burden of proof: companies must demonstrate compliance to continue trading in regulated markets. Non-compliant suppliers risk exclusion from high-value export markets entirely.

**How UNTP helps** — UNTP Digital Product Passports (DPPs) and Digital Conformity Credentials (DCCs) provide the verifiable, machine-readable evidence that importers and regulators require. By presenting credentials that directly address regulatory requirements, suppliers can maintain and expand market access rather than being forced into lower-value commodity channels.

**Quantification** — Depending on sector and geography, 10–40% of export revenue may be exposed to sustainability regulations. The benefit is measured as market access retained (i.e. revenue that would otherwise be lost due to non-compliance). References: [WTO Trade Facilitation Agreement](https://www.wto.org/english/tratop_e/tradfa_e/tradfa_e.htm), [UNCTAD trade data](https://unctad.org/statistics).

**Key variables**
- Proportion of revenue from regulated markets (EU, US, Japan, Australia)
- Number and severity of applicable regulations
- Current ability to demonstrate compliance without UNTP
- Competitor readiness — early movers capture displaced market share

### Unit Price Uplift

**Description** — Consumers and business buyers are increasingly willing to pay a premium for products with verified sustainability credentials. Conversely, products that cannot demonstrate sustainability are likely to be pushed into lower-priced commodity markets, creating a widening price gap between verified and unverified goods.

**How UNTP helps** — UNTP provides rich, verifiable product-level data through DPPs and DCCs that can be presented at point of sale (B2C) or during procurement (B2B). This transforms sustainability from a marketing claim into a verifiable attribute that justifies premium pricing.

**Quantification** — Consumer goods: 2–8% price premium for verified sustainable products. B2B/industrial: 1–3% price premium. Note: willingness-to-pay surveys report higher figures (10–15%), but actual captured premiums are consistently lower due to the gap between stated preference and purchase behaviour. References: [PwC 2024 Voice of the Consumer](https://www.pwc.com/gx/en/news-room/press-releases/2024/pwc-2024-voice-of-consumer-survey.html), [Simon-Kucher 2024 Global Sustainability Study](https://www.simon-kucher.com/en/who-we-are/newsroom/simon-kucher-unveils-2024-global-sustainability-study-majority-willing-pay-more).

**Key variables**
- Sector (consumer goods vs industrial commodities)
- Strength of sustainability differentiation relative to competitors
- Consumer/buyer willingness to pay in target markets
- Existing brand positioning and credibility

### Anti-Counterfeiting

**Description** — Global trade in counterfeit goods is estimated at 2–5% of total trade value. The most impacted sectors are pharmaceuticals and luxury goods, including quality wines and spirits. The proportion that matters commercially is counterfeits unknowingly purchased as genuine, since in many cases buyers of fake luxury goods know the goods are counterfeit.

**How UNTP helps** — UNTP provides a simple but effective anti-counterfeit mechanism through verifiable product identity linked to Digital Product Passports. When buyers scan a product identifier, they can verify authenticity against the manufacturer's identity resolver. This works particularly well when buyers are motivated to confirm that goods are genuine.

**Quantification** — Revenue recovery ranges from negligible for commodity goods to material for pharmaceuticals and luxury goods. A benchmark of 0.1–2% of revenue is reasonable depending on sector. Note: OECD estimates of 2–5% refer to total counterfeit trade as a share of global trade, not per-company revenue recovery through anti-counterfeiting measures. References: [OECD trends in counterfeit goods](https://www.oecd.org/en/publications/2019/03/trends-in-trade-in-counterfeit-and-pirated-goods_g1g9f533.html), [USPTO counterfeit estimates](https://www.uspto.gov/sites/default/files/documents/USPTO-Counterfeit.pdf).

**Key variables**
- Sector (pharma and luxury highest; commodities lowest)
- Brand recognition and attractiveness to counterfeiters
- Geographic markets (counterfeiting more prevalent in some regions)
- Buyer motivation to verify authenticity

## Benefits — Cost Reduction

### Compliance Costs

**Description** — Regulatory compliance costs encompass administrative burden of reporting, processing fees, tariffs, border clearance delays, and penalties for non-compliance. As sustainability regulations proliferate, these costs will grow — especially at borders where goods face increasing scrutiny.

**How UNTP helps** — UNTP Digital Product Passports provide customs authorities and corporate regulators with high-confidence, machine-readable data that can streamline border processing, reduce administrative costs, and minimise delays. For carbon border tariffs such as the [EU CBAM](https://taxation-customs.ec.europa.eu/carbon-border-adjustment-mechanism_en), DPPs with actual emissions data enable importers to pay charges on actual rather than default (higher) emissions values, and Digital Traceability Events (DTEs) provide the chain of custody evidence required.

**Quantification** — 10–20% reduction in compliance administration costs through automated data exchange. Note: this applies to the documentation and reporting component of compliance spend, not to audit fees, tariffs, or testing costs which are not directly reduced by digital credentials. Additional savings from CBAM certificate costs when using actual vs default emissions data. References: [EU CBAM](https://taxation-customs.ec.europa.eu/carbon-border-adjustment-mechanism_en), [WTO Trade Facilitation Agreement studies](https://www.wto.org/english/tratop_e/tradfa_e/tradfa_e.htm).

**Key variables**
- Current compliance spend (reporting, audits, border costs)
- Exposure to carbon border tariffs (CBAM and similar)
- Volume and frequency of border crossings
- Current level of manual vs automated compliance processes

### Finance Costs

**Description** — Sustainable supply chain finance (SCF) is growing rapidly, yet the global trade finance gap remains approximately $2.5 trillion (ADB 2022), disproportionately affecting SMEs and deep-tier suppliers. Companies with strong, verifiable ESG credentials can access preferential financing terms, reducing their cost of capital and improving margins.

**How UNTP helps** — UNTP provides a standardised framework based on international standards that enables development banks and commercial lenders to assess ESG risk consistently. This unlocks trade finance for deep-tier suppliers who previously lacked the visibility to qualify. Digital Conformity Credentials provide the verifiable ESG evidence that lenders require, while the transparency graph enables risk assessment across multiple supply chain tiers.

**Quantification** — 2–10% reduction in financing costs for companies with verified sustainability credentials. Sustainability-linked loans typically offer margin reductions of 5–25 basis points; the benefit is most material for companies with large debt portfolios or those currently constrained by the trade finance gap. References: [ADB Trade Finance Gaps 2023](https://www.adb.org/publications/2023-trade-finance-gaps-growth-jobs-survey), [IFC Sustainable Finance 2020](https://www.ifc.org/en/home).

**Key variables**
- Current financing costs and access to trade finance
- Depth and complexity of supply chain
- ESG maturity and existing certifications
- Lender appetite for sustainable finance products in relevant markets

### Digitalisation Efficiency

**Description** — Digitalisation through UNTP enables automated data collection and processing, reducing manual labour and errors. Enhanced visibility into supply chain activities allows for better inventory management, demand forecasting, and faster decision-making. Access to accurate, real-time data improves overall operational performance.

**How UNTP helps** — UNTP Digital Traceability Events and Digital Product Passports provide standardised, machine-readable data flows across the supply chain. This data integrates with existing ERP and supply chain management systems, automating processes that were previously manual. The transparency graph provides end-to-end visibility that supports predictive analytics and proactive management.

**Quantification** — 3–10% reduction in supply chain documentation and data management costs through automation and standardised data exchange. Note: UNTP adds a credential and data interoperability layer — it is not a full supply chain digitalisation platform. Benefits are concentrated in cross-enterprise data exchange (supplier data collection, compliance documentation, traceability reporting) rather than internal operations. References: [McKinsey digital transformation reports](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/unlocking-success-in-digital-transformations).

**Key variables**
- Current level of supply chain digitalisation
- Volume and complexity of supply chain transactions
- Number of manual processes that can be automated
- Integration capability of existing IT systems

## Benefits — Corporate Value

### Brand Reputation

**Description** — Transparency in supply chains builds consumer trust, as customers and investors are increasingly concerned about the ethical and environmental impact of products. Companies that can demonstrate verifiable commitment to sustainability are more likely to gain consumer loyalty, attract investment, and command brand premiums.

**How UNTP helps** — UNTP provides the verifiable evidence behind sustainability claims, moving beyond marketing assertions to machine-verifiable credentials. Digital Product Passports make sustainability data accessible to consumers, investors, and rating agencies. This builds trust through transparency rather than narrative.

**Quantification** — Qualitative benefit. While studies suggest correlations between sustainability perception and brand value, the effect of any single initiative (including UNTP) is impossible to isolate from other factors such as marketing spend, product quality, and competitive dynamics. Brand value effects typically manifest over medium-to-long time horizons. References: [Brand Finance Sustainability Perceptions 2025](https://brandirectory.com/reports/sustainability-perceptions-index).

**Key variables**
- Current brand value and market positioning
- Consumer sensitivity to sustainability in target markets
- Competitor sustainability positioning
- Consistency and credibility of current sustainability messaging

### Improved Disclosures

**Description** — Regulations mandating annual corporate sustainability disclosures are in force or being drafted in most economies. They generally require reporting of concrete metrics such as CO2-equivalent emissions, including scope 3 (upstream supply chain) emissions. Most corporations lack the supplier data to directly measure scope 3, forcing reliance on industry-average intensity factors — which provide no mechanism to reward or select lower-intensity suppliers.

**How UNTP helps** — Digital Product Passports from suppliers provide direct measurement of product-level sustainability performance, replacing industry-average estimates. This enables corporations to select more sustainable supply and demonstrate year-on-year improvement in their own aggregate performance. The transparency graph aggregates supplier DPPs into disclosure-ready metrics.

![Transaction to disclosure roll up](PassportDisclosuresRollUp.png)

**Quantification** — Qualitative benefit. Companies with verifiable supply chain data can demonstrate actual (rather than estimated) scope 3 performance, which strengthens regulatory compliance posture and supports better outcomes across all other benefit categories (brand, finance, market access). The value is in moving from estimated to actual data — the magnitude of improvement is organisation-specific and depends on the gap between current estimates and actual supplier performance. References: [WBCSD Pathfinder 2.0 Framework](https://www.wbcsd.org/resources/pathfinder-framework-version-2-0/).

**Key variables**
- Scope 3 emissions as proportion of total emissions
- Number and diversity of suppliers
- Current reliance on industry-average vs actual data
- Applicable disclosure regulations (CSRD, SEC climate rules, ISSB)

## Costs — Sustainable Practices

### Process Improvement

**Description** — Suppliers are often required to implement ESG improvements aligned with buyers' sustainability strategies. This may include reducing carbon emissions from energy-intensive processes, switching to renewable energy sources, eliminating harmful chemicals, or improving labour practices. These transitions require real investment but are often partially offset by efficiency gains and green finance.

**How UNTP helps** — UNTP does not directly reduce the cost of process improvement, but it ensures that investments in sustainability are visible and valued by the market. DPPs and DCCs make improvement verifiable, enabling suppliers to capture the market access, price premium, and finance benefits described above. This makes the business case for process improvement stronger and the payback period shorter.

**Quantification** — 2–8% of operational costs for the first 3 years of ESG transition, declining as improvements are embedded. Partially offset by green finance grants and efficiency gains. References: IFC transition cost data, UNIDO industrial energy efficiency studies.

**Key variables**
- Current sustainability maturity (more to do = higher initial cost)
- Sector-specific transition requirements
- Availability of green finance and grants
- Energy and material cost structures

### Audits and Certification

**Description** — Third-party certification is the most credible way to verify sustainability claims, carrying greater weight than self-assessment or buyer audits for both voluntary and regulatory compliance. Certifications typically need to be obtained for each relevant ESG risk area, with costs for initial certification and ongoing annual surveillance.

**How UNTP helps** — UNTP Digital Conformity Credentials digitise certification evidence, making it reusable across multiple buyers and regulatory contexts. Multi-scheme mutual recognition, facilitated by the [Conformity Assessment Body (CAB)](../specification/ConformityCredential) framework, reduces duplication by allowing a single assessment to satisfy multiple requirements.

**Quantification** — $10K–$50K per certification type (initial assessment); $5K–$20K annual surveillance. Multi-scheme recognition through UNTP can reduce total certification costs by consolidating overlapping requirements.

**Key variables**
- Number of certification schemes required by buyers/regulators
- Complexity of operations being assessed
- Geographic spread of facilities
- Existing certifications that may satisfy multiple requirements

## Costs — Transparency System

### Capital Investment

**Description** — Implementing a UNTP-conformant transparency system requires consulting to assess the supply chain structure and data elements, software integration or adaptation, staff training, and project management. The scale of investment depends significantly on organisation size and existing digital maturity.

**How UNTP helps** — UNTP is designed to work with existing systems rather than requiring replacement. The protocol specifies open standards and interoperable data formats, allowing organisations to extend their current ERP, supply chain, and compliance systems. When implemented at community level through a [Community Activation Program (CAP)](../governance/CommunityActivationProgram.md), costs are significantly reduced as software vendors implement UNTP once for all their customers.

**Quantification** — $50K–$200K for SMEs; $200K–$1M for large enterprises. Significantly reduced when implemented at community level via CAP, as software vendors, certifiers, and industry associations share implementation costs across their communities.

**Key variables**
- Organisation size and supply chain complexity
- Existing digital maturity and system landscape
- Whether implementing individually or as part of a community
- Availability of UNTP-ready software from existing vendors

### Operational Costs

**Description** — Ongoing costs include credential issuance (signing and hosting DPPs, DCCs, DTEs), identity resolver hosting, system maintenance, and staff to manage the transparency system. UNTP is designed to work with what is already available, so these costs are typically incremental to existing IT operations.

**How UNTP helps** — UNTP's standards-based approach means that operational costs leverage existing infrastructure. Credential issuance can be automated as part of existing business processes (e.g. issuing a DPP as part of shipping documentation). Identity resolver hosting can be shared at community level.

**Quantification** — $10K–$50K/year for SMEs; $50K–$200K/year for large enterprises. Often largely absorbed into existing IT operations budgets.

**Key variables**
- Transaction volume (number of credentials issued per year)
- Whether resolver hosting is individual or shared
- Level of automation achieved during implementation
- Existing IT operations budget and capacity

## Business Case Template

A downloadable [business case template](../assets/files/UNTP-Business-Case-Template-Industry.docx) with quantification summary table and narrative structure is available as a Word document. The template is designed to be populated using the benchmark ranges above combined with organisation-specific financial data (e.g. annual report, management accounts) — including with the assistance of AI tools as described below.

## Generate Your Own Business Case

You can use a frontier AI model (such as ChatGPT, Claude, or Gemini) to generate a first-draft business case for your organisation. Upload your company's annual report (PDF) alongside the prompt below. The AI will extract your financial data, apply the UNTP benchmark ranges weighted to your specific industry and geography, and produce a complete draft business case using the template above.

**Prerequisites:** This prompt requires a frontier AI model with a large context window (100K+ tokens) and the ability to process PDF attachments. You will likely need a professional-tier subscription (e.g. ChatGPT Plus/Pro, Claude Pro, Gemini Advanced) to handle the combined size of the annual report, the UNTP cost/benefit framework, and the business case template in a single session.

**Important disclaimer:** The generated business case is only an initial draft. AI models may misinterpret financial data, apply benchmark ranges inappropriately, or make unfounded assumptions about your organisation's regulatory exposure, supply chain structure, or competitive position. The output should be thoroughly reviewed and adjusted by subject matter experts before being used for any decision-making purpose.

**How to use:** Copy the prompt below, open your preferred AI assistant, attach your annual report PDF, paste the prompt, and submit.

:::info[Business Case Generation AI Prompt]

You are preparing a first-draft UNTP business case for the company whose annual report is attached.

**Input documents**

1. **Annual report** — attached PDF. Extract: company name, sector, revenue, export revenue, geographic markets, supply chain description, existing certifications/sustainability initiatives, ESG disclosures, and any mentions of regulatory compliance costs or sustainability spending.

2. **UNTP cost/benefit framework** — fetch from https://untp.unece.org/business-case/BusinessCaseIndustry and use the benchmark ranges for each benefit and cost category.

3. **Business case template** — fetch from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Industry.docx and use this as the output structure. Fill in every section and every bracketed placeholder.

**How to weight each benefit category**

IMPORTANT: Always err on the side of conservatism. Use the lower end of each benchmark range unless there is strong, specific evidence from the annual report to justify a higher figure. A credible business case with conservative estimates is far more useful than an optimistic one that loses credibility under scrutiny. When in doubt, round down. If evidence for a benefit category is weak or absent, use the minimum of the range or exclude it entirely.

Weight each benefit category based on what you know about this specific company, its sector, and its geography:

- **Market access** — weight HIGH if the company exports to the EU, US, Japan, or Australia and operates in sectors subject to EUDR, CBAM, ESPR, UFLPA, or CSDDD. Weight LOW if primarily domestic or in unregulated sectors.
- **Unit price uplift** — weight HIGH for consumer-facing brands with sustainability positioning. Weight LOW for undifferentiated commodity producers.
- **Anti-counterfeiting** — weight HIGH for pharmaceuticals, luxury goods, premium wines/spirits. Weight NEAR-ZERO for bulk commodities, construction materials, most B2B industrials. Note: the benchmark range (0.1–2%) refers to per-company revenue recovery, not total counterfeit trade volume.
- **Compliance cost reduction** — weight HIGH if the company reports significant regulatory compliance spend or operates across many jurisdictions. Weight MEDIUM for most exporters.
- **Finance cost reduction** — weight HIGH if the company mentions trade finance constraints, operates in developing countries, or is an SME. Weight LOW for investment-grade corporates with strong ESG ratings already.
- **Operational efficiency** — weight HIGH if the company has complex multi-tier supply chains with manual processes. Weight LOW if already highly digitised.
- **Brand reputation** — weight HIGH for consumer brands. Weight LOW for B2B intermediaries.
- **Improved disclosures** — weight HIGH if the company reports under CSRD, ISSB, or SEC climate rules and acknowledges scope 3 data gaps. Weight LOW if not subject to disclosure regulations.

For costs, adjust based on:

- **Organisation size** — use the low end of capital investment ranges for SMEs, high end for large enterprises.
- **Digital maturity** — reduce cost estimates if the company already has modern ERP/supply chain systems.
- **Community implementation** — reduce costs significantly if the company operates in a sector with an active UNTP Community Activation Program.

**Output requirements**

1. Populate the full template — every section, every table, every placeholder. Use actual figures from the annual report where available; use informed estimates (with reasoning) where not.
2. In section 4.4 (Estimation Assumptions), assign a confidence level (H/M/L) to each benefit and explain your reasoning based on the company's specific context.
3. In section 4.3 (Net Value and Payback), provide conservative, base case, and optimistic scenarios. The conservative case should use the low end of applicable ranges; the optimistic case should use the high end.
4. In section 6 (Dependencies), assess the actual readiness of the ecosystem the company operates in — name specific software vendors, registers, and conformity schemes relevant to its sector and geography.
5. In section 7.3 (Do-Nothing Risk), be specific about which regulations affect this company and by when.
6. Throughout, show your working — explain why you chose a particular point in a benchmark range, citing specific evidence from the annual report or your knowledge of the sector.

**Output format**

Download the business case template from https://untp.unece.org/assets/files/UNTP-Business-Case-Template-Industry.docx and produce the output as a completed version of that Word document. Fill in every bracketed placeholder, populate every table, and replace all instructional text with company-specific content. The output should be a ready-to-review Word document that can be presented to a board or investment committee without further formatting.

:::

---

## Impact Assessment Framework

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

# Impact Assessment Framework

## Introduction

The Impact Assessment Framework (IAF) provides a structured methodology for measuring the value of UNTP implementation at global scale. While the [business case for industry](BusinessCaseIndustry.md) and [business case for government](BusinessCaseGovernment.md) describe the expected benefits of UNTP adoption, the IAF defines how those benefits are actually measured over time through real implementation data.

The IAF closes the feedback loop between implementation activity and demonstrable impact. As registered implementers progress from planned to active status, they provide 6-monthly anonymised volumetric reports via the same [implementation registration](../implementations/) process. These reports are aggregated at community and global levels to produce dashboards and scorecards that track UNTP impact over time.

The methodology follows an OECD-style results framework that traces a causal chain from implementer investments (inputs) through directly measurable activity (outputs) to modelled market effects (outcomes) and, ultimately, estimated contributions to UN [Sustainable Development Goal](https://sdgs.un.org/goals) targets (impacts). This four-level structure ensures that reporting remains grounded in observable data while still connecting implementation activity to the global goals that motivate it.

## Results Framework

The IAF uses a four-level results chain. Each level builds on the previous one, with increasing reliance on modelling assumptions as the chain progresses from directly measured data to estimated global impact.

```
Inputs → Outputs → Outcomes → Impacts
(invested)  (measured)  (modelled)  (estimated)
```

### Inputs

Inputs represent what implementers invest in UNTP adoption. These are not collected as part of the IAF reporting process but are described here to complete the results chain. Typical input categories include:

- **Capital investment** — system integration, consulting, credential infrastructure setup, and conformity testing. These are one-time costs incurred during implementation.
- **Operational investment** — credential issuance, identity resolution, ongoing system maintenance, and staff time. These are recurring costs that scale with transaction volume.

Reference cost categories are described in detail in the [Business Case for Industry](BusinessCaseIndustry.md#costs--transparency-system) and [Business Case for Government](BusinessCaseGovernment.md) pages.

### Outputs

Outputs are the directly measurable results of UNTP implementation. They are collected from each registered implementer via 6-monthly volumetric reports. Output metrics are specific to each implementer type and are defined in detail in the [Output Metrics](#output-metrics) section below.

Outputs answer the question: *how much UNTP activity is happening?*

### Outcomes

Outcomes are the market-level effects that result from aggregate UNTP outputs. They are modelled from output data using defined assumptions rather than directly measured. Key outcome categories include:

- **Supply chain transparency coverage** — the proportion of global trade value covered by verifiable digital credentials, estimated from the aggregate volume and commodity scope of issued DPPs.
- **Greenwashing reduction** — the shift from unverifiable sustainability claims to verifiable conformity credentials, estimated from DCC volumes relative to known certification markets.
- **Regulatory compliance efficiency** — the reduction in compliance burden enabled by machine-readable credentials, estimated from regulator DCC volumes and identity resolution traffic.

Outcomes answer the question: *what difference is UNTP activity making?*

### Impacts

Impacts are the long-term societal changes to which UNTP adoption contributes. They are estimated by mapping outcome indicators to specific SDG targets as described in the [SDG Target Mapping](#sdg-target-mapping) section below.

Impact measurement acknowledges attribution challenges. UNTP is one of many interventions contributing to sustainable development outcomes. The IAF therefore reports UNTP's *contribution* to SDG targets rather than claiming sole causation.

Impacts answer the question: *how is UNTP activity contributing to global goals?*

## Output Metrics

Each implementer type reports a defined set of volumetric metrics every 6 months. These metrics are designed to be simple to collect and to avoid exposing commercially sensitive information.

### Industry Actors

| Metric | Description | Unit |
|---|---|---|
| DPPs issued | Digital Product Passports issued in the reporting period | Count |
| Product categories | UN CPC product categories covered by issued DPPs | Count |
| Countries | Countries in which DPPs were issued | Count |
| DFRs issued | Digital Facility Records issued or updated | Count |
| DTEs issued | Digital Traceability Events published | Count |

### Software Solutions

| Metric | Description | Unit |
|---|---|---|
| Active customers | Customer organisations with active UNTP implementations | Count |
| Credential types | UNTP credential types supported (DPP, DCC, DFR, DTE, DIA) | List |
| Industry sectors | UN ISIC sectors served by active customers | Count |
| Countries served | Countries in which customers operate | Count |

### Conformity Scheme Owners

| Metric | Description | Unit |
|---|---|---|
| CVCs published | Conformity Vocabulary Catalogs published | Count |
| Conformity topics | Conformity topic categories covered | Count |
| Industry sectors | UN ISIC sectors covered by published schemes | Count |
| Countries | Countries in which schemes are active | Count |

### Conformity Assessment Bodies

| Metric | Description | Unit |
|---|---|---|
| DCCs issued | Digital Conformity Credentials issued in the reporting period | Count |
| Conformity schemes | Number of different conformity schemes assessed against | Count |

### Regulators

| Metric | Description | Unit |
|---|---|---|
| DCCs issued | Digital Conformity Credentials issued (permits, licenses, certificates) | Count |
| Regulation types | Types of regulation covered by issued DCCs | Count |
| Regulated entities | Number of entities holding government-issued DCCs | Count |

### Identity Registers

| Metric | Description | Unit |
|---|---|---|
| Resolution requests | Identifier resolution requests processed | Count |
| DIAs issued | Digital Identity Anchors issued or updated | Count |
| Registered members | Number of registered members or entities | Count |

## Aggregation Model

IAF data is aggregated at three levels, with anonymisation applied at each aggregation boundary.

**Implementer level** — Each registered implementer submits their own 6-monthly volumetric report. Individual data is held confidentially and is not published. Implementers can benchmark their own performance against anonymised averages for their implementer type, sector, and geographic region.

**Community level** — [Community Activation Program](../governance/CommunityActivationProgram.md) governance bodies aggregate reports from implementers within their sector or region. Community-level dashboards allow member associations and development banks to track the progress and value of their community investment.

**Global level** — UN/CEFACT aggregates community-level data across all communities to produce global dashboards for member states. Global aggregates are mapped to SDG targets and published in annual impact reports.

All data is anonymised at aggregate levels. No individual implementer's data is identifiable in community or global reports.

## SDG Target Mapping

Aggregate outcome indicators are mapped to specific SDG targets to estimate UNTP's contribution to the global goals. The mapping below connects IAF outcome categories to the most relevant targets.

| Outcome Category | SDG Targets | Example Indicator |
|---|---|---|
| Verifiable emissions data | 13.2 — Climate action integration | Trade volume covered by verified carbon data |
| Ethical sourcing evidence | 8.7 — End forced labour | DCC coverage of social compliance criteria |
| Circular economy data | 12.5 — Reduce waste generation | DPPs with circular economy fields populated |
| Deforestation-free supply | 15.2 — Sustainable forest management | DPPs covering forest-risk commodities |
| Responsible production | 12.6 — Sustainable practices and reporting | Companies with verifiable sustainability disclosures |
| Clean water and chemicals | 6.3 — Improve water quality | DPPs with chemical compliance data |

This mapping builds on the conformity topic classification defined in the [UNTP core taxonomies](../specification/CoreTaxonomies.md), which provides a structured vocabulary for linking conformity criteria to sustainability themes.

## Reporting Process

**Frequency** — Reports are submitted 6-monthly for the periods January to June and July to December.

**Mechanism** — Implementers submit volumetric data via the same [registration process](../implementations/) used for initial implementation registration. Reporting is integrated into the existing registration workflow to minimise additional burden.

**Anonymisation** — Individual implementer data is not published. Only sector-level and geographic aggregates are made available in dashboards and reports.

**Publication** — UN/CEFACT publishes aggregated dashboards on an ongoing basis and produces an annual impact report summarising global UNTP adoption and its estimated contribution to SDG targets.

**First reporting** — IAF reporting will commence when a sufficient number of registered implementations reach Active status to produce meaningful aggregates.

## Relationship to Business Case

The IAF is designed to progressively replace qualitative estimates with empirical benchmarks. The cost and benefit projections in the [business case for industry](BusinessCaseIndustry.md) and [business case for government](BusinessCaseGovernment.md) are currently supported by references to external research. As IAF data accumulates, these projections will be supplemented — and eventually validated or refined — by actual implementation data from registered implementers.

At the community level, [CAP](../governance/CommunityActivationProgram.md) governance bodies can use IAF dashboards to demonstrate realised value to potential members, strengthening the case for new organisations to join. At the global level, UN/CEFACT can use IAF reports to inform policy recommendations for member states and to demonstrate the impact of UNTP to funding bodies and development partners.

---

## Benefits of Adoption

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## The Business Case for UNTP implementation

In this section we provide a broad analysis of the key drivers, impacts, costs, and benefits associated with the implementation of the United Nations Transparency Protocol (UNTP) in an overall digital trade facilitation program.

* [Community activation program](#community-activation-program) defines a methodology and business case for industry member associations to engage their membership for collective implementation at the community level.
* [Impact assessment framework](#impact-assessment-framework) defines the UNTP KPIs that will be measured so that global impact can be tracked — essentially the UNTP business case for UNECE.
* [Business case for industry](#business-case-for-industry) details the business value propositions and costs for UNTP implementation by industry at individual company level and provides a simple business case template.
* [Business case for government](#business-case-for-government) details the business case for governments at both individual agency and national economy levels.
* [Case for schemes and registers](#case-for-schemes-and-registers) details the business case for the trust infrastructure services that UNTP depends on — conformity schemes, conformity assessment bodies, identity registers, and identity resolver operators.

## [Community Activation Program.](../governance/CommunityActivationProgram.md)

Supply chain actors are often reluctant to proceed with a specific initiate like UNTP unless they have some confidence that others in their industry are doing the same. There are not only obvious interoperability benefits from industry wide adoption but also cost benefits.

For example, it is often the case that a small number of commercial software platforms are commonly used by larger numbers of businesses in a given industry and jurisdiction. So a software vendor that implements UNTP once will benefit all it's customers. Additionally there are often a few standards and a few certifiers that are common to an industry and country. Finally, when a large community is willing to act together, there will often be financial incentives from governments and/or development banks that can assist with initial funding. In short, there are many reasons to approach UNTP implementation at a community level.

The Community Activation Program (CAP) is a methodology and business case for a community level adoption of UNTP including a tool for financial cost/benefit modelling at community level. The CAP is an ideal vehicle for existing industry member associations to bring new value to their members by supporting their connections into global sustainable value chains.

For more information, please visit the [Community Activation Program](../governance/CommunityActivationProgram.md) page.

## [Impact Assessment Framework.](ImpactAssessmentFramework.md)

Once a community or individual company implements UNTP and transparency data starts to flow at scale, it will become important to continuously assess the actual impact realised. Dashboards and scorecards that measure key performance indicators will energise ongoing action and provide valuable feedback at both community and UN level. Therefore the UNTP defines a minimal set of KPIs that each implementer can easily measure and report to their community - and which communities can report to the UN so that global impact can be measured and mapped to the 169 specific targets defined by the [17 UN Sustainable Development Goals](https://sdgs.un.org/goals).

For more information, please visit the [Impact Assessment Framework](ImpactAssessmentFramework.md) page.

## [Business Case for Industry.](BusinessCaseIndustry.md)

In today's global marketplace, commercial incentives drive business action. With regard to sustainable business practices and products, there is a maturity trend in the way businesses think about value.

* **Historically** sustainability was a marketing exercise that focused primarily on green labeling to promote sales.

* **Currently** the explosion of stakeholder expectations has led to a similarly dramatic increase in company- and product-level disclosure regulations aimed at counteracting greenwashing and supporting national net-zero commitments.

* **For the future** organisations are placing sustainability at the front and centre of their business strategy, profitability, and brand value. UNTP provides value chain transparency at scale, enabling brands to be confident in the implementation of their sustainability strategies.

At a high level adopting UNTP offers several key benefits:

* **Supply Chain Optimization** : Detailed supplier data allows for informed selection of more sustainable and resilient supply options.

* **Enhanced Disclosure Accuracy** : Access to granular, product-level sustainability data enables precise reporting and provides the key information needed for organisations to select suppliers, ensuring that their year-on-year sustainability disclosures demonstrate a clear improvement trend.

* **Reputational Risk Management** : Transparency in the supply chain helps mitigate risks associated with unsustainable supplier practices.

* **Financial Advantages** : The financial sector increasingly rewards strong sustainability credentials with improved terms for trade finance and investment capital.

* **Traceability and trackability** : Detailed data enable enhanced logistics and product quality management. It also supports circular economy options and, more broadly, end-of-use-cycle management.

For more information and templates, please visit the [Business Case for Industry.](BusinessCaseIndustry.md) page.

## [Business Case for Government.](BusinessCaseGovernment.md)

The implementation of the UNTP is expected to yield significant economic benefits for participating nations. While the precise impact may vary based on a country's existing trade infrastructure, regulatory environment, and level of digitalization, there are several opportunities for improvement.

* **Trade cost reduction** : Implementation of the UNTP is projected to reduce trade costs through the standardisation and digitization of processes. This includes streamlining customs clearance, documentation, inspections, and other administrative procedures.

* **Enhanced Revenue Collection** : Improved compliance and reduced fraud, facilitated by the UNTP's transparency measures, may lead to more effective revenue collection from customs duties and taxes.

* **Facilitate Trade Policy Development** : Receiving granular data and attributes of what gets in and out of the country and being able to aggregate that data can help policy makers in shaping policy in a more targeted way to enhance their countries competitiveness.

* **Foreign Direct Investment (FDI)** : Nations adopting the UNTP may become more attractive to foreign investors due to increased efficiency and predictability in trade processes.

* **Supply Chain Resilience and Competitiveness** : The real-time data and transparency provided by the UNTP can enhance the resilience of supply chains to disruptions and improve overall competitiveness in the global market.

The realisation of these benefits may depend on several factors, including:

* The nation's initial conditions and existing trade barriers
* The extent and effectiveness of UNTP implementation
* Complementary reforms in areas such as infrastructure, governance, and technology

The UNTP is supported by UNECE policy [Recommendation 49 - traceability and transparency at scale](https://unece.org/trade/documents/2024/07/session-documents/draft-recommendation-no-49-transparency-scale) that defines specific recommendations for member states that wish to reap the economic benefits of increased supply chain traceability, transparency, and trust.

For more information and templates, please visit the [Business Case for Government.](BusinessCaseGovernment.md) page.

## [Case for Schemes and Registers.](BusinessCaseDependentServices.md)

UNTP depends on a supporting ecosystem of trust infrastructure services — conformity schemes that publish digital criteria vocabularies, conformity assessment bodies (CABs) that issue Digital Conformity Credentials, identity registers that issue Digital Identity Anchors, and identity resolver operators that host discovery infrastructure. Without these services, UNTP credentials cannot be issued, verified, or discovered.

Each of these service types has a distinct business case for UNTP conformance:

* **Expanded market reach** — As UNTP adoption grows, conformant services become the default choice for participating supply chains. Non-conformant services risk losing market share.

* **Multi-scheme recognition** — Schemes that publish digital criteria vocabularies enable mutual recognition, making their scheme usable across more supply chain contexts without duplicative assessments.

* **New revenue streams** — CABs can offer digital credential issuance as a value-added service; registers can offer DIA issuance and resolver hosting as fee-based services.

* **Operational efficiency** — Machine-readable scheme criteria reduce assessment effort by 20–30%. Automated credential lifecycle management reduces administrative overhead by 50–70%.

* **Trust and credibility** — Registers that issue DIAs and schemes that publish transparent digital criteria strengthen their institutional authority and relevance.

For more information, please visit the [Case for Schemes and Registers](BusinessCaseDependentServices.md) page.

---

## Different Digital Maturities

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview

The world will not transition from paper to digital overnight. For years — possibly decades — supply chains will operate with a mix of PDF documents, paper certificates, and digitally verifiable credentials. Every UNTP implementer faces the same reality: some upstream suppliers are not yet issuing verifiable digital data, and some downstream customers are not yet equipped to consume it. This page describes the challenges of this transition period and the UNTP design patterns that address them.

## Challenges

### Upstream: Unstructured Input Data

Most supply chain actors will encounter upstream suppliers that have not yet implemented UNTP. Their product and facility data arrives as PDF documents, scanned certificates, spreadsheets, or even paper records. This creates several problems for an implementer trying to build a [transparency graph](./TrustGraphs.md):

* **No machine-readable structure** — the data cannot be automatically loaded into a graph database or validated against business rules.
* **No cryptographic integrity** — PDF documents and paper certificates are trivially easy to fake with modern AI tools. There is no digital signature to verify authenticity.
* **No consistent discovery** — unlike UNTP credentials that are discoverable via [identity resolvers](../specification/IdentityResolver.md), unstructured data arrives through ad-hoc channels (email, portals, physical mail) with no standardised way to check for updates.
* **No entity linking** — a PDF certificate might refer to "Copper mining facility seven" while the graph knows the same facility as ID `https://someregister/facilities/5558880000030`. Without structured identifiers, linking data across credentials is manual and error-prone.

### Downstream: Customers Not Ready for Digital

At the other end, an implementer that issues UNTP digital credentials may find that some customers cannot process them. A small retailer scanning a QR code on a product expects to see something human-readable — not a JSON-LD document. If digital credentials are only machine-readable, they create a barrier to adoption rather than removing one. The challenge is to issue credentials that serve both technically advanced verifiers running automated compliance checks and less technical actors who need a simple, readable document.

## Solution

### Ingesting Unstructured Data with AI

For upstream suppliers that have not yet implemented UNTP, the recommended approach is to use AI (Large Language Models) to transform unstructured data into graph-compatible linked data — but to **flag that data as unverified**.

![unstructured data](Graphs-Unstructured.png)

The diagram shows a case where the mine-site and the refiner have not implemented UNTP and are producing PDF documentation. The smelter and fabricator use an LLM to transform the PDF data into UNTP-structured linked data before loading it into their transparency graph. This means the same algorithmic assessments and validation rules can run across the entire graph, but portions derived from unstructured sources will be marked as lower integrity — warranting sample-based human review or traditional auditing.

There are important considerations for this approach:

* **Entity matching** — UNTP depends on globally unique identifiers to link data. A PDF document might refer to a facility by a different name than the graph uses. LLMs are well suited to matching similar entities, so implementers should follow [GraphRAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) best practices: first ask the LLM to extract and match entities against existing graph nodes, then transform the data using matched identifiers.
* **Discovery** — The [Identity Resolver](../specification/IdentityResolver.md) need not be limited to discovering UNTP credentials. It can also make PDF product or facility data consistently discoverable. Even before implementing UNTP credentials, there is value in making existing data discoverable via an identity resolver — this standardises how downstream actors find and refresh your data.
* **Integrity** — AI cannot generate valid cryptographic signatures. Unstructured data ingested via LLM should be treated as unverified and clearly flagged in the graph. Implementers should plan to transition suppliers from PDF documents to digitally signed credentials over time.

In the diagram above, the mine-site passes unstructured data to the smelter via an unmanaged channel, so the smelter must manually request updates and cannot be sure the data is genuine. However the refiner, although still exchanging unstructured data, publishes it through an identity resolver — so the fabricator can be confident it is genuine refiner data and can automate the discovery and update process.

### Human and Machine Readable Credentials

The solution to the downstream challenge is straightforward: **every UNTP credential is designed to be both human-readable and machine-readable**. This is achieved through two mechanisms built into the [Verifiable Credentials Profile](../specification/VerifiableCredentials.md):

* **Render templates** — Every UNTP credential SHOULD include a `renderMethod` property that defines an HTML template for human-readable rendering. When a person scans a QR code on a product, the credential can be displayed as a nicely formatted document — complete with logos, claims, and assessment results — without any specialised software.
* **Hosted verifier links** — Credentials can include a link to a hosted verification service. A low-maturity actor simply clicks the link and sees a verified, human-readable document in their browser. A high-maturity actor processes the raw credential data programmatically.

A good analogy is the modern passport. It is a paper document with a photo page that humans inspect — but it also contains an embedded chip that smart gates read automatically. Both the border officer and the automated gate use the same passport; they just consume it differently. UNTP credentials follow exactly the same pattern — a consumer with a phone sees a rendered, human-readable product passport, while a compliance system ingests the structured JSON-LD data and loads it into a transparency graph for automated verification. There is no need for separate "paper" and "digital" versions. A single credential serves all maturity levels.

Related design patterns cover other aspects of data sharing that are not specific to the paper-to-digital transition: [Variant-Based Disclosure](./VariantBasedDisclosure.md) addresses how to serve different data to different consumer roles (regulators, buyers, public), and [Mass Balance](./MassBalance.md) covers upstream confidentiality and audited transparency for supply chain traceability.

### Transition Maturity Levels

The table below illustrates how a single product (a battery) might be represented at different stages of the paper-to-digital transition.

| Maturity Level | Upstream Data | Downstream Output | Graph Quality |
|---|---|---|---|
| **Level 1** — Paper only | PDF certificates from mine and refiner, received by email | Paper certificate shipped with goods | No graph — manual review only |
| **Level 2** — Discoverable but unstructured | PDFs published behind identity resolvers | PDF discoverable via QR code on product | Partial graph — AI-ingested, flagged as unverified |
| **Level 3** — Mixed credentials | UNTP credentials from refiner, PDFs from mine | UNTP credential with render template | Mostly verified graph — unverified portions flagged |
| **Level 4** — Fully digital | UNTP credentials from all upstream suppliers | UNTP credential consumed by automated systems | Fully verified transparency graph |

Most implementers will operate at Level 2 or 3 for an extended period. The key insight is that **every level is useful** — even AI-ingested unstructured data in a graph provides more actionable compliance intelligence than unconnected PDF files in email inboxes.

## Examples

### Human and Machine Readable Credential

The sample below is a UNTP Digital Product Passport issued as a verifiable credential. The URL (or QR scan) resolves to a hosted verifier that displays a human-readable version. Raw JSON data can be viewed via the `JSON` tab and the full credential can be downloaded via the download button.

| URL | QR | Description |
|---|---|---|
| [Sample Digital Product Passport](https://untp.showthething.com/verify?uri=https%3A%2F%2Funtp-storage.s3.ap-southeast-2.amazonaws.com%2Fde0ef9bd-f1b1-4804-88cb-fadda5b7dd51.json) | ![Sample Digital Product Passport](../assets/images/sample-dpp-qrcode-v0.7.0.jpeg) | A sample digital product passport as a signed Verifiable Credential. Scanning the QR code or clicking the link opens the same credential in a hosted verifier — a human sees a rendered passport, while a machine can consume the raw JSON-LD data. |

### AI-Assisted Mapping of Unstructured Data

Given a well-documented UNTP vocabulary, credential schema, conformity topic taxonomy, and identifier scheme register, it is feasible to produce fully compliant UNTP data from unstructured sources and add it to a transparency graph. There are a number of commercial products that specialise in this kind of structured data extraction, but anyone can test the feasibility for themselves. Simply find a publicly available independent audit report (to map to a UNTP conformity credential) or a product brochure with an environmental product declaration (to map to a UNTP product passport), and use a prompt similar to the following in your preferred AI assistant:

> *"Using the attached audit report, create a UNTP Digital Conformity Credential JSON instance that complies with the guidance and JSON schema at https://untp.unece.org/docs/specification/ConformityCredential and the conformity topic taxonomy at https://untp.unece.org/docs/specification/CoreTaxonomies. Map any identifiers found in the document to well-structured globally unique identifiers using the identifier scheme guidance at https://untp.unece.org/docs/implementations/idr"*

The results are typically surprisingly good — demonstrating that the barrier to transforming existing unstructured supply chain data into graph-compatible UNTP credentials is lower than most implementers expect. The identifier mapping step is particularly important because it ensures that entities extracted from unstructured sources can be linked to existing nodes in the transparency graph rather than creating disconnected duplicates.

---

## Digital Wallets

import Disclaimer from '../\_disclaimer.mdx';

# Digital wallets

<Disclaimer />

## Overview

UNTP is **wallet-agnostic**. It neither mandates nor precludes the use of digital wallets for storing, managing, or exchanging verifiable credentials. The protocol's primary credential exchange model is a resolver-based "pull" pattern where credentials are published by issuers and discovered by verifiers through [Identity Resolvers](../specification/IdentityResolver) or linked data. However, there are legitimate implementation contexts — particularly those driven by regulatory requirements or existing digital identity infrastructure — where digital wallets play a valuable role. This page provides guidance for implementers operating in those contexts.

A digital wallet, in the context of UNTP, is any software application that enables an entity to receive, store, manage, and present verifiable credentials. Wallets may be operated by organisations (enterprise wallets) or individuals (personal wallets), and may be hosted services or edge applications running on a user's device.

## Challenges

The verifiable credentials ecosystem has matured around a model where a human **holder** stores credentials in a personal wallet and presents them to verifiers on demand. This model works well for personal identity credentials such as driver's licenses and educational certificates, where the holder is a person who can actively participate in a presentation exchange.

UNTP operates in a fundamentally different context. The subject of most UNTP credentials is an **inanimate object** — a box of goods, a shipment of steel, a battery module.  As the [Verifiable Credentials](../specification/VerifiableCredentials#verifiable-presentations) specification explains:

> *The box of goods does not create verifiable presentations on demand and the binding is to the identity of the goods.* 

In supply chain scenarios, any party with physical or digital access to a product identifier (via a barcode, QR code, or RFID tag) can discover credentials about that product through an Identity Resolver. 

There is no human "holder" in the loop presenting credentials from a wallet. This is why UNTP's architecture centres on the resolver-based pull model rather than a wallet-based push model.

This does not mean wallets are irrelevant. It means UNTP is designed so that wallets are **one possible mechanism** among several for credential exchange — not a prerequisite.

## When wallets are relevant

Although the resolver-based pull model is the primary UNTP credential exchange pattern, digital wallets become relevant in several implementation scenarios.

**Organisational identity and accreditation.** When a supply chain actor needs to prove its identity or accreditation status to access non-public credentials (see [Decentralised Access Control](../specification/DecentralisedAccessControl) Pattern 6), an enterprise wallet can store and present [Digital Identity Anchor](../specification/DigitalIdentityAnchor) credentials, accreditation credentials, or role-based authorisation credentials. For example, an accredited recycler presenting its DIA credential to a battery manufacturer's access control endpoint to obtain decryption keys for confidential facility records. 

**Regulatory compliance in wallet-mandated jurisdictions.** Some regulatory frameworks — notably the [EU Digital Identity (EUDI) Wallet](https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet-toolbox) initiative under the eIDAS 2.0 regulation — are establishing infrastructure where digital wallets are a primary mechanism for credential exchange. Implementers operating in these jurisdictions may need to support wallet-based flows alongside resolver-based discovery to meet local regulatory expectations. 

**Business-to-business credential exchange.** In scenarios where supply chain actors have established commercial relationships and exchange credentials as part of procurement or onboarding workflows, enterprise wallets or credential management platforms can streamline the exchange of digital product passports, conformity credentials, and traceability events. The UNTP specification explicitly permits this:

> A conformant UNTP implementation MAY exchange these and any other credentials as verifiable presentations in wallet-to-wallet transfers or any other method. 

**Consumer-facing transparency.** When end consumers interact with product transparency information through mobile applications, the consumer's device may function as a lightweight wallet that receives and stores verifiable credentials for offline verification, comparison shopping, or personal sustainability tracking.

## Design principles for wallet implementations

Implementers introducing wallets into UNTP deployments should follow the same design principles that underpin the broader protocol.

### Postel's robustness principle applies

The UNTP [Verifiable Credentials](../specification/VerifiableCredentials) specification applies [Postel's robustness principle](https://en.wikipedia.org/wiki/Robustness_principle): **be conservative in issuing and liberal in verifying**.  For wallet implementations, this means:

- When a wallet **issues or presents** UNTP credentials, it MUST conform to the [UNTP Verifiable Credentials Profile](../specification/VerifiableCredentials) — specifically W3C VC Data Model v2.0, JSON-LD Compacted Document Form, JOSE enveloping proofs, and `did:web` as the organisational DID method. 
- When a wallet **receives or verifies** credentials, it SHOULD accept the widest practical range of credential formats. Sustainability evidence discovered across a value chain may arrive as W3C VCs, ISO mDL credentials, or even human-readable PDF documents. 

This asymmetry is deliberate. Strict issuance ensures interoperability across the ecosystem. Liberal verification ensures that sustainability assessments can draw on the broadest possible evidence base.

### Resolver-based discovery remains primary

A wallet-based exchange does not replace the need for resolver-based credential publication. Conformant UNTP implementations MUST issue and publish credentials discoverable via Identity Resolvers regardless of whether those credentials are also exchanged via wallets.  The resolver-based model ensures that any party with access to a product identifier can discover credentials without requiring a prior relationship, wallet infrastructure, or specific software.

Wallets and resolvers are **complementary, not competing** models. A practical deployment may use resolver-based discovery for public product transparency data and wallet-based exchange for confidential credentials requiring authenticated access.

### No lock-in to specific wallet technologies

Consistent with UNTP's principle that it is a **protocol, not a platform**,  implementations MUST NOT require counterparties to adopt any specific wallet software, wallet provider, or wallet framework.  The interoperability boundary is defined by the credential format and exchange protocol, not by the wallet application.

## Conformity requirements

The following requirements apply to UNTP implementations that incorporate digital wallet functionality.

| ID     | Name                  | Requirement Statement                                                                                                           | Solution Mapping                                                   |
| ------ | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| WAL-01 | Credential format     | Credentials issued or presented from a wallet MUST conform to the UNTP Verifiable Credentials Profile                           | [VC Profile](../specification/VerifiableCredentials#vcdm-profile)  |
| WAL-02 | Resolver publication  | Credentials exchanged via wallet MUST also be published and discoverable via an Identity Resolver                               | [Identity Resolver](../specification/IdentityResolver)             |
| WAL-03 | Technology neutrality | Implementations MUST NOT require counterparties to use any specific wallet software or provider                                 | [Architecture](../specification/Architecture)                      |
| WAL-04 | Liberal verification  | Wallet-based verifiers SHOULD accept credentials in any format that can be meaningfully verified                                | [VC Profile](../specification/VerifiableCredentials#verifiable-presentations) |
| WAL-05 | DID methods           | Wallets issuing or presenting UNTP credentials MUST use `did:web` as the organisational DID method                              | [DID Methods](../specification/VerifiableCredentials#did-methods)  |
| WAL-06 | Access control        | Wallets used for authenticated access to non-public credentials SHOULD implement DID-Authentication and MAY implement OpenID4VP | [DAC](../specification/DecentralisedAccessControl)                 |

## Examples

### Pattern A: Resolver discovery with wallet-assisted authentication

This is the most common pattern where wallets add value in UNTP deployments. The primary credential discovery flow uses the standard resolver-based pull model. When the verifier encounters a non-public (encrypted) credential, the wallet assists with the authentication step required to obtain decryption keys.

1. Verifier scans product data carrier and queries the Identity Resolver
2. Resolver returns a link-set including both public and non-public credential links
3. Verifier retrieves and verifies public credentials directly
4. For non-public credentials, the link-set indicates the required `accessRole` and `encryptionMethod` 
5. Verifier's wallet presents a DID-Authenticated request including role credentials (e.g., DIA proving accredited recycler status)
6. Data provider validates the presentation and returns decryption keys
7. Verifier decrypts and verifies the non-public credentials

This pattern combines the universality of resolver-based discovery with the security of wallet-based authentication. It aligns with [Decentralised Access Control](../specification/DecentralisedAccessControl) Pattern 6 (Decentralised Authentication).

### Pattern B: Direct wallet-to-wallet credential exchange

In this pattern, supply chain actors exchange UNTP credentials directly through wallet infrastructure, bypassing resolver-based discovery for the initial exchange. This may be appropriate for B2B procurement workflows where parties have established relationships.

1. Issuer creates UNTP credentials (DPP, DCC, DTE) conforming to the VC Profile
2. Issuer's wallet packages credentials as a Verifiable Presentation signed by the issuer's DID
3. Presentation is transmitted to the receiver's wallet via any mutually agreed protocol
4. Receiver's wallet verifies the presentation and extracts the credentials
5. Issuer MUST also publish the credentials via an Identity Resolver (WAL-02)

Note that even in direct wallet-to-wallet exchange, the credentials themselves are standard UNTP VCs. The wallet is a transport mechanism; the credential format and semantics are what ensure interoperability.

## Relationship to other UNTP specifications

Digital wallets interact with several UNTP specifications. The table below maps the key touchpoints.

| UNTP Specification                                                          | Wallet Relevance                                                                                 |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| [Verifiable Credentials Profile](../specification/VerifiableCredentials)    | Defines the credential format that wallets MUST use when issuing or presenting UNTP credentials  |
| [Identity Resolver](../specification/IdentityResolver)                      | Wallets complement but do not replace resolver-based credential discovery                        |
| [Digital Identity Anchor](../specification/DigitalIdentityAnchor)           | DIAs may be stored in and presented from organisational wallets for identity verification        |
| [Decentralised Access Control](../specification/DecentralisedAccessControl) | Wallet-based DID-Authentication (Pattern 6) enables access to non-public credentials             |
| [Digital Product Passport](../specification/DigitalProductPassport)         | DPPs may be exchanged via wallet-to-wallet transfer as an alternative to resolver discovery      |
| [Digital Conformity Credential](../specification/ConformityCredential)      | DCCs may be stored in organisational wallets and presented during procurement or audit workflows |

## Conclusion

UNTP is deliberately wallet-agnostic because its primary use case — product-level sustainability transparency — centres on inanimate objects discoverable through resolvers rather than human holders presenting from wallets.  This design ensures the widest possible adoption across supply chain actors of varying technical maturity. Where wallets are relevant — for organisational authentication, regulatory compliance, B2B exchange, or consumer interaction — they function as a complementary transport and management layer. The credential format and semantics defined by the UNTP Verifiable Credentials Profile are what ensure interoperability,  regardless of whether those credentials travel through a resolver, a wallet, an email attachment, or a QR code printed on the side of a box.

---

## Durable Storage

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

# Durable Storage

## Overview

A common and important question raised by UNTP implementers and policymakers is:

> *"What happens to a Digital Product Passport or conformity credential when the issuing organisation goes out of business?"*

This page provides guidance on how UNTP credential publishers can select storage approaches that ensure their credentials remain accessible, tamper-evident, and verifiable for the full required lifetime of those credentials — independent of any individual organisation or service provider.

This guidance is relevant to all actors who publish UNTP credentials including issuers of:

- [Digital Product Passports (DPP)](../specification/DigitalProductPassport.md)
- [Digital Conformity Credentials (DCC)](../specification/ConformityCredential.md)
- [Digital Traceability Events (DTE)](../specification/DigitalTraceabilityEvents.md)
- [Digital Facility Records (DFR)](../specification/DigitalFacilityRecord.md)
- [Digital Identity Anchors (DIA)](../specification/DigitalIdentityAnchor.md)

---

## Challenges

UNTP credentials are designed to carry sustainability, traceability, and conformity claims that must remain verifiable for the lifetime of a product, facility, or business — which may be decades. However, the organisations that issue those credentials (manufacturers, certifiers, conformity assessment bodies) are subject to the normal lifecycle of businesses: they may restructure, be acquired, become insolvent, or simply cease operations.

Similarly, commercial storage or hosting services used by those organisations may be discontinued, acquired, or changed.

The challenge this creates has three distinct dimensions:

1. **Availability**: Will the credential still be retrievable at its URL after the issuer is gone?
2. **Integrity**: Can a verifier be confident the content at a given URL has not been silently altered or replaced?
3. **Economic sustainability**: Who pays for storage to continue when the original publisher no longer exists?

A naive approach — hosting credentials on the issuer's own web server or even a standard cloud provider — fails on all three counts once the issuer stops paying their bills. Even blockchain-based or decentralised storage networks are not immune: networks can lose critical mass of participants, be abandoned by their developer communities, or become economically unviable if token incentives collapse. No technical solution can guarantee infinite longevity, but the approaches described below are designed to maximise durability by distributing both the storage responsibility and the economic incentive to serve data across many independent actors.

---

## Why a Protocol-Based Approach Is Preferred

UNTP is a fundamentally decentralised architecture. It deliberately avoids any requirement for a central data repository. This design principle applies equally to credential storage.

Rather than recommending a centralised national or international backup register — which would be costly to build, politically contentious to govern, and fragile as a single point of failure — UNTP recommends a **protocol-based** approach to durable storage.

A compliant durable storage approach SHOULD satisfy all three of the following properties:

1. **Post-issuer availability**: The credential continues to be served even after the original publisher has ceased operations.
2. **Post-provider availability**: The credential continues to be served even if the specific storage service provider also ceases operations.
3. **Tamper-evident integrity**: It is not possible to silently replace or alter a credential at its storage address without detection.

Existing open protocols already satisfy these properties. The following sections describe them and provide practical implementation guidance.

---

## Content-Addressable Storage: The Key Concept

The foundation of durable, tamper-evident storage is **content-addressability**. In a content-addressable system:

- The **address** (identifier/URL) of a credential is derived directly from a cryptographic hash of its content.
- This means a given address always and only refers to one specific document. Any change to the document — even a single character — produces a completely different address.
- Because the address *is* the hash of the content, any party serving the content can be verified independently, without trusting the server itself.

This approach is fundamentally different from conventional web hosting, where a URL like `https://company.example/dpp/product-123.json` is just a pointer controlled by the domain owner, who can change or delete the content at will without any external party detecting the substitution.

Content-addressable storage underpins both of the primary protocols recommended below.

---

## Recommended Protocols

### IPFS — InterPlanetary File System

[IPFS](https://ipfs.tech/) is a widely-adopted, open, content-addressable distributed file system. Key properties relevant to UNTP:

- **Content Identifiers (CIDs)**: Every object stored in IPFS is identified by a CID — a hash-based, self-describing identifier. This CID is the canonical address of a credential regardless of which node serves it.
- **Competitive marketplace of storage nodes**: Many independent IPFS pinning services and gateways exist. If one goes offline, the content remains accessible from others that have pinned the same CID.
- **Vendor neutrality**: Because the CID is independent of any specific provider, publishers can migrate between storage providers without changing the credential's address.
- **HTTP gateway compatibility**: IPFS content is accessible via standard HTTPS gateways (e.g., `https://ipfs.io/ipfs/<CID>` or `https://<CID>.ipfs.dweb.link`), ensuring compatibility with conventional web verifiers.

#### Filecoin — Economic Incentives for IPFS Durability

[Filecoin](https://filecoin.io/) operates on top of IPFS and adds a cryptoeconomic incentive layer. Storage "miners" are rewarded for proving they continue to store specific data over time. This means:

- Storage can be paid for in advance for a defined period (or in perpetuity through endowment-style deals).
- Even after a publisher ceases operations, independent miners have a financial incentive to continue serving the data.
- Filecoin is complementary to IPFS: the same CID is used, and content is retrievable through any IPFS-compatible gateway.

### Arweave — Permanent, Incentivised Storage

[Arweave](https://www.arweave.org/) is a separate protocol designed specifically around the concept of **permanent, one-time-payment storage**. Key properties:

- **Endowment model**: Publishers pay a single upfront fee calculated to fund storage in perpetuity by a decentralised network of miners.
- **Permaweb**: Data stored on Arweave is added to an append-only, immutable ledger — content cannot be deleted or altered.
- **Content addressing**: Like IPFS, Arweave uses content-based transaction IDs, providing tamper-evident integrity.
- **Long-term economic design**: The protocol's economic model is explicitly designed to sustain storage without ongoing payments from the original publisher, making it particularly well-suited to the "issuer goes out of business" scenario.

In effect, Arweave combines the distributed storage of IPFS with the economic durability incentives of Filecoin in a single, self-contained protocol.

---

## Storage Maturity Levels

UNTP acknowledges that implementers will have varying levels of technical capability and risk tolerance. The following maturity levels are provided to guide implementers and help policymakers understand the relative durability of different approaches.

### Level 1 — Self-Hosted (Baseline)

The credential publisher hosts credentials on their own infrastructure (web server, cloud storage bucket, etc.).

| Property                   | Assessment                                                                        |
| -------------------------- | --------------------------------------------------------------------------------- |
| Post-issuer availability   | ❌ Credentials will likely become unavailable when the publisher ceases operations |
| Post-provider availability | ❌ Dependent on the publisher's infrastructure and payment continuity              |
| Tamper-evident integrity   | ⚠️ Dependent on credential signature only; URL content can be silently replaced    |
| Cost                       | Low                                                                               |
| Complexity                 | Low                                                                               |

This approach is adequate for early pilot implementations and short-lived credentials but is **not recommended** for production Digital Product Passports that must remain accessible for the product's full lifetime.

### Level 2 — Managed Commercial Storage

The publisher uses a commercial cloud or managed hosting service (e.g., a major cloud provider's object storage) with up-front contractual terms for a defined retention period.

| Property                   | Assessment                                                                                                                          |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Post-issuer availability   | ⚠️ Dependent on contract terms and continued payment; likely fails when issuer ceases operations                                     |
| Post-provider availability | ⚠️ Major providers are relatively durable but operate on recurring payment models — credentials will be deleted if fees are not paid |
| Tamper-evident integrity   | ⚠️ Dependent on credential signature only unless content-addressable hosting is used                                                 |
| Cost                       | Low–Medium                                                                                                                          |
| Complexity                 | Low                                                                                                                                 |

**Note**: Even major cloud providers (AWS, Azure, Google Cloud) do not currently offer a "pay once, store forever" model. All operate on a recurring-fee basis, which means credentials will be deleted when payment stops — which will typically happen when a business ceases operations.

This level provides modest improvement over Level 1 but does not adequately address the core durability problem for long-lived credentials.

### Level 3 — Protocol-Based Durable Storage (Recommended)

The publisher stores credentials using a content-addressable, economically incentivised decentralised storage protocol such as Filecoin or Arweave.

| Property                   | Assessment                                                                                                      |
| -------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Post-issuer availability   | ✅ Content remains accessible via any compatible gateway, independent of the original publisher                  |
| Post-provider availability | ✅ No single provider dependency; content addressed by hash, served by any participating node                    |
| Tamper-evident integrity   | ✅ Content addressing guarantees integrity at the storage layer, in addition to the VC's cryptographic signature |
| Cost                       | Low (especially Arweave's one-time model)                                                                       |
| Complexity                 | Medium                                                                                                          |

This is the **recommended approach** for all UNTP credentials that must remain accessible for multi-year or multi-decade periods. It is the only non-government approach that can credibly satisfy the durability requirements of regulations such as the EU Digital Product Passport framework without requiring state-managed infrastructure.

---

## How Durable Storage Interacts with UNTP Identity Resolution

UNTP uses an [Identity Resolver](../specification/IdentityResolver.md) to link a product identifier (e.g., a GS1 Digital Link) to the set of credentials associated with that product. The relationship between identity resolution and durable storage is as follows:

- The **Identity Resolver** provides a discoverable, resolvable link to the current location of a credential. This link can be updated if a credential is re-issued or migrated.
- The **credential's storage address** (e.g., an IPFS CID or Arweave transaction ID) is the permanent, tamper-evident reference to a specific credential version.
- For Level 3 implementations, it is recommended that the Identity Resolver link-set include the content-addressable URI (e.g., `ipfs://<CID>` or `ar://<txid>`) alongside any HTTPS gateway URL, so that verifiers can independently confirm integrity.

This combination means that:

1. Discoverability is maintained through the identity resolution layer.
2. Long-term integrity and availability are guaranteed through the durable storage layer.

---

## Guidance for Policymakers and Regulators

National regulations inspired by the EU DPP model often propose a centralised government-managed backup register as a solution to the post-issuer availability problem. UNTP recommends that policymakers consider protocol-based durable storage as an alternative or complement to such registers, for the following reasons:

- **Lower cost**: Protocol-based storage requires no government infrastructure build-out or ongoing operational budget.
- **Higher scalability**: A decentralised network scales naturally with the volume of credentials without central bottlenecks.
- **Greater durability**: Decentralised protocols are not subject to a single point of failure, including government budget cuts or policy changes.
- **Higher integrity**: Content-addressable storage provides tamper-evidence at the storage layer that a conventional register cannot offer without additional technical measures.
- **Vendor and jurisdiction neutrality**: No single national government, company, or jurisdiction controls access to the stored data.

Where national regulation requires a register, policymakers are encouraged to design that register as an **index of content-addressable identifiers** (pointing to credentials stored in decentralised protocols) rather than as a centralised store of credential content. This approach provides the regulatory assurance of a known inventory while leveraging the durability and integrity of open protocols.

---

## Implementation Guidance for Credential Publishers

Publishers wishing to implement Level 3 durable storage should follow these steps:

1. **Generate the credential** according to the relevant UNTP specification (DPP, DCC, DTE, etc.) and sign it with the issuer's DID key.
2. **Store the credential** using a supported durable storage protocol:
   - For IPFS + Filecoin: Use a pinning service such as [web3.storage](https://web3.storage/), [Pinata](https://www.pinata.cloud/), or [Lighthouse](https://www.lighthouse.storage/) and request a Filecoin storage deal for long-term durability.
   - For Arweave: Upload using the [Arweave SDK](https://docs.arweave.org/) or a bundling service such as [Irys (formerly Bundlr)](https://irys.xyz/).
3. **Record the content-addressable identifier** (CID or Arweave TX ID) returned by the storage service.
4. **Register the credential** in your Identity Resolver link-set, including:
   - An HTTPS gateway URL for broad compatibility.
   - The native content-addressable URI (`ipfs://<CID>` or `ar://<txid>`) for integrity verification.
5. **Verify retrievability** by resolving the CID or TX ID through an independent gateway before publishing the product identifier.

---

## Summary

|                                     | Level 1     | Level 2                 | Level 3                    |
| ----------------------------------- | ----------- | ----------------------- | -------------------------- |
| **Storage**                         | Self-hosted | Commercial cloud        | IPFS+Filecoin or Arweave   |
| **Survives issuer closure**         | ❌           | ⚠️                       | ✅                          |
| **Survives provider closure**       | ❌           | ❌                       | ✅                          |
| **Tamper-evident at storage layer** | ❌           | ❌                       | ✅                          |
| **One-time payment possible**       | N/A         | ❌                       | ✅ (Arweave)                |
| **Recommended for production**      | Pilots only | Short-lived credentials | All long-lived credentials |

For any UNTP credential that must remain accessible for the lifetime of a physical product — particularly Digital Product Passports — **Level 3 protocol-based durable storage is strongly recommended**.

---

## Linked Lifecycle Data

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview 

[Digital Product Passports (DPPs)](../specification/DigitalProductPassport.md) are typically issued at the point of manufacture, capturing critical information about materials, provenance, and sustainability attributes. However, a product's lifecycle extends far beyond the factory gate - through retail, consumer use, repairs, maintenance, refurbishment, and eventual end-of-life processing. This design pattern addresses how to add verifiable post-sale lifecycle data to products without modifying the original DPP.

## Challenges

Consider a battery manufactured in 2026 with an accompanying DPP issued by the manufacturer. Nine years later in 2034:
* The battery requires repair at an authorized service center
* The original manufacturer may have been acquired, restructured, or ceased operations 
* The current owner needs to document the repair event for warranty, compliance, or resale purposes
* Downstream buyers need access to the complete maintenance history

The approach of re-issuing DPPs creates problems:
* **Loss of provenance:** Original manufacturing data becomes disconnected or suspect
* **Authorization challenges:** Who has the authority to re-issue credentials for products they didn't manufacture? 
* **Fragmentation:** Multiple competing "versions" of a products history may emerge
* **Verification complexity:** How do verifiers know which version is authoritative? 

## Solution

UNTP solves this problem through the **[Identity Resolver](../specification/IdentityResolver.md) pattern**: maintain an **immutable original [DPP](../specification/DigitalProductPassport.md)** while enabling multiple authorized parties to add lifecycle events as new linked credentials. This approach:
* Preserves integrity and verifiability of the original DPP
* Enables distributor custody (different parties contribute data through various lifecycle stages)
* Maintains a complete, verifiable audit trail
* Works even when the original manufacturer is no longer operating

### Key Design Principles

#### Never Modify the Original DPP

The DPP issued by the manufacturer represents a cryptographically signed statement about the product at a specific point in time. Modifying it would:
* Invalidate the original signature
* Undermine trust in the manufacturing data
* Create ambiguity about what changed and when 

**Principle:** The original DPP remains immutable and always accessible as the canonical manufacturing record. 

#### Use Identity Resolver for Link Management

The [Identity Resolver](../specification/IdentityResolver.md) serves as the discovery mechanism for all credentials related to a product identifier. Instead of modifying the DPP, authorized parties add new links to the resolver. 

##### Example linkset structure

```json
{
  "identifier": "01/09520123456788/21/12345",
  "linkset": [
    {
      "anchor": "01/09520123456788/21/12345",
      "itemDescription": "Industrial Battery Model X-200",
      "links": [
        {
          "type": "application/vc+ld+json",
          "linkType": "verifiableCredential",
          "rel": "productPassport",
          "href": "https://manufacturer.example/dpp/abc123",
          "title": "Original Digital Product Passport",
          "hash": "sha256-a8f7d...",
          "controlParty": "did:web:manufacturer.example",
          "created": "2025-03-15T10:00:00Z"
        },
        {
          "type": "application/vc+ld+json",
          "linkType": "verifiableCredential",
          "rel": "traceabilityEvent",
          "href": "https://retailer.example/dte/sale-456",
          "title": "Sale to End Customer",
          "hash": "sha256-b9e8c...",
          "controlParty": "did:web:retailer.example",
          "created": "2025-06-20T14:30:00Z"
        },
        {
          "type": "application/vc+ld+json",
          "linkType": "verifiableCredential",
          "rel": "traceabilityEvent",
          "href": "https://service-center.example/dte/repair-789",
          "title": "Battery Cell Replacement - 2034-01-15",
          "hash": "sha256-c1f9d...",
          "controlParty": "did:web:service-center.example",
          "created": "2034-01-15T11:00:00Z",
          "previousEvent": "https://retailer.example/dte/sale-456"
        }
      ]
    }
  ]
}
```

#### Enable Clear Authorization Roles

Not everyone should be able to add lifecycle events to a product. The Identity Resolver must enforce policies to ensure only authorized parties can add links. 

**For detailed information on authorization and authentication mechanisms for adding links, see the [Decentralised Access Control](../specification/DecentralisedAccessControl.md) specification.** This specification describes how parties can prove their authorization to add lifecycle events through mechanisms such as shared secrets, DID authentication, and role-based access control. 

## Examples

**Scenario:** Battery repair after 9 years

**Actors**:
* **Manufacturer:** (`did:web:battery-corp.example`) - Originally produced the battery in 2025
* **Retailer:** (`did:web:electronics-store.example`) - Sold battery to end customer in 2025
* **Owner:** (`did:web:owner.example`) - Purchased battery in 2025, uses it for 9 years
* **Service Center:** (`did:web:service-center.example`) - Performs repair in 2034
* **[Identity Resolver](../specification/IdentityResolver.md):** (`https://id.example/01/09520123456788/21/12345`) - Discovery service

**Workflow:**

```mermaid
sequenceDiagram
    participant M as Manufacturer
    participant O as Owner
    participant SC as Service Center
    participant IR as Identity Resolver
    
    M->>IR: Register DPP
    M->>O: Deliver product
    O->>SC: Request repair service
    SC->>IR: Retrieve product linkset
    SC->>SC: Perform repair
    SC->>IR: Add repair event link(requires authorization)
```

:::info Authorization and Authentication
When adding lifecycle event links to the Identity Resolver, parties must prove their authorization. The [Decentralised Access Control](../specification/DecentralisedAccessControl.md) specification defines the mechanisms for authentication and authorization, including shared secrets, DID authentication, and role-based access control. Implementers should refer to that specification for detailed guidance on how to authorize parties to add links.
:::

### Roadmap 

* Explore the use of cryptographic links between lifecycle events to create a verifiable chain. 
* Document how archival of [Identity Resolver](../specification/IdentityResolver.md) operators can be handled.

---

## Mass Balance

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

## Overview

Chain of custody refers to the documented, end-to-end record of how a product or material moves and is transformed from origin to final use. Its purpose is to provide traceability and integrity, proving where something came from, what happened to it, and who was responsible at each step. There are several well-understood chain of custody models, each balancing operational practicality against assurance strength:

| Model | Physical Separation | Claim Strength | Description |
|-------|-------------------|----------------|-------------|
| Identity Preserved | Strict (single source) | Strongest | Exact certified source remains unblended throughout the chain |
| Segregated | Strict (certified only) | Strong | Certified materials from multiple sources may be combined but never mixed with non-certified |
| Mass Balance | Mixing allowed | Moderate | Qualifying and non-qualifying materials may be mixed; output claims limited to qualifying input proportions |
| Book and Claim | Fully decoupled | Market-driven | Sustainability attributes traded as credits, independent of physical product flow |

This page focuses on the **mass balance** model, which is the most common approach for bulk commodities and complex supply chains where physical segregation is impractical or cost-prohibitive. Book and Claim is covered in a separate page.

## Challenges

The [transparency graphs](TrustGraphs.md) page describes how data in UNTP credentials can be assembled to construct a verifiable digital twin of a supply chain — linking products to the facilities that made them and, via traceability events, to the upstream materials used in manufacturing. However, it does not address how to verify that the sustainability claims on output products are actually supported by the input materials and production processes. This is the domain of mass balance chain of custody.

### Are Output Claims Matched by Inputs?

Consider these concrete scenarios:

* **Organic cotton fabric** — A buyer purchases certified organic and fair-work cotton fabric from a weaver. The weaver can show evidence of some upstream purchases of certified raw cotton. But how can the buyer be sure that the fabric does not include mixed non-compliant cotton? If the weaver buys 40% certified organic cotton and 60% conventional, only 40% of output fabric should carry the organic claim.
* **Low-carbon steel** — A buyer of low-carbon steel products needs confidence that the claimed emissions intensity is matched by purchases of low-emissions ore by the refiner. If the refiner blends ore from multiple sources with different carbon footprints, the output emissions claim must reflect the weighted average of actual inputs, not a cherry-picked best case.
* **Certified mineral sourcing** — A copper smelter claims that its refined copper comes from 100% certified mines. But does the smelter actually source sufficient certified copper concentrate to back that claim across all its output, or is it re-using certificates from a small certified supply to cover a much larger uncertified volume?

More generally, the challenge is to verify that the **totality of output performance claims from a facility are matched by input material and production process performance metrics**. Mass balance fraud happens when actors buy small quantities of high-integrity inputs but claim much larger volumes of sustainable outputs. Without facility-level material accounting, this is undetectable.

### Commercial Confidentiality

A further and very important constraint is that, for a buyer to satisfy themselves that their supplier has appropriate mass balance controls, the buyer would need full visibility of **all** facility inputs, outputs, and production processes — including supply volumetrics, yield rates, and stock levels. This data is almost always commercially sensitive. Facilities will not publish their production volumes, supplier relationships, or material accounting ledgers for competitors to see.

This creates a fundamental tension: mass balance verification requires comprehensive facility-level data, but that data is too commercially sensitive to share openly. Any viable solution must resolve this tension — enabling trustworthy verification without requiring public disclosure of commercial secrets.

## Solution

UNTP addresses the mass balance challenge through facility-level material accounting anchored in the same credentials used for transparency graphs, combined with privacy-preserving audit mechanisms that resolve the confidentiality tension.

### Facility-Level Material Accounting

UNTP material accounting follows the same fundamental logic as financial accounting:

| Financial Accounting | UNTP Material Accounting |
|---------------------|---------------------|
| Chart of accounts | Digital Product Passports (DPPs) describe characteristics and intensity metrics of identified input and output materials |
| Balance sheet | Digital Traceability Events (DTEs) with bizStep "stocktake" record material stocks at a point in time |
| Ledger transactions | DTEs with bizStep "shipping" or "transformation" account for input/output flows and production runs |
| Audited accounts | Digital Conformity Credentials (DCCs) carry independently audited conformance and verified intensity metrics |
| Facility conformity | Digital Facility Records (DFRs) carry facility-level conformity claims, certifications, and quality metrics |

The core principle is **conservation**:

```
Opening stock
  + inbound flows
  - outbound flows
  ± production transformations
= closing stock
```

This applies to mass, volume, or count and forms the foundation for all higher-level sustainability claims. Just as double-entry accounting makes financial fraud difficult by requiring transactions to balance, material accounting makes greenwashing difficult by requiring physical quantities to reconcile.

It is worth noting that the accounting analogy, whilst valuable, may imply an accuracy that exists in financial accounting but does not in material accounting, and even less in impact accounting. Material stocks and flows must allow for waste and losses, and emissions intensity calculations must allow for inaccuracies in reported intensities. UNTP allows for claims and assessments to report metrics together with an estimate of accuracy.

### Supporting All Production Models

Industrial processes fall into three broad categories, each producing a different but conceptually equivalent type of production record:

* **Discrete Manufacturing** produces individually serialised items (vehicles, machinery, electronics). The canonical record is the **as-built record** documenting actual components and processes for a specific serialised product.
* **Batch Manufacturing** processes identified inputs to produce identified outputs via discrete production batches (food processing, chemicals, refining). The canonical record is the **batch record**.
* **Continuous Production** produces a stream of output materials from a continuous stream of inputs (mining, oil production, bulk chemicals). The boundary is typically a time period, and the canonical record is the **production run record**.

All three record types are specialisations of a production record and differ only in how boundaries are defined (serial number, batch ID, or time window). All are represented as transformation event DTEs with quantity inputs and outputs.

### Separating Facts from Policy Claims

This approach separates **underlying material accounting** (facts about what physically happened) from **policy-driven claims** (assertions about sustainability attributes). This separation allows the same material accounting facts to support different chain of custody assessments. For example, when a facility records input material identity and quantity for every production run, the same records support:

* **Segregated chain of custody** — if all inputs for a given run meet the policy criteria claimed for the output
* **Mass balance chain of custody** — if the average of all inputs to multiple production runs matches the average of all outputs over a given period

The same separation facilitates multiple impact assessments from the same data. For example, given a shipment of 100 tonnes of copper ore with a DPP stating 2 tCO₂e/tonne ore and 25% copper concentration, the emissions intensity per tonne of contained copper is 2 ÷ 0.25 = 8 tCO₂e/tonne Cu.

### Aligning with Natural Industrial Processes

UNTP does not require facilities to change their manufacturing processes or record-keeping systems. No UNTP credential should carry information not reasonably available in production management systems at the time of issue:

* **Material flows** between facilities are recorded using shipping manifests — logistics-level flow records that production management systems already create.
* **Production runs** record consumption of inputs and creation of outputs — data that all production management systems maintain.
* **Facility stocks** record point-in-time inventory — running balances verified via periodic physical stock-takes.
* **Product records** define characteristics and intensity metrics of identified material types.

UNTP credentials map naturally to these records: DTEs carry flow information (shipping, transformation, stocktake events), DPPs carry material characteristics and intensity metrics, and DFRs carry facility-level conformity claims.

### Privacy-Preserving Verification

Most facilities will not provide public transparency into their internal production stocks and flows. Yet all facilities should operate on a level playing field where genuine commercial confidentiality concerns cannot be used to hide non-compliant behaviour. The answer is that facilities share their material accounting information with at least one trusted independent party, but not necessarily with everyone.

A key advantage of digital and verifiable source data is reduced auditing cost through increasingly automated algorithmic auditing. This permits every actor to choose an appropriate level of transparency vs confidentiality:

* **Random sample-based audits** — A facility maintains internal records using UNTP DTEs. All relevant material accounting data for a production period is grouped and signed as an evidence bundle, and only the hash is shared to support self-assessed claims. External auditors can request random bundles, verify the hash, and confirm claims via a DCC.
* **Outsourced continuous audit** — A facility streams all internal DTEs to a trusted external auditor who issues DCCs to back claims in DPPs and DFRs.
* **One-up-one-down verification** — Facilities share material accounting data only with direct customers, who do not share it further downstream.
* **Full public transparency** — Some businesses may choose full openness as a competitive advantage.

In all these models, the actual material accounting data and how it is embedded into credentials is the same. The only difference is **who** it is shared with.

### How Credentials Work Together

The diagram shows an overview of credential flows for a refiner facility seeking to provide chain of custody compliance assurance to its customers without revealing commercial sensitivities.

![chain of custody with UNTP](CoC-facilityAudit.png)

**Process flow:**

1. A supplier facility (e.g., a mine-site) ships material with a shipping manifest (DTE) listing material identifiers and quantities. The mine has also issued a DPP for each material and may include conformity assessments (DCCs). Following the UNTP identity resolver standard, the DPPs and DCCs are discoverable from material identifiers in the shipping manifest.
2. The refiner receives the inbound shipment. The inbound material may be mixed with other supplies of different qualities. The facility performs production runs and records quantities of input materials consumed and output materials produced as transformation event DTEs. The facility also performs periodic stock-takes recorded as stocktake event DTEs.
3. An external auditor (which, if all source data is digital, could be an algorithmic service) receives all stock and flow data (DTEs), pulls the DPPs for each identified material, verifies material accounting (balancing material mass), calculates impacts (e.g., emissions intensity), and issues DCCs at product and facility level.
4. The facility issues DPPs with declared product characteristics and intensity metrics and DFRs with facility-level conformity claims. The facility adds the DCCs from the independent auditor as verifiable support. A shipment of refined product is prepared for a customer with a shipping manifest listing identifiers and quantities.
5. The customer receives the shipment and can pull DPPs, DCCs, and DFRs that provide verifiable confidence in the qualities claimed — without needing to see the facility's internal production data. The receiving facility is now in the same position as step 1, and the process repeats.

**Criterion alignment:** Each assessment criterion in DPPs and DFRs has a unique `criterion.id`. When an auditor issues a DCC, the DCC's assessment criteria reference these same IDs, creating a verifiable link between facility claims and auditor verification.

### Fraud Resistance

Fraud in chain of custody claims will disadvantage legitimate actors and lead to a collapse in trust. When there is material value (higher prices or reduced taxes) attached to performance claims, there will be incentives to make fraudulent claims.

If all stocks and flows are digitally signed by responsible parties, time-ordered and immutable, and counterparty-anchored (suppliers sign outbound, receivers sign inbound), then mass-balance assurance becomes an **algorithmic audit problem** rather than requiring constant physical site inspections. An independent audit service can collect stock positions, gather all signed inbound and outbound flows, collect production records, apply conservation rules, and check for temporal consistency, counterparty consistency, impossible negative balances, and outputs exceeding possible inputs.

Key fraud countermeasures include:

* **Multi-party reconciliation** — Collusion is easiest pairwise but becomes fragile when third parties are involved. If A and B collude, they must ensure downstream buyer C's records also reconcile, scaling collusion to many actors.
* **Time-based plausibility constraints** — Material moves and transforms at finite rates. Fabricated flows often violate equipment capacity, transport time, or yield constraints.
* **Statistical anomaly detection** — Analysis of yield variance vs peers, suspiciously consistent loss rates, perfect reconciliation over long periods (real operations have noise), and sudden step changes aligned across facilities.
* **Independent anchoring points** — Transport operators signing manifests, weighbridge operators issuing signed weights, port intake records, and utility-based production constraints all break closed-loop fabrication.
* **Randomised physical audits** — Algorithmic audit runs continuously; facilities are randomly selected for spot checks weighted by anomaly scores. This is exactly how tax audits work.
* **Liability and counterparty risk linkage** — Audit failures propagate risk flags to connected parties; certifications or market access can be suspended.

The goal is not to make collusion impossible but to make it expensive, risky, fragile, and commercially dangerous. This is the same standard financial systems operate under.

## Examples

This section provides UNTP v0.7.0 credential examples for a copper supply chain demonstrating mass balance material accounting. The actors are:

* **Copper Mine** (`did:web:sample-mine.example.com`) — produces copper ore concentrate in Zambia
* **Refinery** (`did:web:sample-refinery.example.com`) — smelts and refines to LME Grade A copper cathode in Japan
* **Battery Factory** (`did:web:sample-battery.example.com`) — manufactures battery components in Germany

### Example 1: DPP for Input Ore

**Purpose:** Identity and characteristics (accounting analogy: chart of accounts)

A DPP identifies a product or material and declares intrinsic properties and performance claims — it does **not** assert quantity or location. DPPs are reusable references across facilities, shipments, and production records.

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.7.0/context/"
  ],
  "type": ["DigitalProductPassport", "VerifiableCredential"],
  "id": "https://credentials.sample-mine.example.com/dpp/cu-conc-2025",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-mine.example.com",
    "name": "Sample Copper Mine Pty Ltd"
  },
  "validFrom": "2025-03-01T00:00:00Z",
  "name": "Digital Product Passport — Copper Concentrate (Cu 30%)",
  "credentialSubject": {
    "type": ["Product"],
    "id": "https://id.sample-mine.example.com/product/cu-conc-2025",
    "name": "Copper Concentrate (Cu 30%)",
    "idGranularity": "model",
    "modelNumber": "SM-CU-CONC-30",
    "batchNumber": "2025-Q1-4501",
    "producedAtFacility": {
      "id": "https://facility-register.example.com/fac-001",
      "name": "Sample Copper Mine"
    },
    "countryOfProduction": { "countryCode": "ZM", "countryName": "Zambia" },
    "materialProvenance": [
      {
        "name": "Copper ore",
        "originCountry": { "countryCode": "ZM", "countryName": "Zambia" },
        "massFraction": 0.30,
        "recycledMassFraction": 0
      }
    ],
    "performanceClaim": [
      {
        "type": ["Claim"],
        "id": "https://sample-mine.example.com/claims/product-carbon-2025",
        "name": "Product Carbon Footprint — Copper Concentrate",
        "conformityTopic": {
          "type": ["ConformityTopic"],
          "id": "https://vocabulary.uncefact.org/conformity-topic/greenhouse-gas-emissions",
          "name": "Greenhouse Gas Emissions"
        },
        "claimedPerformance": [
          {
            "metric": {
              "id": "https://vocabulary.uncefact.org/performance-metric/product-carbon-footprint",
              "name": "Product Carbon Footprint"
            },
            "measure": { "value": 2.1, "unit": "KGM" }
          }
        ]
      }
    ]
  }
}
```

**Key observations:** The `credentialSubject` is a `Product` (not a wrapper). Uses `performanceClaim` with `claimedPerformance` containing metric references from the UNTP performance metrics vocabulary. Declares intensities, not absolute quantities.

### Example 2: DFR for Facility Conformity

**Purpose:** Facility-level certifications, material usage, and performance claims (accounting analogy: corporate certifications)

A DFR identifies a facility and declares certifications, material usage, and performance claims. The `materialUsage` property records aggregate material consumption over a reporting period — this is the facility-level "balance sheet" data that supports mass balance verification.

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.7.0/context/"
  ],
  "type": ["DigitalFacilityRecord", "VerifiableCredential"],
  "id": "https://credentials.sample-refinery.example.com/dfr/smelter-002",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd"
  },
  "validFrom": "2025-01-15T00:00:00Z",
  "validUntil": "2028-01-15T00:00:00Z",
  "name": "Digital Facility Record — Sample Copper Refinery",
  "credentialSubject": {
    "type": ["Facility"],
    "id": "https://facility-register.example.com/fac-002",
    "name": "Sample Copper Refinery",
    "countryOfOperation": { "countryCode": "JP", "countryName": "Japan" },
    "processCategory": [
      {
        "code": "41521",
        "name": "Unwrought copper",
        "schemeID": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
        "schemeName": "UN Central Product Classification (CPC)"
      }
    ],
    "relatedParty": [
      {
        "role": "owner",
        "party": {
          "type": ["Party"],
          "id": "did:web:sample-refinery.example.com",
          "name": "Sample Copper Refinery Co. Ltd"
        }
      }
    ],
    "materialUsage": {
      "applicablePeriod": {
        "startDate": "2024-01-01",
        "endDate": "2024-12-31"
      },
      "materialConsumed": [
        {
          "name": "Copper concentrate",
          "originCountry": { "countryCode": "ZM", "countryName": "Zambia" },
          "massFraction": 0.85,
          "mass": { "value": 420000000, "unit": "KGM" },
          "recycledMassFraction": 0
        }
      ]
    },
    "performanceClaim": [
      {
        "type": ["Claim"],
        "id": "https://sample-refinery.example.com/claims/ghg-2024",
        "name": "GHG Emissions — Scope 1",
        "conformityTopic": {
          "type": ["ConformityTopic"],
          "id": "https://vocabulary.uncefact.org/conformity-topic/greenhouse-gas-emissions",
          "name": "Greenhouse Gas Emissions"
        },
        "claimedPerformance": [
          {
            "metric": {
              "id": "https://vocabulary.uncefact.org/performance-metric/scope-1-ghg-emissions",
              "name": "Scope 1 GHG Emissions"
            },
            "measure": { "value": 120000, "unit": "TNE" }
          }
        ]
      }
    ]
  }
}
```

**Key observations:** The `credentialSubject` is a `Facility` directly. Uses `materialUsage` to report aggregate material consumption for the reporting period. Uses `performanceClaim` with `claimedPerformance` for facility-level metrics. The `relatedDocument` array (not shown) links to the Coppermark DCC.

### Example 3: DTE Move Event (Shipping)

**Purpose:** Material flows between facilities (accounting analogy: ledger transactions)

A `MoveEvent` records the physical movement of materials between facilities. It uses `movedProduct`, `fromFacility`, and `toFacility` to describe what moved and where.

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.7.0/context/"
  ],
  "type": ["DigitalTraceabilityEvent", "VerifiableCredential"],
  "id": "https://credentials.sample-refinery.example.com/dte/move-cathode-2025-0310",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd"
  },
  "validFrom": "2025-03-10T00:00:00Z",
  "name": "Shipment of Copper Cathode — Sample Refinery to Sample Battery Factory",
  "credentialSubject": [
    {
      "type": ["MoveEvent", "LifecycleEvent"],
      "id": "https://sample-refinery.example.com/events/move-cathode-2025-0310",
      "name": "Copper cathode shipment to Sample Battery Factory",
      "eventDate": "2025-03-10T14:00:00Z",
      "activityType": {
        "code": "shipping",
        "name": "Shipping",
        "schemeID": "https://ref.gs1.org/cbv/BizStep",
        "schemeName": "GS1 CBV Business Step"
      },
      "movedProduct": [
        {
          "product": {
            "id": "https://id.sample-refinery.example.com/product/cu-cathode-2025",
            "name": "LME Grade A Copper Cathode",
            "modelNumber": "SR-CU-CATH-9999",
            "batchNumber": "2025-Q1-0812",
            "idGranularity": "model"
          },
          "quantity": { "value": 2000, "unit": "KGM" },
          "disposition": "new"
        }
      ],
      "fromFacility": {
        "id": "https://facility-register.example.com/fac-002",
        "name": "Sample Copper Refinery"
      },
      "toFacility": {
        "id": "https://facility-register.example.com/fac-003",
        "name": "Sample Battery Factory"
      },
      "consignmentId": "urn:carrier:sea-freight:BL-2025-SG-BG-0310",
      "relatedParty": [
        { "role": "consignor", "party": { "type": ["Party"], "id": "did:web:sample-refinery.example.com", "name": "Sample Copper Refinery Co. Ltd" } },
        { "role": "consignee", "party": { "type": ["Party"], "id": "did:web:sample-battery.example.com", "name": "Sample Battery Mfg GmbH" } }
      ]
    }
  ]
}
```

**Key observations:** Uses `MoveEvent` (replacing the old `TransactionEvent` with bizStep "shipping"). The `movedProduct` array describes what was shipped with product identity, quantity, and disposition. `fromFacility` and `toFacility` replace `sourceParty`/`destinationParty`. The `credentialSubject` is an array (can carry multiple events). The counterparty (battery factory) would issue a corresponding receiving move event.

### Example 4: DTE Make Event (Production Run)

**Purpose:** Material transformation (accounting analogy: ledger transactions)

A `MakeEvent` records a production process that consumes input materials and creates output products. It uses `inputProduct`, `outputProduct`, and `madeAtFacility`.

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.7.0/context/"
  ],
  "type": ["DigitalTraceabilityEvent", "VerifiableCredential"],
  "id": "https://credentials.sample-refinery.example.com/dte/make-cathode-2025-0305",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd"
  },
  "validFrom": "2025-03-05T00:00:00Z",
  "name": "Smelting of Copper Concentrate into Copper Cathode",
  "credentialSubject": [
    {
      "type": ["MakeEvent", "LifecycleEvent"],
      "id": "https://sample-refinery.example.com/events/make-cathode-2025-0305",
      "name": "Copper smelting and electrolytic refining batch",
      "description": "Processing of 30 tonnes of copper concentrate (Cu 30%) through smelting and electrolytic refining to produce 10 tonnes of LME Grade A copper cathode (Cu 99.99%).",
      "eventDate": "2025-03-05T06:00:00Z",
      "activityType": {
        "code": "commissioning",
        "name": "Commissioning",
        "schemeID": "https://ref.gs1.org/cbv/BizStep",
        "schemeName": "GS1 CBV Business Step"
      },
      "inputProduct": [
        {
          "product": {
            "id": "https://id.sample-mine.example.com/product/cu-conc-2025",
            "name": "Copper Concentrate (Cu 30%)",
            "modelNumber": "SM-CU-CONC-30",
            "batchNumber": "2025-Q1-4501",
            "idGranularity": "model"
          },
          "quantity": { "value": 30000, "unit": "KGM" },
          "disposition": "consumed"
        }
      ],
      "outputProduct": [
        {
          "product": {
            "id": "https://id.sample-refinery.example.com/product/cu-cathode-2025",
            "name": "LME Grade A Copper Cathode",
            "modelNumber": "SR-CU-CATH-9999",
            "batchNumber": "2025-Q1-0812",
            "idGranularity": "model"
          },
          "quantity": { "value": 10000, "unit": "KGM" },
          "disposition": "new"
        }
      ],
      "madeAtFacility": {
        "id": "https://facility-register.example.com/fac-002",
        "name": "Sample Copper Refinery"
      },
      "relatedParty": [
        { "role": "manufacturer", "party": { "type": ["Party"], "id": "did:web:sample-refinery.example.com", "name": "Sample Copper Refinery Co. Ltd" } }
      ],
      "relatedDocument": [
        {
          "linkURL": "https://credentials.sample-refinery.example.com/dpp/cu-cathode-2025",
          "linkName": "Digital Product Passport — LME Grade A Copper Cathode",
          "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dpp"
        }
      ]
    }
  ]
}
```

**Key observations:** Uses `MakeEvent` (replacing the old `TransformationEvent`). `inputProduct` lists materials consumed with disposition "consumed"; `outputProduct` lists materials created with disposition "new". `madeAtFacility` identifies where the production occurred. The input-to-output ratio (30t concentrate → 10t cathode at 30% Cu grade) provides the mass balance data an auditor needs to verify material conservation. `relatedDocument` links to the output product's DPP and the facility's DCC.

### Example 5: DCC for Independent Mass Balance Assurance

**Purpose:** Verified conformance and assessed performance metrics (accounting analogy: audited accounts)

The DCC is issued by an independent auditor after verifying the facility's material accounting. It communicates assessed conformance and performance metrics WITHOUT revealing commercially sensitive stock and flow data.

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.7.0/context/"
  ],
  "type": ["DigitalConformityCredential", "VerifiableCredential"],
  "id": "https://credentials.sample-cab.example.com/dcc/smelter-002",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-cab.example.com",
    "name": "Sample Conformity Assessment Body"
  },
  "validFrom": "2025-01-15T00:00:00Z",
  "validUntil": "2028-01-15T00:00:00Z",
  "name": "Responsible Metals Certification — Sample Copper Refinery",
  "credentialSubject": {
    "type": ["ConformityAttestation"],
    "id": "https://sample-cab.example.com/attestation/RM-2025-002",
    "name": "Responsible Metals Scheme Certificate — Sample Refinery",
    "assessorLevel": "3rdParty",
    "assessmentLevel": "authority-benchmark",
    "attestationType": "certification",
    "issuedToParty": {
      "id": "did:web:sample-refinery.example.com",
      "name": "Sample Copper Refinery Co. Ltd"
    },
    "referenceScheme": {
      "id": "https://responsible-metals-scheme.example.org",
      "name": "Sample Responsible Metals Scheme"
    },
    "referenceProfile": {
      "id": "https://responsible-metals-scheme.example.org/rra/v3.0",
      "name": "Responsible Metals Risk Assessment v3.0"
    },
    "authorisation": [
      {
        "name": "Accreditation as Approved Assessment Firm",
        "issuingAuthority": {
          "id": "https://responsible-metals-scheme.example.org",
          "name": "Sample Responsible Metals Authority"
        }
      }
    ],
    "conformityAssessment": [
      {
        "type": ["ConformityAssessment"],
        "id": "https://sample-cab.example.com/assessment/RM-2025-002-GHG",
        "name": "GHG Emissions Assessment",
        "assessmentDate": "2025-01-12",
        "conformance": true,
        "conformityTopic": {
          "type": ["ConformityTopic"],
          "id": "https://vocabulary.uncefact.org/conformity-topic/greenhouse-gas-emissions",
          "name": "Greenhouse Gas Emissions"
        },
        "assessedPerformance": [
          {
            "metric": {
              "id": "https://vocabulary.uncefact.org/performance-metric/scope-1-ghg-emissions",
              "name": "Scope 1 GHG Emissions"
            },
            "measure": { "value": 120000, "unit": "TNE" }
          }
        ],
        "assessedFacility": [
          {
            "facility": {
              "id": "https://facility-register.example.com/fac-002",
              "name": "Sample Copper Refinery"
            },
            "idVerifiedByCAB": true
          }
        ],
        "assessedOrganisation": {
          "id": "did:web:sample-refinery.example.com",
          "name": "Sample Copper Refinery Co. Ltd"
        }
      },
      {
        "type": ["ConformityAssessment"],
        "id": "https://sample-cab.example.com/assessment/RM-2025-002-WM",
        "name": "Waste Management Assessment",
        "assessmentDate": "2025-01-12",
        "conformance": true,
        "conformityTopic": {
          "type": ["ConformityTopic"],
          "id": "https://vocabulary.uncefact.org/conformity-topic/waste-minimization",
          "name": "Waste Minimization"
        },
        "assessedPerformance": [
          {
            "metric": {
              "id": "https://vocabulary.uncefact.org/performance-metric/waste-diversion-rate",
              "name": "Waste Diversion Rate"
            },
            "measure": { "value": 78, "unit": "P1" }
          }
        ],
        "assessedFacility": [
          {
            "facility": {
              "id": "https://facility-register.example.com/fac-002",
              "name": "Sample Copper Refinery"
            },
            "idVerifiedByCAB": true
          }
        ]
      }
    ]
  }
}
```

**Key observations:**
- Uses `ConformityAttestation` as the credential subject (not `Attestation`)
- Uses `conformityAssessment` array (not `assessment`)
- Uses `assessedPerformance` with metric references from the UNTP performance metrics vocabulary (not `declaredValue`/`assessmentCriteria`)
- Includes `assessmentLevel` ("authority-benchmark") and `authorisation` chain linking to the scheme authority
- Each assessment has `assessedFacility` with `idVerifiedByCAB: true` confirming the auditor verified facility identity
- Hides commercially sensitive information (stock levels, flow quantities, supplier identities) while providing verified performance metrics
- Downstream buyers can use the `conformityTopic` and `assessedPerformance` to match against corresponding `performanceClaim` entries in DPPs and DFRs

---

## Transparency Graphs

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview

A transparency graph is a digital twin of your value chain. It comprises a set of facilities (eg manufacturing plants, mine-sites, farms, etc) linked by the exchange of products and materials. The output products and materials of one facility are the input of others, building a "graph" of relationships that represents your supply chain. Each facility and product carries conformity claims — product safety, carbon footprint, waste management, labour rights — some backed by independent assessments that add trust.

![Transparency graphs](CriticalMineralsTransparencyGraph.png)

The illustration above shows a simplified critical minerals to electric vehicle / data centre transparency graph. Each facility transforms input products and materials to make outputs that are shipped to the next facility. It also shows (in green) how UNTP works across sectors with the example of leather as an agricultural by-product making its way into automotive upholstery. In the real world, your graph will be much larger and more dynamic — most facilities have many more suppliers and customers than can be shown here. This is a key reason why all this must be digitalised if it is to work at scale.

This page explains the challenges that transparency graphs address, the UNTP solution for building and verifying them, and examples of graph verification in practice.

## Challenges

Verifying a single credential proves that it hasn't been tampered with and was issued by the stated issuer. But it says nothing about whether the *graph* of linked claims across many credentials is trustworthy. Real compliance verification requires following chains of evidence across multiple credentials issued by different parties. Below are concrete scenarios that illustrate why graph-level verification matters.

### Issuer Trust

"Is the issuer of this product passport really the producer of this product?" A manufacturer publishes a Digital Product Passport (DPP) claiming low emissions for a battery. But how does a buyer know the DPP was actually issued by the operator of the facility that made the battery? Answering this requires linking the DPP issuer's identity to a facility record and verifying via a Digital Identity Anchor (DIA) from an authoritative business register. No single credential can answer this alone — it requires traversing from DPP to DFR to DIA.

### Accreditation Verification

"Is the Conformity Assessment Body (CAB) that certified this product actually accredited to make this attestation?" A DCC claims that a product meets a sustainability standard, but verifiers need to confirm the issuing CAB holds valid accreditation. This requires following the chain: DCC issuer → DIA from an accreditation authority → trust anchor (e.g. an [ILAC](https://ilac.org/) member). With thousands of CABs worldwide, automated verification of this chain is essential.

### Regulatory Compliance

"Does the farm that produced this beef meet EU deforestation regulation requirements?" Answering this means tracing product origin through Digital Traceability Events (DTEs) back to source facilities, checking facility geo-coordinates against deforestation risk maps, and confirming conformity claims against regulation criteria. The evidence spans DTEs, DFRs, DCCs, and DIAs — all issued by different parties.

### Conflict Minerals and Mass Balance

"Are there conflict minerals in this refined metal, and can the smelter back that up with verifiable mass-balance proof of sourcing?" Verifying this requires following transformation events to trace inputs back to source mines, checking facility locations against conflict zone data, and verifying that input-output mass-balance claims are consistent with auditable evidence. See the [Mass Balance](./MassBalance.md) design pattern for more detail.

### Completeness and Quality

Even when individual credentials verify correctly, the graph may reveal gaps that undermine confidence:

* Where are the gaps in my transparency graph (eg non-participating suppliers) — so I can request that they adopt UNTP and publish credentials?
* Where are there important conformity claims that do not have evidence of reliable independent assessments?
* Where is there an excess of unstructured and unverifiable data that I should push for uplift to UNTP credentials?
* Which parties have not attached verifiable evidence of identity from an authoritative source?
* Which parts of my supply chain include conflict zones or locations at risk of political disruption?

In essence, there are an almost unlimited number of business rules for which automated verification requires cryptographically verifiable links between data in many credentials. This is what transparency graphs enable — a compliance and risk assessment tool that allows organisations to focus their limited resources on the parts that matter.

## Solution

UNTP solves these challenges through three capabilities: **discovering** credentials across the value chain, **building** a linked-data graph from their contents, and **verifying** the graph against business rules.

### Discovering Credentials

The approach to finding the UNTP credentials that carry the information for the transparency graph is simply stated — **just follow the product and facility identifiers** to find relevant UNTP credentials like Product Passports (DPP), Facility Records (DFR), Conformity Credentials (DCC), and Traceability Events (DTE).

The core mechanism for building a transparency graph is a simple recursive process: **find an identifier, resolve it to credentials, extract new identifiers from those credentials, and repeat**. The technical details are described in the [Identity Resolver](../specification/IdentityResolver.md) specification but the essence is straightforward:

1. **Find an identifier** — a barcode on a box, a QR code, or an ID in a document. Any identifier can be turned into a URL that points to an [identity resolver](../specification/IdentityResolver.md).
2. **Resolve to credentials** — the resolver returns a list of available data about the identified thing, including UNTP credentials.
3. **Extract linked identifiers** — each credential contains identifiers of related entities (facilities, products, parties, schemes). These become the starting point for the next resolution cycle.
4. **Repeat** — follow each new identifier to discover more credentials, progressively building out the graph.

This process is independent of identifier scheme (GS1, national registers, DIDs) and works the same way for all four UNTP credential types:

| Credential | Description | Key identifiers to follow |
|---|---|---|
| [Digital Product Passport (DPP)](../specification/DigitalProductPassport.md) | Product/material claims issued by the manufacturer | Facility ID (where produced), material/component IDs |
| [Digital Facility Record (DFR)](../specification/DigitalFacilityRecord.md) | Facility performance claims issued by the operator | Party ID (operator), scheme IDs (conformity schemes) |
| [Digital Conformity Credential (DCC)](../specification/ConformityCredential.md) | Independent assessments issued by a conformity assessment body | Product/facility IDs (assessed subjects), party ID (assessor) |
| [Digital Traceability Event (DTE)](../specification/DigitalTraceabilityEvents.md) | Process events (transformation, shipment, repair) linking inputs to outputs | Input product/material IDs, source/destination facility IDs |

The DTE is particularly important for graph construction because it **links** supply chain tiers — a transformation event lists the input materials consumed to produce an output product, allowing the graph to be traced upstream through successive production steps. Because DTEs reveal upstream supply information, they can be commercially sensitive. The [Different Digital Maturities](./DigitalMaturities.md) design pattern describes ways to handle upstream supplier confidentiality.

### Building the Graph

Having discovered a bunch of credentials that describe your value chain as described in previous sections, the next step is to use them to create your linked-data transparency graph as a digital twin of your value chain. In reality this is an ongoing process as new or updated credentials are found, they are added to the graph.

UNTP is designed with this task front-of-mind so it is actually very simple. Every UNTP credential is built using JSON-LD (the "LD" stands for "Linked Data") so the credentials are already natively graph ready. Just load them to your preferred graph database and the linked data model will emerge.

#### Entity linking model

One very important concept to grasp is that the transparency graph is not a graph of linked credentials like DPPs and DCCs. It is a linked-data graph of the identified entities found **inside** the credentials. So, in the diagram below, the graph is created from the entities (dark blue ellipses) and relationships between them. The UNTP credentials are just containers for these entities and are shown as lighter coloured shading around the key entities. Please note that the diagram below is a conceptual model designed to facilitate understanding, not a rigorous UNTP ontology, which is a little more complex.

![UNTP meta-model](Graphs-metamodel.png)

The diagram illustrates many of the key ideas in UNTP. For example:

* That **products** are made at **facilities** and assert a number of performance **claims** which are made against **criteria** defined by recognised conformity **schemes**.
* That an **attestation** is issued by an authorised **party** and includes a number of conformity **assessments** about either **products** or **facilities**. The **assessments** are also made against **criteria** defined by authoritative **schemes** that depend on recognised **standards**.
* That all **parties** have one or more authoritative registered **identities** governed by a registrar such as a national business register.
* That a manufacturing or service **process** happens at a **facility** and may consume input **products** to create output **products**.

These are the types of entities and relationships that will appear in your transparency graph when you load UNTP credentials.

#### Loading credentials to the graph

As stated earlier, UNTP credentials are graph-ready by design so loading them into your graph database is simple. That's because every entity that will become a node on the graph always has a "type" (from a controlled UNTP list — like "assessment"), a globally unique "id", and a human readable "name". And the entity will always be in a context that defines its relationship to other entities.

This is best explained via a small snippet of a UNTP digital facility record credential.

```
...
"facility": {
      "type": ["Facility"],
      "id": "https://someregistrar.com/facility/9468240000012",
      "name": "Copper Mine 7",
      "registeredId": "9468240000012",
      "idScheme": {
        "type": ["IdentifierScheme"],
        "id": "https://facilities.someregister.com",
        "name": "Global Facility Number"
        }
      },
      "conformityClaim": [
         {
           "type": ["Claim"],
           "id": "https://somefacility.com/claims/ABC12345",
           "name":"environmental mgt system",
           "assessmentDate": "2025-07-15",
           "assessmentCriteria": [
             {
               "type": ["Criterion"],
               "id": "https://some-conformity-scheme/criteria/ems-2017",
               "name": "EMS Standard 2017",
               "description": "Participants shall minimize environmental impact through compliance with regulations, effective management of resources, and reduction of emissions and waste.",
               "conformityTopic": "environment",
               "status": "active"
             }
             ],
           "conformance": true
         }
        ]
...
```
There are four typed entities in the snippet and so it would create four nodes in a graph with defined relationships between them:

* A **facility** node with ID `https://someregistrar.com/facility/9468240000012` and name `Copper Mine 7`. The facility has two relationships:
  * an `idScheme` relationship to an **identifierScheme** node with ID `https://facilities.someregister.com` and name `Global Facility Number`
  * a `conformityClaim` relationship to a **claim** node with ID `https://somefacility.com/claims/ABC12345` and name `environmental mgt system`
* The **claim** would also have an `assessmentCriteria` relationship to a **Criterion** node with id `https://some-conformity-scheme/criteria/ems-2017` and name `EMS Standard 2017`

Which might render on your graph something like this

![graph sample snippet](Graphs-SampleSnippet.png)

The more credentials you add to your graph, the more it starts to provide a meaningful digital twin of your real supply chain. Since all UNTP data is digital and graph native, the entire process of discovery, load and analyse can be automated.

A couple of important notes:

* Often a credential will contain an entity that is already a node in the graph. For example you load a DFR, which creates a facility node (eg with id `https://someregister/facilities/5558880000030`). Then you upload a DPP that has a "producedAtFacility" property which is of type facility and has the same id `https://someregister/facilities/5558880000030`. In this case of course you do not create a new facility, you just create a link from the "product" node to the "facility" node with name "producedAtFacility".
* Sometimes a relatively empty new node is created — for example because you find a "assessedFacility" in the "assessment" object of a DCC — so you create a new node with that facility id (assuming it doesn't exist already). Then later on you find a DFR for that same facility. In this case you have new data about an existing node — so you create a new relationship AND update that existing node with all the new data.

So the general rule is — when you find a typed and identified entity anywhere in a credential:

1. If the entity does not already exist, create it.
2. If the entity already exists, add any new properties.
3. Create a link from the containing entity to the referenced entity using the property name of the contained entity.

All this means that no dedicated code is needed to process each version of each UNTP credential. They can just be uploaded to the graph with the same simple logic.

### Verifying the Graph

Although transparency graphs are constructed from data in verifiable credentials, it does not follow that if every individual credential is valid then the graph is verified.

#### Trust chains

Consider the scenario where GHG emissions of a product result in a carbon border adjustment that must be paid. In such cases, the potential for fraud is significant, as some manufacturers might falsely claim low GHG emissions in their digital product passport. To combat this, verifiers must be able to construct a **chain of trust**. For example

* A manufacturer issues a declaration in a UNTP Digital Product Passport (DPP) that states an emissions footprint for a given product ID. If the verifier trusts the manufacturer then this may be sufficient. But often a third party attestation is needed.
* A third party Conformity Assessment Body (CAB) issues an attestation as a UNTP Digital Conformity Credential (DCC) about the same product ID that confirms the emissions footprint. If the verifier knows and trusts the CAB then this may be sufficient. But there are thousands of CABs and so it is very possible that the verifier does not know or trust the specific CAB.
* A national accreditation authority issues an endorsement as a UNTP Digital Identity Anchor (DIA) which states that the CAB is accredited to issue certifications under a recognised scheme such as the [GHG Protocol](https://ghgprotocol.org/). The number of accreditation authorities is only a little larger than the number of countries, so verifiers only need a short list of accreditation authorities ("trust anchors") in order to trust the chain from product manufacturer -> CAB -> national authority.
* Most national accreditation authorities are members of a global association such as [ILAC](https://ilac.org/). If ILAC were to issue a credential attesting that national authority is a member then there is a chain of trust from manufacturer -> CAB -> national authority -> ILAC.

Ultimately, verifiers need only maintain a very short list of ultimate **trust anchors**. In general, all these actors in the trust chain already exist and have well managed governance frameworks. The verifiable credential and transparency graph technologies are not creating new trust models, they are just making existing ones digital and verifiable at scale.

#### Validation rule tiers

The validation rules for a given transparency graph that represents a specific actor's value chain are of course up to the specific actor. However there is likely to be a tiered set of re-usable rules that would make life easier for each actor.

* **UNTP core validation rules.** There is a core subset of rules (eg that claims are verified by assessments, that identities are anchored, etc) that will be common to all industry sectors and all geographies.
* **Industry specific rules.** On top of the UNTP core rules, there will be industry specific rules that apply to specific [UNTP extensions](../tools-and-support/ExtensionsMethodology.md) such as which specific sustainability schemes are trusted, what identity schemes and anchors are preferred, etc.
* **Geography specific rules.** As well as industry level common rules, there will be geography specific rules that will typically map to national regulations. These could usefully be defined consistently by each regulator.
* **Organisation specific rules.** Finally there will be rules that reflect the specific requirements of individual organisations.

UNTP and extensions will make these validation rules public and re-usable so that specific implementers need only consider whether they wish to add any organisation specific rules.

## Examples

### Trust Chain Verification

Consider verifying a GHG emissions claim on a battery Digital Product Passport. A border authority receives a battery shipment and needs to verify the claimed carbon footprint of 45 kg CO2e per kWh. The graph-level verification proceeds as follows:

1. **Resolve the battery DPP** — The battery identifier resolves to a DPP issued by the battery manufacturer, containing the emissions claim.
2. **Find the supporting DCC** — The DPP references (or the identity resolver returns) a DCC issued by a CAB that assessed the emissions footprint and confirmed the 45 kg CO2e figure.
3. **Verify CAB accreditation** — The CAB's identifier resolves to a DIA issued by the national accreditation authority, confirming the CAB is accredited under the [GHG Protocol](https://ghgprotocol.org/) scheme.
4. **Check the trust anchor** — The national accreditation authority is on the verifier's list of trusted anchors (or is attested as an [ILAC](https://ilac.org/) member).

This chain — DPP → DCC → DIA → trust anchor — addresses the [issuer trust](#issuer-trust) and [accreditation verification](#accreditation-verification) challenges described above. If any link in the chain is missing or invalid, the graph verification flags it for human review.

### Graph Validation Rules

The following pseudo-code illustrates the kind of rules that can be applied to a transparency graph. These are indicative examples — actual rule definitions will be formalised as UNTP matures.

```
# UNTP Core Rules

FOR each Product with conformityClaims
  CHECK that at least one matching DCC assessment exists
    for the same product ID and conformity topic
  FLAG "unverified claim" if no matching assessment found

FOR each DCC issuer (ConformityAssessmentBody)
  CHECK that a DIA exists confirming accreditation
    issued by a recognised accreditation authority
  FLAG "unaccredited assessor" if no DIA found

FOR each Facility operator (Party)
  CHECK that a DIA exists anchoring the party identity
    issued by an authoritative business register
  FLAG "unanchored identity" if no DIA found

FOR each transformation DTE
  CHECK that input product quantities and output product quantities
    are consistent within acceptable mass-balance tolerances
  FLAG "mass-balance inconsistency" if tolerance exceeded

# Industry Extension Rules (example: critical minerals)

FOR each Facility with conformityTopic = "mineral sourcing"
  CHECK that facility geoLocation is not within
    a designated conflict zone
  FLAG "conflict zone risk" if location matches

# Geography Specific Rules (example: EU CBAM)

FOR each imported Product with conformityTopic = "emissions"
  CHECK that emissions claim value exists AND
    a matching DCC assessment with scheme = "GHG Protocol" exists
  FLAG "CBAM non-compliant" if missing
```

---

## Variant-based Disclosure

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

:::note Terminology Note
This guidance describes a variant-based approach where different actors receive different complete documents (Digital Product Passports, Digital Facility Records) based on their access role. This is distinct from cryptographic selective disclosure mechanisms in the W3C Verifiable Credentials ecosystem (such as BBS+ signatures or SD-JWT), which enable selective disclosure within a single credential using cryptographic techniques. The UNTP approach uses Identity Resolver routing and role-based access control rather than cryptographic selective disclosure.
:::

Variant-based disclosure extends UNTP [Digital Product Passports](../specification/DigitalProductPassport.md) (DPP) and [Digital Facility Records](../specification/DigitalFacilityRecord.md) (DFR) to support variant-based disclosure at the individual claim level. This enables different actors in the value chain to access different subsets of credential information based on their role, while maintaining a standards-based approach with minimal complexity.

Variant-based disclosure builds on the existing UNTP [Decentralised Access Control](../specification/DecentralisedAccessControl.md) pattern and enables granularity at the claim level rather than the entire credential level.

## Challenges

The UNTP [Decentralised Access Control](../specification/DecentralisedAccessControl.md) specification operates at the entire credential payload level — a party either has access to a credential or they don't. In practice, different actors need access to different claim-level information within the same credential:

### Digital Product Passport use cases

- **Public claims** (e.g., recycling instructions) available to all stakeholders
- **Customer-specific claims** (e.g., warranty information) available only to product purchasers
- **Regulatory claims** (e.g., detailed emissions data) available only to competent authorities
- **Recycler claims** (e.g., hazardous material details) available only to accredited recycling facilities

### Digital Facility Record use cases

- **Public claims** (e.g., facility location, basic certifications) available to all stakeholders
- **Customer-specific** claims (e.g., capacity, lead times) available only to business partners
- **Regulatory claims** (e.g., worker safety records, environmental compliance) available only to competent authorities
- **Audit claims** (e.g., detailed sustainability metrics) available only to authorized auditors

## Design Principles

- **Minimal Changes**: Extend existing structures rather than introduce new patterns
- **Backwards Compatible**: Existing credential verifiers continue to work
- **Resolver-Centric**: [Identity Resolver](../specification/IdentityResolver.md) handles routing; credentials remain static blobs
- **Discoverability**: Users can see what additional data exists and how to access it
- **Standards-Aligned**: Builds on existing UNTP link types and access control patterns
- **Credential Agnostic**: Same pattern works for [DPP](../specification/DigitalProductPassport.md), [DFR](../specification/DigitalFacilityRecord.md), and future UNTP credentials

## Conceptual Model

The variant-based disclosure model introduces document variants that enable role-based access to claims while maintaining discoverability through the [Identity Resolver](../specification/IdentityResolver.md).

### Architecture Flow

1. **[Identity Resolver](../specification/IdentityResolver.md)** receives a query with an optional `accessRole` parameter
2. Based on the `accessRole`, the resolver returns a linkset containing the appropriate document variant(s)
3. Each **document variant** is a complete, valid credential containing:
   - **Basic claims** accessible to the specified role
   - **Claim stubs** (without `declaredValue`) indicating claims available in other variants
   - **`otherVariants` metadata** listing other available access roles

### Example Variant Structure

**Public Variant:**
- Contains basic claims accessible to all stakeholders
- Includes claim stubs for restricted claims (emissions, warranty, hazmat)
- Lists other available variants (Customer, Regulator, Recycler)

**Regulator Variant:**
- Contains basic claims plus regulatory-specific claims (emissions data, supply chain provenance)
- Includes claim stubs for role-specific claims (warranty for Customers, hazmat for Recyclers)
- Lists other available variants for discovery

### Key Concepts

- **Document Variant**: A complete, valid credential containing a subset of claims for a specific access role
- **Claim Stub**: A claim entry without `declaredValue`, indicating the claim exists in another variant
- **`otherVariants`**: Metadata property listing other available document variants
- **`accessRole`**: Query parameter and property indicating required access level
- **[Identity Resolver](../specification/IdentityResolver.md)**: Routes requests to appropriate variant based on access role

## Requirements

| ID    | Name                     | Requirement Statement                                                                                                                                    | Solution Mapping                                                                        |
| ----- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| VD-01 | Claim-level granularity  | Different actors SHALL be able to access different claims within the same credential based on their role                                                 | Multiple document variants with different claims                                        |
| VD-02 | Variant discovery        | A credential recipient SHALL be able to discover that other variants exist for different access roles                                                    | `otherVariants` property in credential subject                                          |
| VD-03 | Claim discovery          | A credential recipient SHALL be able to see which specific claims exist in other variants                                                                | Claim stubs in claims array                                                             |
| VD-04 | Role-based routing       | [Identity Resolver](../specification/IdentityResolver.md) SHALL route requests to appropriate document variant based on `accessRole` parameter           | Enhanced Identity Resolver query parameter                                              |
| VD-05 | Credential type agnostic | Solution SHALL work for both [DPP](../specification/DigitalProductPassport.md) and [DFR](../specification/DigitalFacilityRecord.md) without modification | Generic pattern applicable to any credential with claims                                |
| VD-06 | Backwards compatibility  | Existing credential verifiers MUST continue to function without modification                                                                             | Extensions are optional; base structures unchanged                                      |
| VD-07 | Minimal complexity       | Solution SHALL NOT require cryptographic selective disclosure or complex application logic                                                               | Uses static files and [Identity Resolver](../specification/IdentityResolver.md) routing |
| VD-08 | Access indication        | Each claim or variant SHALL clearly indicate which access role is required                                                                               | `accessRole` property on claims and variants                                            |

## Specification

The following extensions to UNTP credentials, [Identity Resolver](../specification/IdentityResolver.md), and related specifications are defined:

### Extension 1: Identity Resolver Query Parameter

The [Identity Resolver](../specification/IdentityResolver.md) SHALL support an optional `accessRole` query parameter for both product and facility identifiers:

```
GET /01/{productId}?accessRole={roleURI}
GET /99/{facilityId}?accessRole={roleURI}
```

**Without `accessRole` parameter:**

Resolver returns linkset with all available document variants, allowing discovery.

**With `accessRole` parameter:**

Resolver returns linkset with only the document variant(s) matching that role.

### Extension 2: Credential Variant Metadata

Add an optional `otherVariants` property to the credential subject (`ProductPassport` or `FacilityRecord`) to indicate other document variants are available:

```json
{
  "credentialSubject": {
    "type": ["ProductPassport"],
    "id": "https://example.com/products/90664869327",
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "accessRole": ["untp:accessRole#Regulator"]
      }
    ],
    "product": {...},
    "conformityClaim": [...]
  }
}
```

Or for a facility:

```json
{
  "credentialSubject": {
    "type": ["FacilityRecord"],
    "id": "https://example.com/facilities/F123456",
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "accessRole": ["untp:accessRole#Auditor"]
      }
    ],
    "facility": {...},
    "conformityClaim": [...]
  }
}
```

**Properties:**

- **`otherVariants`** (OPTIONAL): Array of objects indicating other document variants exist
- **`accessRole`** (REQUIRED): Array of URIs indicating which role can access the variant

### Extension 3: Claim Stubs for Discovery

A claim in the claims array (e.g., `conformityClaim`, `sustainabilityClaim`) MAY be a stub indicating the claim exists in another variant but is not included in the current credential.

A claim stub is distinguished by the absence of the `declaredValue` property combined with the presence of an `accessRole` property.

```json
{
  "conformityClaim": [
    {
      "id": "https://example.com/claims/emissions-001",
      "conformityTopic": "environment.emissions",
      "description": "Carbon footprint assessment",
      "accessRole": ["untp:accessRole#Regulator"]
    }
  ]
}
```

**Claim Stub Properties:**

- **`id`** (REQUIRED): Unique identifier for the claim
- **`conformityTopic`** (REQUIRED): Classification of the claim
- **`description`** (OPTIONAL): Human-readable description
- **`accessRole`** (REQUIRED for stubs): Array of URIs indicating required access level
- **`declaredValue`** (ABSENT): No value data; this is the key indicator it's a stub

**Full Claim Properties:**

Same as stub, PLUS:

- **`declaredValue`** (REQUIRED): Array of metric values
- **`accessRole`** (OPTIONAL): If present, indicates this claim has access restrictions

## Implementation Guidance

The following examples demonstrate variant-based disclosure for both [Digital Product Passports](../specification/DigitalProductPassport.md) and [Digital Facility Records](../specification/DigitalFacilityRecord.md).

### Identity Resolver Behavior

The [Identity Resolver](../specification/IdentityResolver.md) behavior is identical for both product and facility identifiers.

#### Scenario 1: Query Without Access Role

**Request (Product):**

```http
GET /01/90664869327
Host: resolver.example.com
```

**Request (Facility):**

```http
GET /99/F123456
Host: resolver.example.com
```

**Response (Product):**

```json
{
  "linkset": [{
    "anchor": "https://resolver.example.com/01/90664869327",
    "https://vocabulary.uncefact.org/untp/linkType#digitalProductPassport": [
      {
        "href": "https://files.example.com/dpp/90664869327-public.json",
        "accessRole": ["untp:accessRole#Anonymous"]
      },
      {
        "href": "https://files.example.com/dpp/90664869327-customer.json",
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "href": "https://files.example.com/dpp/90664869327-regulator.json",
        "accessRole": ["untp:accessRole#Regulator"]
      }
    ]
  }]
}
```

**Response (Facility):**

```json
{
  "linkset": [{
    "anchor": "https://resolver.example.com/99/F123456",
    "https://vocabulary.uncefact.org/untp/linkType#digitalFacilityRecord": [
      {
        "href": "https://files.example.com/dfr/F123456-public.json",
        "accessRole": ["untp:accessRole#Anonymous"]
      },
      {
        "href": "https://files.example.com/dfr/F123456-customer.json",
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "href": "https://files.example.com/dfr/F123456-auditor.json",
        "accessRole": ["untp:accessRole#Auditor"]
      }
    ]
  }]
}
```

The resolver returns all available variants, allowing the requestor to discover what access levels exist.

#### Scenario 2: Query With Access Role

**Request (Product):**

```http
GET /01/90664869327?accessRole=untp:accessRole%23Customer
Host: resolver.example.com
```

**Request (Facility):**

```http
GET /99/F123456?accessRole=untp:accessRole%23Auditor
Host: resolver.example.com
```

**Response (Product):**

```json
{
  "linkset": [{
    "anchor": "https://resolver.example.com/01/90664869327",
    "https://vocabulary.uncefact.org/untp/linkType#digitalProductPassport": [{
      "href": "https://files.example.com/dpp/90664869327-customer.json",
      "accessRole": ["untp:accessRole#Customer"]
    }]
  }]
}
```

**Response (Facility):**

```json
{
  "linkset": [{
    "anchor": "https://resolver.example.com/99/F123456",
    "https://vocabulary.uncefact.org/untp/linkType#digitalFacilityRecord": [{
      "href": "https://files.example.com/dfr/F123456-auditor.json",
      "accessRole": ["untp:accessRole#Auditor"]
    }]
  }]
}
```

The resolver returns only the variant(s) matching the requested access role.

### Credential Structure Examples

The following examples demonstrate variant-based disclosure for both [Digital Product Passports](../specification/DigitalProductPassport.md) and [Digital Facility Records](../specification/DigitalFacilityRecord.md).

## Digital Product Passport Examples

### Example DPP-1: Public Variant

The public variant contains only claims with `accessRole#Anonymous` or no access restrictions. It includes:

- Full claims for public data
- `otherVariants` array showing other access levels exist
- Claim stubs for restricted claims

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dpp/0.7.0/"
  ],
  "type": ["DigitalProductPassport", "VerifiableCredential"],
  "issuer": {
    "id": "did:web:manufacturer.example.com",
    "name": "Battery Manufacturer Inc"
  },
  "credentialSubject": {
    "type": ["ProductPassport"],
    "id": "https://example.com/products/90664869327",
    
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "accessRole": ["untp:accessRole#Regulator"]
      },
      {
        "accessRole": ["untp:accessRole#Recycler"]
      }
    ],
    
    "product": {
      "id": "https://example.com/products/90664869327",
      "name": "Lithium Battery Pack",
      "registeredId": "90664869327",
      "description": "High-capacity lithium battery for electric vehicles"
    },
    
    "conformityClaim": [
      {
        "id": "https://example.com/claims/recycling-001",
        "conformityTopic": "environment.recycling",
        "description": "Recycling instructions and material composition",
        "declaredValue": [
          {
            "metricName": "Recyclable Content",
            "metricValue": {
              "value": 95,
              "unit": "P1"
            }
          }
        ],
        "conformityEvidence": {
          "type": ["Link"],
          "linkURL": "https://example.com/recycling-instructions.pdf",
          "linkType": "https://vocabulary.uncefact.org/untp/linkType#instruction"
        }
      },
      {
        "id": "https://example.com/claims/emissions-001",
        "conformityTopic": "environment.emissions",
        "description": "Carbon footprint assessment per GBA Rulebook",
        "accessRole": ["untp:accessRole#Regulator"]
      },
      {
        "id": "https://example.com/claims/warranty-001",
        "conformityTopic": "governance.warranty",
        "description": "Product warranty terms and conditions",
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "id": "https://example.com/claims/hazmat-001",
        "conformityTopic": "environment.hazmat",
        "description": "Hazardous materials declaration for safe recycling",
        "accessRole": ["untp:accessRole#Recycler"]
      }
    ],
    
    "circularityScorecard": {
      "recyclableContent": 0.95,
      "recycledContent": 0.3
    }
  }
}
```

**Key Points:**

- Contains 1 full claim (recycling)
- Contains 3 claim stubs (emissions, warranty, hazmat)
- `otherVariants` shows 3 additional access levels exist
- Verifiers can display: "Additional information available for Customers, Regulators, and Recyclers"

### Example DPP-2: Customer Variant

The customer variant adds warranty information to the public claims:

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dpp/0.7.0/"
  ],
  "type": ["DigitalProductPassport", "VerifiableCredential"],
  "issuer": {
    "id": "did:web:manufacturer.example.com",
    "name": "Battery Manufacturer Inc"
  },
  "credentialSubject": {
    "type": ["ProductPassport"],
    "id": "https://example.com/products/90664869327",
    
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Anonymous"]
      },
      {
        "accessRole": ["untp:accessRole#Regulator"]
      },
      {
        "accessRole": ["untp:accessRole#Recycler"]
      }
    ],
    
    "product": {
      "id": "https://example.com/products/90664869327",
      "name": "Lithium Battery Pack",
      "registeredId": "90664869327",
      "description": "High-capacity lithium battery for electric vehicles"
    },
    
    "conformityClaim": [
      {
        "id": "https://example.com/claims/recycling-001",
        "conformityTopic": "environment.recycling",
        "description": "Recycling instructions and material composition",
        "declaredValue": [
          {
            "metricName": "Recyclable Content",
            "metricValue": {
              "value": 95,
              "unit": "P1"
            }
          }
        ]
      },
      {
        "id": "https://example.com/claims/warranty-001",
        "conformityTopic": "governance.warranty",
        "description": "Product warranty terms and conditions",
        "declaredValue": [
          {
            "metricName": "Warranty Period",
            "metricValue": {
              "value": 5,
              "unit": "ANN"
            }
          },
          {
            "metricName": "Warranty Coverage",
            "metricValue": {
              "value": 100000,
              "unit": "KMT"
            }
          }
        ],
        "conformityEvidence": {
          "type": ["Link"],
          "linkURL": "https://example.com/warranty-certificate.pdf",
          "linkType": "https://vocabulary.uncefact.org/untp/linkType#certification"
        }
      },
      {
        "id": "https://example.com/claims/emissions-001",
        "conformityTopic": "environment.emissions",
        "description": "Carbon footprint assessment per GBA Rulebook",
        "accessRole": ["untp:accessRole#Regulator"]
      },
      {
        "id": "https://example.com/claims/hazmat-001",
        "conformityTopic": "environment.hazmat",
        "description": "Hazardous materials declaration for safe recycling",
        "accessRole": ["untp:accessRole#Recycler"]
      }
    ],
    
    "circularityScorecard": {
      "recyclableContent": 0.95,
      "recycledContent": 0.3
    }
  }
}
```

**Key Points:**

- Contains 2 full claims (recycling + warranty)
- Contains 2 claim stubs (emissions, hazmat)
- Customer sees warranty data that public users don't
- Still advertises other variants exist

### Example DPP-3: Regulator Variant

The regulator variant includes detailed emissions and supply chain data:

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dpp/0.7.0/"
  ],
  "type": ["DigitalProductPassport", "VerifiableCredential"],
  "issuer": {
    "id": "did:web:manufacturer.example.com",
    "name": "Battery Manufacturer Inc"
  },
  "credentialSubject": {
    "type": ["ProductPassport"],
    "id": "https://example.com/products/90664869327",
    
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Anonymous"]
      },
      {
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "accessRole": ["untp:accessRole#Recycler"]
      }
    ],
    
    "product": {
      "id": "https://example.com/products/90664869327",
      "name": "Lithium Battery Pack",
      "registeredId": "90664869327",
      "description": "High-capacity lithium battery for electric vehicles"
    },
    
    "conformityClaim": [
      {
        "id": "https://example.com/claims/recycling-001",
        "conformityTopic": "environment.recycling",
        "description": "Recycling instructions and material composition",
        "declaredValue": [
          {
            "metricName": "Recyclable Content",
            "metricValue": {
              "value": 95,
              "unit": "P1"
            }
          }
        ]
      },
      {
        "id": "https://example.com/claims/emissions-001",
        "conformityTopic": "environment.emissions",
        "description": "Carbon footprint assessment per GBA Rulebook",
        "referenceStandard": {
          "type": ["Standard"],
          "id": "https://www.globalbattery.org/media/publications/gba-rulebook-v2.0-master.pdf",
          "name": "GBA Battery Passport Greenhouse Gas Rulebook - V.2.0"
        },
        "declaredValue": [
          {
            "metricName": "GHG Emissions Intensity",
            "metricValue": {
              "value": 12.5,
              "unit": "KGM"
            },
            "accuracy": 0.05
          }
        ],
        "conformityEvidence": {
          "type": ["SecureLink", "Link"],
          "linkURL": "https://example.com/evidence/emissions-attestation.json",
          "linkType": "https://vocabulary.uncefact.org/untp/linkType#dcc",
          "hashDigest": "6239119dda5bd4c8a6ffb832fe16feaa5c27b7dba154d24c53d4470a2c69adc2",
          "hashMethod": "SHA-256"
        }
      },
      {
        "id": "https://example.com/claims/provenance-001",
        "conformityTopic": "materials.provenance",
        "description": "Supply chain due diligence and material origins",
        "declaredValue": [
          {
            "metricName": "Primary Sourced Data Ratio",
            "metricValue": {
              "value": 0.85,
              "unit": "P1"
            }
          }
        ]
      },
      {
        "id": "https://example.com/claims/warranty-001",
        "conformityTopic": "governance.warranty",
        "description": "Product warranty terms and conditions",
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "id": "https://example.com/claims/hazmat-001",
        "conformityTopic": "environment.hazmat",
        "description": "Hazardous materials declaration for safe recycling",
        "accessRole": ["untp:accessRole#Recycler"]
      }
    ],
    
    "emissionsScorecard": {
      "carbonFootprint": 12.5,
      "declaredUnit": "KGM",
      "operationalScope": "CradleToGate",
      "primarySourcedRatio": 0.85
    },
    
    "circularityScorecard": {
      "recyclableContent": 0.95,
      "recycledContent": 0.3
    }
  }
}
```

**Key Points:**

- Contains 3 full claims (recycling + emissions + provenance)
- Contains 2 claim stubs (warranty, hazmat)
- Includes detailed emissions scorecard
- Regulators see supply chain data that others don't

## Digital Facility Record Examples

### Example DFR-1: Public Variant

The public variant contains basic facility information available to all stakeholders:

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dfr/0.7.0/"
  ],
  "type": ["DigitalFacilityRecord", "VerifiableCredential"],
  "issuer": {
    "id": "did:web:facility.example.com",
    "name": "Battery Manufacturing Facility"
  },
  "credentialSubject": {
    "type": ["FacilityRecord"],
    "id": "https://example.com/facilities/F123456",
    
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "accessRole": ["untp:accessRole#Auditor"]
      },
      {
        "accessRole": ["untp:accessRole#Regulator"]
      }
    ],
    
    "facility": {
      "id": "https://example.com/facilities/F123456",
      "name": "Battery Cell Manufacturing Plant",
      "registeredId": "F123456",
      "description": "High-capacity lithium battery cell production facility",
      "location": {
        "address": "123 Industrial Blvd, Manufacturing District",
        "countryCode": "CN",
        "geoCoordinates": {
          "latitude": 31.2304,
          "longitude": 121.4737
        }
      },
      "operatedBy": {
        "id": "https://business.gov.cn/12345678",
        "name": "Battery Manufacturer Inc"
      }
    },
    
    "conformityClaim": [
      {
        "id": "https://example.com/facilities/F123456/claims/iso-14001",
        "conformityTopic": "environment.management",
        "description": "ISO 14001 Environmental Management certification",
        "declaredValue": [
          {
            "metricName": "Certification Status",
            "metricValue": {
              "value": "Active",
              "unit": "text"
            }
          }
        ],
        "conformityEvidence": {
          "type": ["Link"],
          "linkURL": "https://example.com/certs/iso-14001.pdf",
          "linkType": "https://vocabulary.uncefact.org/untp/linkType#certification"
        }
      },
      {
        "id": "https://example.com/facilities/F123456/claims/capacity",
        "conformityTopic": "production.capacity",
        "description": "Annual production capacity and lead times",
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/safety",
        "conformityTopic": "governance.safety",
        "description": "Worker safety records and incident reports",
        "accessRole": ["untp:accessRole#Regulator"]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/sustainability",
        "conformityTopic": "environment.sustainability",
        "description": "Detailed sustainability metrics and targets",
        "accessRole": ["untp:accessRole#Auditor"]
      }
    ]
  }
}
```

**Key Points:**

- Contains 1 full claim (ISO 14001 certification)
- Contains 3 claim stubs (capacity, safety, sustainability)
- `otherVariants` shows 3 additional access levels exist
- Public can see location and basic certifications
- Facility contact information available to all

### Example DFR-2: Customer Variant

The customer variant adds business-relevant operational information:

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dfr/0.7.0/"
  ],
  "type": ["DigitalFacilityRecord", "VerifiableCredential"],
  "issuer": {
    "id": "did:web:facility.example.com",
    "name": "Battery Manufacturing Facility"
  },
  "credentialSubject": {
    "type": ["FacilityRecord"],
    "id": "https://example.com/facilities/F123456",
    
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Anonymous"]
      },
      {
        "accessRole": ["untp:accessRole#Auditor"]
      },
      {
        "accessRole": ["untp:accessRole#Regulator"]
      }
    ],
    "facility": {
      "id": "https://example.com/facilities/F123456",
      "name": "Battery Cell Manufacturing Plant",
      "registeredId": "F123456",
      "description": "High-capacity lithium battery cell production facility",
      "location": {
        "address": "123 Industrial Blvd, Manufacturing District",
        "countryCode": "CN",
        "geoCoordinates": {
          "latitude": 31.2304,
          "longitude": 121.4737
        }
      }
    },
    "conformityClaim": [
      {
        "id": "https://example.com/facilities/F123456/claims/iso-14001",
        "conformityTopic": "environment.management",
        "description": "ISO 14001 Environmental Management certification",
        "declaredValue": [
          {
            "metricName": "Certification Status",
            "metricValue": {
              "value": "Active",
              "unit": "text"
            }
          }
        ]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/capacity",
        "conformityTopic": "production.capacity",
        "description": "Annual production capacity and lead times",
        "declaredValue": [
          {
            "metricName": "Annual Capacity",
            "metricValue": {
              "value": 5000000,
              "unit": "H87"
            }
          },
          {
            "metricName": "Lead Time",
            "metricValue": {
              "value": 12,
              "unit": "WEE"
            }
          },
          {
            "metricName": "Utilization Rate",
            "metricValue": {
              "value": 85,
              "unit": "P1"
            }
          }
        ]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/safety",
        "conformityTopic": "governance.safety",
        "description": "Worker safety records and incident reports",
        "accessRole": ["untp:accessRole#Regulator"]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/sustainability",
        "conformityTopic": "environment.sustainability",
        "description": "Detailed sustainability metrics and targets",
        "accessRole": ["untp:accessRole#Auditor"]
      }
    ]
  }
}
```

**Key Points:**

- Contains 2 full claims (ISO cert + production capacity)
- Contains 2 claim stubs (safety, sustainability)
- Customers see operational data for supply chain planning
- Production capacity and lead times support procurement decisions

### Example DFR-3: Auditor Variant

The auditor variant includes comprehensive sustainability data:

```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dfr/0.7.0/"
  ],
  "type": ["DigitalFacilityRecord", "VerifiableCredential"],
  "issuer": {
    "id": "did:web:facility.example.com",
    "name": "Battery Manufacturing Facility"
  },
  "credentialSubject": {
    "type": ["FacilityRecord"],
    "id": "https://example.com/facilities/F123456",
    
    "otherVariants": [
      {
        "accessRole": ["untp:accessRole#Anonymous"]
      },
      {
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "accessRole": ["untp:accessRole#Regulator"]
      }
    ],
    
    "facility": {
      "id": "https://example.com/facilities/F123456",
      "name": "Battery Cell Manufacturing Plant",
      "registeredId": "F123456",
      "description": "High-capacity lithium battery cell production facility",
      "location": {
        "address": "123 Industrial Blvd, Manufacturing District",
        "countryCode": "CN",
        "geoCoordinates": {
          "latitude": 31.2304,
          "longitude": 121.4737
        }
      }
    },
    
    "conformityClaim": [
      {
        "id": "https://example.com/facilities/F123456/claims/iso-14001",
        "conformityTopic": "environment.management",
        "description": "ISO 14001 Environmental Management certification",
        "declaredValue": [
          {
            "metricName": "Certification Status",
            "metricValue": {
              "value": "Active",
              "unit": "text"
            }
          }
        ]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/sustainability",
        "conformityTopic": "environment.sustainability",
        "description": "Detailed sustainability metrics and targets",
        "referenceStandard": {
          "type": ["Standard"],
          "id": "https://www.iso.org/standard/70453.html",
          "name": "ISO 14064-1:2018 Greenhouse gases"
        },
        "declaredValue": [
          {
            "metricName": "Scope 1 Emissions",
            "metricValue": {
              "value": 2500,
              "unit": "TNE"
            }
          },
          {
            "metricName": "Scope 2 Emissions",
            "metricValue": {
              "value": 15000,
              "unit": "TNE"
            }
          },
          {
            "metricName": "Renewable Energy Use",
            "metricValue": {
              "value": 45,
              "unit": "P1"
            }
          },
          {
            "metricName": "Water Consumption",
            "metricValue": {
              "value": 500000,
              "unit": "LTR"
            }
          }
        ],
        "conformityEvidence": {
          "type": ["SecureLink", "Link"],
          "linkURL": "https://example.com/evidence/sustainability-audit.json",
          "linkType": "https://vocabulary.uncefact.org/untp/linkType#dcc"
        }
      },
      {
        "id": "https://example.com/facilities/F123456/claims/capacity",
        "conformityTopic": "production.capacity",
        "description": "Annual production capacity and lead times",
        "accessRole": ["untp:accessRole#Customer"]
      },
      {
        "id": "https://example.com/facilities/F123456/claims/safety",
        "conformityTopic": "governance.safety",
        "description": "Worker safety records and incident reports",
        "accessRole": ["untp:accessRole#Regulator"]
      }
    ]
  }
}
```

**Key Points:**

- Contains 2 full claims (ISO cert + sustainability metrics)
- Contains 2 claim stubs (capacity, safety)
- Auditors see detailed environmental performance data
- Includes GHG emissions, renewable energy use, water consumption
- Links to third-party audit evidence

### Claim Reference Extension (Optional)

For cases where a claim needs to point to additional detailed evidence with its own access control:

```json
{
  "conformityClaim": [
    {
      "id": "https://example.com/claims/emissions-001",
      "conformityTopic": "environment.emissions",
      "description": "Carbon footprint summary",
      "declaredValue": [
        {
          "metricName": "GHG Emissions Intensity",
          "metricValue": {
            "value": 12.5,
            "unit": "KGM"
          }
        }
      ],
      "conformityEvidence": {
        "type": ["SecureLink", "Link"],
        "linkURL": "https://example.com/evidence/emissions-detailed.json",
        "linkType": "https://vocabulary.uncefact.org/untp/linkType#dcc",
        "accessRole": ["untp:accessRole#Regulator"]
      }
    }
  ]
}
```

This allows a claim to include:

- Summary data (inline `declaredValue`)
- Reference to detailed evidence (via `conformityEvidence` with `accessRole`)

## Implementation Considerations

### Variant Generation Strategy

Implementers have flexibility in how they generate and store variants for both [DPPs](../specification/DigitalProductPassport.md) and [DFRs](../specification/DigitalFacilityRecord.md):

**Option A: Pre-compute all variants at issuance**

- Generate public, customer, regulator, auditor variants as appropriate
- Store as separate static files
- Fast retrieval, more storage
- Best for high-traffic credentials

**Option B: Dynamic variant generation**

- Store one "full" credential with all claims
- Filter claims based on `accessRole` at query time
- Less storage, more compute
- Best for low-traffic or frequently updated credentials

**Option C: Hybrid**

- Pre-compute common variants (public, customer)
- Generate rare variants on-demand (auditor, inspector)
- Balance storage and compute costs

### Resolver Implementation

The [Identity Resolver](../specification/IdentityResolver.md) needs minimal changes:

- Accept `accessRole` as optional query parameter for all identifier types
- Maintain mapping of identifier → available variants
- Return filtered linkset based on `accessRole`

No authentication required at resolver level; access control can be enforced at storage level via encryption or authentication.

### Storage Patterns

Document variants can be stored in any web-accessible location:

**Digital Product Passport storage example:**

```
https://files.example.com/dpp/90664869327-public.json
https://files.example.com/dpp/90664869327-customer.json
https://files.example.com/dpp/90664869327-regulator.json
https://files.example.com/dpp/90664869327-recycler.json
```

**Digital Facility Record storage example:**

```
https://files.example.com/dfr/F123456-public.json
https://files.example.com/dfr/F123456-customer.json
https://files.example.com/dfr/F123456-auditor.json
https://files.example.com/dfr/F123456-regulator.json
```

Or with encryption for sensitive variants:

```
https://files.example.com/dpp/90664869327-public.json (unencrypted)
https://files.example.com/dpp/90664869327-customer.json.enc (encrypted, key in package)
https://files.example.com/dpp/90664869327-regulator.json (requires DID auth at CDN)
```

### Security Considerations

#### Claim Stub Information Leakage

Claim stubs reveal that certain data exists without revealing the data itself. This is intentional for discoverability but implementers should consider:

- Which claims to include as stubs in public variants
- Whether to include `description` field (may reveal too much)
- Option to omit stubs entirely (no hints about restricted data)

#### Access Role Verification

This proposal does not specify HOW to verify that a requestor has a claimed access role. Implementers can use:

- No verification: Public variants are truly public
- Shared secrets: Key in product packaging (current UNTP pattern)
- DID Authentication: Prove DID ownership and check against whitelist
- Digital Identity Anchor: Present credential proving authorized role

These mechanisms are complementary and can be combined per use case.

## Relation to Other Specifications

### Decentralised Access Control

Variant-based disclosure extends the existing [Decentralised Access Control](../specification/DecentralisedAccessControl.md) specification:

- DAC handles credential-level encryption and key management
- Variant-based disclosure handles variant routing and claim-level discovery
- Both specifications can be used together (encrypted variants with claim stubs)

### Identity Resolver

Variant-based disclosure extends the [Identity Resolver](../specification/IdentityResolver.md) specification:

- Adds optional `accessRole` query parameter for all identifier types
- Adds `accessRole` property to linkset responses
- Maintains existing linkset structure
- Works with product identifiers (01), facility identifiers (99), and future identifier types

### Digital Product Passport

Variant-based disclosure extends the [Digital Product Passport](../specification/DigitalProductPassport.md) specification:

- Adds optional `otherVariants` property to `ProductPassport`
- Adds optional `accessRole` property to claims
- Defines claim stub pattern (no `declaredValue`)
- Maintains existing DPP structure

### Digital Facility Record

Variant-based disclosure extends the [Digital Facility Record](../specification/DigitalFacilityRecord.md) specification:

- Adds optional `otherVariants` property to `FacilityRecord`
- Adds optional `accessRole` property to claims
- Defines claim stub pattern (no `declaredValue`)
- Maintains existing DFR structure

## Conformance

Implementations claiming conformance to variant-based disclosure MUST:

- Support the `accessRole` query parameter in [Identity Resolver](../specification/IdentityResolver.md) implementations
- Correctly interpret `otherVariants` property when present in credentials
- Correctly interpret claim stubs (claims without `declaredValue` property)
- Return appropriate linkset responses based on `accessRole` parameter

Implementations MAY:

- Support all defined access roles or a subset based on use case requirements
- Implement pre-computed variants, dynamic filtering, or hybrid approaches
- Add additional properties to variant metadata for implementation-specific needs

## Appendix A: Complete Example Linksets

### Example Linkset for Digital Product Passport

Example Identity Resolver response for product with multiple variants:

```json
{
  "linkset": [
    {
      "anchor": "https://resolver.example.com/01/90664869327",
      
      "https://vocabulary.uncefact.org/untp/linkType#digitalProductPassport": [
        {
          "href": "https://files.example.com/dpp/90664869327-public.json",
          "title": "Digital Product Passport (Public)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Anonymous"]
        },
        {
          "href": "https://files.example.com/dpp/90664869327-customer.json",
          "title": "Digital Product Passport (Customer)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Customer"]
        },
        {
          "href": "https://files.example.com/dpp/90664869327-regulator.json",
          "title": "Digital Product Passport (Regulator)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Regulator"]
        },
        {
          "href": "https://files.example.com/dpp/90664869327-recycler.json",
          "title": "Digital Product Passport (Recycler)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Recycler"]
        }
      ],
      
      "https://vocabulary.uncefact.org/untp/linkType#certificationInfo": [
        {
          "href": "https://files.example.com/certs/gba-compliance.json",
          "title": "GBA Battery Rulebook Compliance Certificate",
          "type": "application/vc+ld+json"
        }
      ]
    }
  ]
}
```

### Example Linkset for Digital Facility Record

Example Identity Resolver response for facility with multiple variants:

```json
{
  "linkset": [
    {
      "anchor": "https://resolver.example.com/99/F123456",
      "https://vocabulary.uncefact.org/untp/linkType#digitalFacilityRecord": [
        {
          "href": "https://files.example.com/dfr/F123456-public.json",
          "title": "Digital Facility Record (Public)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Anonymous"]
        },
        {
          "href": "https://files.example.com/dfr/F123456-customer.json",
          "title": "Digital Facility Record (Customer)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Customer"]
        },
        {
          "href": "https://files.example.com/dfr/F123456-auditor.json",
          "title": "Digital Facility Record (Auditor)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Auditor"]
        },
        {
          "href": "https://files.example.com/dfr/F123456-regulator.json",
          "title": "Digital Facility Record (Regulator)",
          "type": "application/vc+ld+json",
          "accessRole": ["untp:accessRole#Regulator"]
        }
      ],
      
      "https://vocabulary.uncefact.org/untp/linkType#certificationInfo": [
        {
          "href": "https://files.example.com/certs/iso-14001.json",
          "title": "ISO 14001 Environmental Management Certification",
          "type": "application/vc+ld+json"
        }
      ]
    }
  ]
}
```

---

## Best Practices

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview

Supply chain transparency is not just a matter of issuing verifiable credentials — it requires solving a series of interconnected challenges that arise when many independent actors exchange sustainability data across complex, multi-tier value chains. This section describes common supply chain challenges and presents how UNTP can be used to address each of them. Each design pattern is non-normative best practice guidance for UNTP implementers.

## [Transparency Graphs](./TrustGraphs.md)

**Challenge:** Verifying a single credential proves it hasn't been tampered with and was issued by the stated issuer — but it says nothing about whether the *graph* of linked claims across many credentials is trustworthy. Real compliance verification requires following chains of evidence across multiple credentials issued by different parties: confirming issuer identity, checking accreditation of conformity assessment bodies, tracing product origins through traceability events, and verifying mass-balance consistency.

**Solution:** UNTP provides a method to recursively discover credentials via identity resolvers, assemble them into a linked-data transparency graph that represents your value chain, and verify the graph against tiered business rules — from core UNTP validation through industry-specific, geography-specific, and organisation-specific rules.

## [Different Digital Maturities](./DigitalMaturities.md)

**Challenge:** Supply chains will operate with a mix of paper certificates, PDF documents, and digital credentials for years to come. Upstream suppliers may not yet issue verifiable data (no machine-readable structure, no cryptographic integrity, no consistent discovery). Downstream customers may not yet be equipped to consume digital credentials.

**Solution:** Use AI (Large Language Models) to transform unstructured upstream data into graph-compatible linked data — flagged as unverified — so that the same validation rules can run across the entire graph regardless of source maturity. For downstream consumers, every UNTP credential is designed to be both human-readable (via render templates and hosted verifier links) and machine-readable, so a single credential serves all maturity levels.

## [Mass Balance](./MassBalance.md)

**Challenge:** When qualifying and non-qualifying materials are mixed during production, a manufacturer could fraudulently claim the entire output as sustainable — re-using valid input credentials across a larger volume than they cover. Verifying mass-balance integrity requires visibility of all facility inputs, outputs, and production processes, but this data is almost always commercially confidential.

**Solution:** Record every input shipment, production run, and output shipment as verifiable traceability events with quantity data. An independent auditor verifies that output sustainability claims never exceed input quantities, issuing a conformity credential that attests to mass-balance integrity — without exposing the facility's confidential production data to buyers or competitors.

## [Linked Lifecycle Data](./LinkedLifecycleData.md)

**Challenge:** A product's lifecycle extends far beyond the factory gate — through retail, use, repair, refurbishment, and end-of-life processing. But the original manufacturer may no longer exist when lifecycle events need to be recorded years later, and re-issuing product passports creates problems of provenance, authorisation, and fragmentation.

**Solution:** Maintain the original Digital Product Passport as an immutable, cryptographically signed record. Authorised parties (service centres, recyclers, owners) add lifecycle events as new linked credentials via the identity resolver — building a complete, verifiable audit trail without modifying the original passport.

## [Variant-Based Disclosure](./VariantBasedDisclosure.md)

**Challenge:** Different supply chain actors — the public, customers, regulators, auditors, recyclers — need access to different claims within the same credential. But credential-level access control is too coarse-grained: a party either has access to an entire credential or they don't.

**Solution:** Publish multiple document variants of the same credential, each containing a role-appropriate subset of claims with stubs indicating what other data exists. The identity resolver routes requests to the appropriate variant based on an access role parameter, enabling claim-level granularity without requiring cryptographic selective disclosure.

## [Digital Wallets](./DigitalWallets.md)

**Challenge:** The verifiable credentials ecosystem assumes a human holder presenting credentials from a wallet on demand. But UNTP credentials describe inanimate products — a box of goods, a shipment of steel — that cannot participate in presentation exchanges. The wallet-centric model does not fit supply chain transparency as the primary exchange pattern.

**Solution:** UNTP centres on resolver-based credential discovery rather than wallet-based presentation, ensuring any party with access to a product identifier can find credentials without prior relationships or specific software. Wallets remain a complementary mechanism for organisational authentication, regulatory compliance in wallet-mandated jurisdictions, and B2B credential exchange.

## [Durable Storage](./DurableStorage.md)

**Challenge:** UNTP credentials must remain verifiable for the lifetime of a product — potentially decades — but issuing organisations may cease operations and stop paying for hosting. Conventional web hosting and even commercial cloud storage fail once the bills stop being paid.

**Solution:** Use content-addressable, economically incentivised storage protocols (IPFS/Filecoin or Arweave) where the credential's address is derived from its content hash, storage persists independent of the original publisher, and tamper-evidence is guaranteed at the storage layer. This provides post-issuer and post-provider durability without requiring centralised government registers.

---

## Community Activation Program

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

# Community Activation Program

## Introduction

The Community Activation Program (CAP) is a member-organisation-led UNTP implementation programme that drives collective adoption across an industry membership. Rather than each organisation implementing independently, a CAP coordinates implementation at community level — achieving efficiency by re-using the four [registered technical roots](implementation-governance.md) (the **SWI** register of software vendors, the **EXT** register of credential extensions, the **CVC** register of conformity schemes, and the **IDR** register of identifier schemes), and achieving consistency by collaborating through the relevant [sectoral fora](sectoral-collaboration.md).

Each of the four registers is continuously maintained by the UNTP registrar agent, which crawls every registered implementation on every observation cycle and publishes signed conformance results. A community choosing components from these registers therefore inherits cryptographically-verified continuous conformity assurance — no separate vendor or scheme due diligence is required for entries listed as `conformant`.

Through CAP, member organisations can assess the value of UNTP adoption for their sector, engage diverse stakeholders, and deliver a coordinated implementation that reduces costs and improves interoperability for all participants.

Launching a UNTP project requires careful consideration of specific foundational elements that ensure the project’s alignment with industry needs and its potential for widespread adoption. These include:

- **Catalyst for adoption**: Identifying a clear and compelling driver for the project, such as new regulatory requirements (e.g., ESPR or Carbon Border Adjustment Mechanism), or the need to align with a national or sectoral traceability strategy, provides stakeholders with focus and sense of urgency.

- **Engaged buyers**: Buyers must perceive significant value in supplier data, such as enhanced product quality, compliance assurance, or risk mitigation. This engagement is essential to drive demand for the project outcomes.

- **Committed suppliers**: Suppliers must be willing and able to share critical data with buyers, especially when the project demonstrates a direct benefit to them, such as cost reductions, increased market access, or reputational gains.

- **Funding mechanism**: Robust and sustainable funding is crucial for supporting the project’s initial phases, covering development, outreach, and pilot testing. This ensures that the project gains traction and delivers early successes to build momentum.

## CAP delivers value to industries and creates a flywheel of adoption

Member organisations leading a CAP deliver significant value to their membership:

- **Reduced costs and risks** — members share implementation costs and re-use registered software systems, identity registers, and conformity schemes rather than sourcing independently.
- **Interoperable implementations** — choosing from registered technical components and collaborating through sectoral fora ensures that member implementations are consistent and interoperable.
- **Increased membership value** — the CAP gives member organisations a compelling new reason for industries to join and stay engaged.
- **Accelerated adoption** — coordinated community action attracts funding from governments and development banks, and builds momentum as early successes demonstrate value.
- **Access to global expertise** — CAP communities connect with UNECE guidance, established extension programmes, and a growing network of practitioners.

As community implementations mature, they generate a self-sustaining flywheel — each new participant adds value for existing members, attracting further adoption.

![Break even point](../assets/images/costbenefit.png)

## CAP supports a structured approach to implementation and adoption

The CAP toolkit offers a proven, phased methodology:

**Inception Phase**: This initial phase is centered on identifying key catalysts for change, such as emerging regulations, national traceability strategies, or industry-specific challenges. Stakeholders work collaboratively to build consensus, define project goals, and create a compelling business case that articulates value.

**Discovery Phase**: In this exploratory phase, current practices are systematically mapped to identify strengths, gaps, and opportunities, and the four UNTP registers are searched for existing components that match the community's needs — software in [SWI](../implementations/swi/), credential extensions in [EXT](../implementations/ext/), conformity schemes in [CVC](../implementations/cvc/), identifier schemes in [IDR](../implementations/idr/). Most communities find that the majority of their technical stack already exists and is continuously verified by the registrar agent; the activation work focuses on the remainder (typically a member-specific identifier scheme to be registered in IDR, and possibly a sector-specific extension to be registered in EXT). Stakeholders prioritize areas for improvement and establish clear objectives that align with industry needs and regulatory demands.

**Alpha Phase**: During the alpha phase, prototypes of the proposed systems and frameworks are developed and tested within controlled environments. This stage allows stakeholders to assess functionality, refine tools, and demonstrate tangible value to participants. Feedback loops are critical in ensuring the solution is robust and addresses real-world challenges effectively.

**Beta Phase**: Building on the alpha phase, the beta phase scales the project to a broader set of participants. Emphasis is placed on resolving interoperability challenges, ensuring compatibility with existing systems, and refining operational workflows. The project is tested in live scenarios to validate its scalability and effectiveness.

**Live Phase**: The final phase transitions the project into full-scale implementation. Stakeholders work to achieve widespread adoption, leveraging continuous improvement mechanisms to adapt to evolving industry needs. This phase ensures the extension remains sustainable, impactful, and aligned with broader industry objectives.

## A successful CAP is a team effort

Community-wide UNTP implementation thrives through collaboration with a wide range of stakeholders.
![Activation Flywheel](../assets/images/CommunityActivationFlywheel.png)

CAP stakeholders bring unique needs and derive tailored benefits:

- **Member organisations**: Lead the CAP, coordinating implementation across their membership, selecting registered technical components, and representing the community in relevant sectoral fora.

- **Suppliers**: Contribute essential data that ensures compliance with ESG standards and enables access to broader markets. Their participation demonstrates alignment with global sustainability efforts and supports trust across supply chains.

- **Buyers**: Play a pivotal role by demanding traceability and guiding the adoption of data standards. This ensures reliable and transparent information flow, bolstering brand trust and improving consumer confidence.

- **Conformity Schemes**: Provide critical policy frameworks and credentials that establish the credibility of sustainability efforts. CAP-relevant schemes are sourced from the [CVC register](../implementations/cvc/), where each entry is continuously verified by the registrar agent for vocabulary conformance, topic classification, and standard/regulatory alignment. They ensure alignment with environmental, social, and governance (ESG) goals and offer a foundation for industry-wide adoption.

- **Development banks**: Facilitate sustainable growth by offering ESG-linked financing and investment mechanisms. These institutions provide crucial resources that reduce financial barriers and encourage broader participation in UNTP extension projects.

- **Software systems**: Deliver platforms whose UNTP credential issuance is continuously verified by the registrar agent. [SWI register](../implementations/swi/) listings carry observed conformance results — the community can trust the listing without separate vendor due diligence, enabling scalable and interoperable solutions across the membership.

## Expert support

Member organisations bring deep industry knowledge, but CAP teams may benefit from engaging expert consultants with skills in some or all of the following areas:

- **Project management** — coordinating activities, resources, and milestones across the community.
- **IT systems and integration** — deploying tools for data exchange, conformance testing, and process automation.
- **Trust architecture** — designing credential frameworks, data integrity mechanisms, and accountability processes.
- **ESG standards** — aligning implementations with sustainability frameworks and compliance requirements.
- **Stakeholder engagement** — building consensus and managing diverse interests across the community.
- **UNTP expertise** — navigating the specification, extension methodology, and interoperability requirements.

## CAP provides access to valuable resources

Communities running a CAP can access a wide range of resources:

- **Frameworks and toolkits**: Business case templates, implementation plans, and traceability frameworks provide a foundation for project planning, helping teams map out goals, resource requirements, and value propositions.

- **Registered technical components**: The [UNTP implementation registers](implementation-governance.md) provide a catalogue of tested identity registers, conformity schemes, credential extensions, and software systems that communities can choose from to accelerate implementation.

- **Sectoral fora**: The [UNTP sectoral fora](sectoral-collaboration.md) provide a venue for communities in the same sector or jurisdiction to collaborate on harmonisation, share lessons, and align their implementations.

- **UNECE guidance**: Strategic guidance from UNECE ensures that community implementations remain consistent with the core specification and interoperable across borders and industries.

- **Collaboration networks**: Engaging with established CAP communities offers opportunities for shared learning, proven methodologies, and alignment with broader industry goals.

## Starting a CAP is simple

- **Join the community**: Join the general UNTP chat channel via the link on the [homepage](https://untp.unece.org) and join a relevant [sectoral fora](sectoral-collaboration.md) to collaborate with peers and register your community. 

- **Access the CAP toolkit**: Access [implementation guidance](../tools-and-support/) including methodologies, templates, and tools to guide your community through every phase of implementation. For each technical decision (software platform, credential extension, conformity scheme, identifier scheme), browse the corresponding register, pick the components that fit, and proceed. Each register entry's status reflects continuous agent-verified conformance — no further vendor due diligence is required for `conformant` entries.

---

## Implementation Registers Architecture

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

The implementation governance layer is organised as **four registers** — the technical roots of the [UNTP governance tree](index.md#the-untp-implementation-governance-tree). Together they catalogue the software, extensions, conformity schemes, and identifier infrastructure that every UNTP implementation draws on.

Registration is a continuous process, not a one-shot certification event. An implementer publishes a DID, signs a registration Verifiable Credential, and exposes their service or credentials at a stable URL. From that point onward, the **UNTP registrar agent** (`did:web:registrar.uncefact.org`) crawls each registered implementation on every observation cycle, validates conformance against published tests, and writes signed observations back to the register. **Status reflects observed reality, not declared intent** — critical at the scale UNTP is designed for, where millions of independent implementers cannot be manually audited.

## The four registers

| Register | Catalogues | What the implementer publishes | What the agent verifies |
|---|---|---|---|
| **[SWI](../implementations/swi/)** — Software Implementers | Software vendors and the build versions they ship | DID + registration VC + an `issuingSoftware` block in every credential the software issues | Signature, schema conformance, vocabulary conformance, optional binding-credential alignment, sample evidence per software version |
| **[EXT](../implementations/ext/)** — Community Extensions | UNTP credential extensions defined by member organisations | DID + registration VC + extension schema, JSON-LD context, and vocabulary at stable URLs | Schema/context/vocabulary content hashes, UNTP context import, no UNTP redefinitions, all terms resolved, samples validate |
| **[CVC](../implementations/cvc/)** — Conformity Vocabulary Catalogue | Conformity schemes (audit, assessment, certification programs) | DID + registration VC + a UNTP-conformant CVC vocabulary at a stable `vocabularyURL` | Vocabulary URL reachable, CVC schema conformance, profile/version URI immutability, topic URI resolution, standard/regulatory alignment reachability |
| **[IDR](../implementations/idr/)** — Identifier Schemes | Identifier schemes for products, facilities, organisations, members, and key assets | DID + registration VC + a publicly reachable resolver service URL | Registry URL reachable, identifier pattern compiles, resolver template resolves, optional UNTP IDR conformance, optional DIA issuance verification |

Each register has its own governance document with the full publishing checklist, validation rules, and lifecycle. Per-register detail is linked in the sections below.

## Why this model

Self-attestation does not scale to millions of implementers — there is no way to manually audit a million conformance claims, and even sampling becomes unreliable. The agent-driven model gives verifiers two things self-attestation cannot:

1. **Continuous integrity**, because every observation is a freshly-signed Verifiable Credential, and any drift from the registered configuration (silent schema changes, broken resolvers, unsigned credentials, forged software claims) is detected on the next crawl cycle.
2. **Cryptographic auditability**, because observations are append-only and signed by the registrar agent's DID — no party can quietly modify history, including UNECE.

The implementer's job stops at "publish your DID, issue a registration VC, expose your service at a stable URL." Everything downstream — observation, validation, drift detection, status updates — is the agent's job.

## Per-register detail

Each register is documented in depth on its own page — including the full publishing checklist, validation rules, lifecycle, and the catalogued entries themselves.

| Register | Browse entries | How to register | Governance document |
|---|---|---|---|
| **SWI** — Software Implementers | [Software register](../implementations/swi/) | [Register your software](../implementations/swi/registration-guide.md) | [SWI governance](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/swi/governance.md) |
| **EXT** — Community Extensions | [Extensions register](../implementations/ext/) | [Register an extension](../implementations/ext/registration-guide.md) | [EXT governance](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/ext/governance.md) |
| **CVC** — Conformity Vocabulary Catalogue | [Scheme owners register](../implementations/cvc/) | [Register a scheme](../implementations/cvc/registration-guide.md) | [CVC governance](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/cvc/governance.md) |
| **IDR** — Identifier Schemes | [Identifier registers](../implementations/idr/) | [Register an identifier scheme](../implementations/idr/registration-guide.md) | [IDR governance](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/idr/governance.md) |

## Conformity Assessment Bodies

Conformity assessment bodies (CABs) — auditors, certifiers, testing laboratories, and inspection bodies — issue [Digital Conformity Credentials (DCCs)](../specification/ConformityCredential.md) carrying independently verified assessments. CABs **do not have their own register**; instead they consume three of the four registers and produce credentials that the SWI register's agent observes:

- They use **SWI-registered software** to issue DCCs (their software's `issuingSoftware` block appears in every DCC).
- They reference **CVC-registered schemes and profile versions** in `attestation.assessmentScheme`.
- They may be members in **IDR-registered industry-association schemes** (e.g. an RBA-recognised audit firm).

A CAB's DID typically appears as the issuer of DCCs in the wild. The SWI register's continuous observation cycle therefore validates CAB-issued credentials as a side-effect of validating the software that issued them. CAB-specific registration is not separately required.

Detailed implementation guidance for specific stakeholder types (producers, regulators, conformity bodies, consumers) is on the [Implementation Plans](../tools-and-support/ImplementationPlans.md) page.

## The trust anchor architecture

The four registers connect to form a continuous trust chain that anchors at UNECE.

UNECE issues a **registrar Digital Identity Anchor (DIA)** credential about each registered DID across all four registers — software vendors (SWI), extension owners (EXT), scheme owners (CVC), and identifier scheme operators (IDR). The DIA cryptographically binds the registrar's DID to its registered identity and the components it operates. Each DIA is hosted on the corresponding register entry as the trust anchor for downstream verifiers.

When a registered party then issues their own credentials — a SWI-listed vendor's software issuing DPPs, an IDR-listed industry association issuing member DIAs, a CAB issuing DCCs — verifiers can chase the trust chain back to UNECE without trusting any single party blindly:

```
UNECE  ──signs registrar DIA──▶  Registered DID
           (in IDR/SWI/EXT/CVC)
                                      │
                                      ▼ signs
                              Member / Software-issued
                              / Extension-defined credential
                                      │
                                      ▼ verified by
                              Verifier with trust chain
                              anchored at UNECE
```

This makes UNTP's identity layer cryptographically continuous from the UN level all the way down to a single batch-level DPP. A verifier encountering an unfamiliar industry-association DIA can resolve the issuer's DID, find the registered IDR entry, fetch the UNECE-issued registrar DIA from that entry, and confirm the chain — without prior trust relationships and without intermediary brokers.

## Conformance testing — playground and continuous observation

UNTP provides two distinct conformance-testing surfaces serving two different purposes:

### Test playground (pre-production, implementer-driven)

The hosted [test playground](../tools-and-support/TestService.md#test-playground) and the locally deployable [full test service](../tools-and-support/TestService.md#full-test-service) are for implementers to validate their work **during development**, before publishing anything. The playground exercises the same [three-tier test architecture](../tools-and-support/TestService.md#3-tier-test-architecture):

| Tier | What it tests | UNTP Core | Extension |
|---|---|---|---|
| **Tier 1 — Technology** | W3C Verifiable Credential compliance | All credential issuers | No additional requirements expected |
| **Tier 2 — Schema** | Schema validity for each credential type | UNTP core schemas | Extended credentials must validate against both core and extension schemas |
| **Tier 3 — Trust Graph** | Correct linking between DPP, DTE, DCC, DFR, and DIA credentials | Standard credential linking | Extension-specific choreography and linking rules |

The playground is self-service and produces evidence credentials that implementers can attach to their registration VCs.

### Continuous registrar-agent observation (production, agent-driven)

The same conformance dimensions are then enforced **continuously** by the UNTP registrar agent against credentials and artefacts published in production. Where the playground is *implementer-driven and point-in-time*, the agent is *registrar-driven and continuous*. The agent's observations are signed Verifiable Credentials recorded in the relevant register and visible to any verifier.

Together, the playground reduces the cost of getting a registration right the first time, and the agent ensures registration stays right over time.

The key principle across both surfaces is that a credential conforming to a UNTP extension is also conformant with UNTP core. This ensures that credentials issued in a specific industry or geographical context remain understandable across industry or geographic boundaries.

---

## Governance

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

The UNTP governance framework follows UN/CEFACT standard governance methodology and is designed to provide implementers with confidence that UNTP:

- is a public good that cannot be captured by any specific commercial interest and is permanently free to use.
- is developed via a consensus based process that ensures it will meet the needs of value chain actors and member states.
- is specific, testable, and rigorously versioned so that implementers can be confident of stability and interoperability.
- is compatible with relevant national and international standards and regulations.

![UNTP Governance Framework](../assets/images/governance-overview.png)

The governance framework covers four distinct domains.

## [UNTP Core Specification](specification-development.md)

How the UNTP specification itself is developed, maintained, and versioned as a UN standard — including the UN/CEFACT framework, working groups, participation rules, change management process, and version management.

## [UNTP Technical Implementations Register](implementation-governance.md)

UNTP adoption depends on technical implementations by Identifier registers, conformity schemes, credential extensions, and  software systems. This is the bottom-up process by which individual implementations earn registration by building conformant implementations, passing tests and providing evidence. 

## [UNTP Sectoral Collaboration Fora](sectoral-collaboration.md)

How communities working in the same sector or jurisdiction collaborate on harmonisation, re-use, and the sharing of lessons across multiple UNTP extensions and implementations. This is the top-down process that complements implementation governance — ensuring that technically interoperable implementations also converge on shared semantics and best practices through sectoral fora.

## [UNTP Community Activation Program](CommunityActivationProgram.md)

The Community Activation Program (CAP) provides a methodology and business case for member organisations to drive collective UNTP adoption across their membership. Communities choose from registered technical components — identity registers, conformity schemes, credential extensions, and software systems — to accelerate interoperable implementation, and join sectoral fora to facilitate collaboration and harmonisation across their industry.

## The UNTP Implementation Governance Tree

A scalable, interoperable supply chain transparency framework has to work across every industry sector and jurisdiction, accommodate each sector's specific needs, empower existing communities rather than replacing them, and share reusable technical components (for example software platforms) across multiple sectors and geographies.

The best way to explain the UNTP approach is an analogy to a tree.

![UNTP Implementation Tree](../assets/images/governance-implementation-tree.png)

* There is just one tree trunk, representing the UNTP core specification. Every implementation — whether in the branches above or the roots below — is interoperable with every other because all of them build on this common core.
* A small number of branches represent very broad industry sectors such as Critical Energy Transition Materials (CETM). The UN provides a collaboration forum for implementation communities within each sector to meet, share knowledge, and where relevant build consensus.
* The leaves are where the action happens. They represent existing community groups such as industry member associations who define the use cases and specific UNTP extensions that are needed to meet their member needs.
* The roots represent registered (and tested) technical tools and services such as software platforms and identity registers that will often be used in many different communities. So the leaves can draw upon any of the roots.

The implementation pathway for any specific actor is therefore to look for the relevant sectoral forum (a branch), find an existing community that matches their needs (or launch one with their preferred member association if there's nothing ready to go), and then use any of the tested tools that match their system requirements (or push their preferred software vendor to implement UNTP). In this way there is maximum flexibility, empowerment, and re-use of existing work. It's the fastest and simplest pathway to genuine global supply chain transparency.

---

## Adoption Group

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

## Mailing List

A group mailing list is maintained and can be used by any list member to post messages to the group. The list also maintains an archive of all messages sent to the group.

- To [join the mailing list](https://gaggle.email/join/untp-adoption@gaggle.email) - your request will be reviewed by a list administrator.

## Meetings

Group meetings are held fortnightly. Please add the following links to your calendar. 

UNTP Adoption team meetings are held fortnightly at alternating times to accommodate participants from different timezones. Use the links below to add the calendar entries to your diary or add the meeting links.

- **Thursday 9am UTC Meetings**. Every 4 weeks. Next meeting 10th July 2025.

  - [ICS Calendar File](/meetings/UNTP-Adoption-WG-9am-UTC-4weekly.ics). Download and double click to add the meetings to your calendar
  - [Zoom meeting link](https://us02web.zoom.us/j/88335520636?pwd=YZct0AJbC7Qft3jBY1RO4O1Mu029kz.1). Click to join the meeting without a calendar entry.

- **Thursday 8pm UTC meetings**. Every 4 weeks. Next meeeting 24th July 2025.
  - [ICS Calendar File](/meetings/UNTP-Adoption-WG-8pm-UTC-4weekly.ics). Download and double click to add the meetings to your calendar.
  - [Join the meeting](https://us02web.zoom.us/j/89718957502?pwd=j4F7ayx8cN6jk3xUXu4Fp67ndaVYdb.1). Click to join the meeting without a calendar entry.

Each meeting will generally work through open [adoption group issues](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/?sort=created_date&state=opened&label_name%5B%5D=WG-Adoption) and [pull requests](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/merge_requests).

Previous meeting dates, recordings, transcripts, and minutes are summarised below with the most recent meeting at the top.

## Previous Meetings

| Meeting    | Summary                                                          | Recording           | Transcription |
| ---------- | ---------------------------------------------------------------- | ------------------- | ------------- |
| 2025-12-11 | [Dec 11 Meeting](#2025-12-11-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-12-11-UNTP-Adoption-WG.pdf)|
| 2025-11-27 | [Nov 27 Meeting](#2025-11-27-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-11-27-UNTP-Adoption-WG.pdf)|
| 2025-11-13 | [Nov 13 Meeting](#2025-11-13-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-11-13-UNTP-Adoption-WG.pdf)|
| 2025-10-30 | [Oct 30 Meeting](#2025-10-30-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-10-30-UNTP-Adoption-WG.pdf)|
| 2025-10-16 | [Oct 16 Meeting](#2025-10-16-meeting-summary) | Not Available |[Link to transcript from Zoom]|
| 2025-10-02 | [Oct 02 Meeting](#2025-10-02-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-10-02-UNTP-Adoption-WG.pdf)|
| 2025-09-18 | [Sept 18 Meeting](#2025-09-18-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-09-18-UNTP-Adoption-WG.pdf)|
| 2025-08-21 | [Aug 21 Meeting](#2025-08-21-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-08-21Summary_UNTP_Adoption_WG_Evening_CET_Meeting.pdf)|
| 2025-08-07 | [Aug 07 Meeting](#2025-08-07-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-08-07-Meeting-assets-for-UNTP-Adoption-Group.pdf)|
| 2025-07-10 | [July 10 Meeting](#2025-07-10-meeting-summary) | Not Available |[Link to transcript from Zoom](/meetings/adoption-working-group/2025-07-10-Meeting-Summary-for-UNTP-Adoption-Group-Morning-CET-Meeting.pdf)|

## Terms of Reference

### Purpose & functions

The purpose of the Group is to coordinate UNTP aspects relating to the adoption of UNTP, under the direction of the UNTP Steering Committee.

- To maintain, subject to oversight from the Steering Committee, the communications templates, enablement and case studies to facilitate adoption of UNTP by both public and private sector organizations.
- To develop and maintain the [Business Case section](/docs/business-case) of UNTP web site
- To maintain the [implementation register](/docs/implementations/)
- To maintain the [extensions register](/docs/implementations/ext/)
- To develop and maintain the Community Activation Program
- To develop and maintain the Value Assessment Framework
- To develop and maintain the relationships with global DPP initiatives (EU JTC24, ISO, ITU, IEEE, UNECE, ??)
- To develop and maintain a list of communications templates for extenders and implementers
- To develop and maintain UNTP training programs
- To develop and maintain UNTP communications
- To liaise with other UNTP sub-committees to be aware and to advise on any adoption related issues that may arise.
- To provide adoption advice, as required, to Industry Extension Groups
- To liaise with UN/CEFACT to ensure continuing compatibility with applicable CEFACT standards, including interactions with other global DPP efforts
- To develop and maintain the relationships with global DPP standards initiatives
- To maintain awareness of developments within global DPP standards efforts to facilitate alignment with international practices
- To liaise with other UNTP sub-committees to ensure that compatibility between UNTP elements is maintained.
- To maintain the Group mailing list

### Roles

**Group Lead**

- Arrange and Chair Group meetings
- Provide updates as required to the UNTP Steering Committee
- Attend UNTP Steering Committee meetings
- Act as liaison point for identified global DPP initiatives
- Provide recommendations to the Steering Committee on matters having potential to affect other UNTP sub-committee activities
- To cooperate with the Steering Committee in handling complaints and disputes relating to extenders and implementers
- To provide advice and to participate when appropriate in Suspension proceedings and Appeal proceedings relating to extenders and implementers
- Maintain mailing list specific to Sub-committee participation
- Delegate duties to other Group members as applicable

**Group Technical Editor**

- Maintain relevant Github repository pages
- Maintain Pull Requests relating to the Business Case section of UNTP website
- Maintain extension and implementation registers

### Operation

- The Group is open to anyone to participate as an observer.
- Contributors to specifications and content maintained by the group must be registered UN/CEFACT experts.
- The Group will meet monthly, or more frequently.
- Where deemed necessary by the Group Lead, working groups may be established for dealing with specialized matters
- While consensus among group participants is always desirable, decisions affecting the UNTP Adoption Working Group are taken by the Group Lead and are subject to oversight by the Steering Committee.

## 2025-12-11 Meeting Summary

Michael and Zach caught up on personal schedules and discussed weather conditions in their
respective locations before transitioning to a discussion about artisanal mining challenges and the
need for industry associations to be introduced to UNTP. They explored the complexities of volunteer
work, including the balance between volunteer commitments and making a living, while emphasizing
the importance of maintaining a non-commercial frame for UNTP volunteers. The conversation
concluded with discussions about developing a legitimate and scalable pathway for UNTP projects,
including the need for clear processes, communication channels, and technical training
requirements.

## 2025-11-27 Meeting Summary

The meeting began with discussions about RBA initiatives, including progress with
hyperscalers' efforts to eliminate human trafficking in data center supply chains and
their commitment to aligning standards with UNTP. The team reviewed various
ongoing projects including textile product group work, the Value Assessment
Framework renaming, and UNTP component updates, with particular focus on
technical implementations and extensions. The group concluded by addressing
proposed changes to UNTP extension pages and scheduling future meetings,
including one in January.

## 2025-11-13 Meeting Summary

The team discussed updates on the Universal National Tailoring Protocol (UNTP) and its recent
adoption by the RBA, including progress on communications and value assessment framework
work. Website restructuring efforts were reviewed, with focus on simplifying content and reorganizing
pages to clearly distinguish between audience, benefits, and goals. The team also discussed
developing an impact assessment framework with measurable indicators, consolidating collaboration
tools, and planning for UNTP version 1.0 release by the end of December.

## 2025-10-30 Meeting Summary

The meeting began with Matthias explaining the group's structure and updates on
various work packages, including communications and impact assessment efforts.
The group discussed several initiatives related to UN partnerships and textile
standards, including potential collaborations with various UN entities and the need for
clear communication about UNTP specifications. The conversation ended with
introductions to new team members and discussions about aligning messaging across
different groups, while noting the absence of several key working group leads.

## 2025-10-16 Meeting Summary
No call.

## 2025-10-02 Meeting Summary

The meeting began with introductions and discussions about a UN CFACT project
under UNTP, emphasizing open development processes and the importance of
communication protocols. The team explored implementation strategies and work
packages, with various participants sharing their perspectives on how to proceed
with the adoption process while addressing concerns about structure and
coordination. The conversation ended with discussions about specific work packages,
including textiles extensions, and established next steps for various team members to
move the project forward.

## 2025-09-18 Meeting Summary
The meeting covered updates on UNTP adoption discussions with potential partners including Mishla and Michelin, along with discussions about extension registration processes and implementation guidelines. The team reviewed training materials development approaches targeting different business roles and discussed organizational dynamics in vertically integrated businesses. Work package coordination and validation processes were addressed, with plans to improve structure and documentation for future implementation efforts.

## 2025-08-21 Meeting Summary

The team discussed scheduling challenges and potential time zone adjustments
for their meetings, with a focus on improving participation from North American
members. They reviewed ongoing ecosystem extension initiatives and work
package assignments, including updates on implementers, standards
collaboration, and upcoming events in various regions. The group established
new communication strategies for UNTP-related content and discussed
formalizing their approach to managing work packages, with plans to create
structured agendas and assign team leaders for subgroups.

## 2025-08-07 Meeting Summary

The UNTP adoption working group held their bi-weekly meeting to discuss various work packages including standards, collaboration, implementers, and communications, with participants expressing interest in different areas and volunteering for specific tasks. The team explored the value assessment framework for UNTP and discussed prioritizing work packages, with communications being identified as a top priority due to its importance for stakeholder engagement. The conversation ended with discussions about organizing work packages, managing participation in working groups, and stablishing processes for creating and reviewing frequently asked questions about UNTP.

## 2025-07-10 Meeting Summary

This was the second meeting of the UNTP Adoption Working Group, chaired by Michael Shea with technical lead Zach Zeus. The session began with participant introductions, highlighting diverse expertise across circular economy, materials, construction, digital identity, and sustainability sectors. Key discussion points included clarifying IP rules, GitLab use for collaboration, and the process for becoming a registered UN/CEFACT expert. The group also reviewed the Terms of Reference and discussed structuring work into smaller “work packages” focused on communication, adoption strategy, pilots, and conformity testing. Participants emphasized the need for real-world pilots, clearer business case development, funding to support adoption, and improved coordination with industry and existing DPP initiatives.  NOTE:  This summary was created by ChatGPT on Nov 11, 205

---

## Conformity Group

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

## Mailing List

A group mailing list is maintained and can be used by any list member to post messages to the group. The list also maintains an archive of all messages sent to the group.

- To [join the mailing list](https://gaggle.email/join/untp-conformity@gaggle.email) - your request will be reviewed by a list administrator.

## Meetings

Group meetings are held approximately fortnightly. To attend, please join the mailing list above.

Each meeting will generally work through open [issues](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/?sort=created_date&state=opened&label_name%5B%5D=WG-Conformity) and [pull requests](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/merge_requests).

Previous meeting dates, recordings, transcripts, and minutes are summarised below with the most recent meeting at the top.

## Previous Meetings

| Meeting    | Summary                                                                 | Materials                                                                                       |
| ---------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| 2026-02-10 | [Feb 10th meeting summary](#2026-02-10-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2026-02-10TranscriptUNTPConformityMtg11.pdf) and [Slides](/meetings/conformity-working-group/2025-02-10-Mtg-11-slides.pdf) |
| 2026-01-20 | Jan 20th meeting summary - NONE | [Meeting Materials](/meetings/conformity-working-group/2026-01-20TranscriptUNTPConformityMtg10.pdf) |
| 2025-12-16 | Dec 16th meeting summary - NONE | [Meeting Materials](/meetings/conformity-working-group/2025-12-16TranscriptUNTPConformityMtg9.pdf) |
| 2025-12-03 | [Dec 3rd meeting summary](#2025-12-03-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-12-03TranscriptUNTPConformityMtg08.pdf) |
| 2025-11-05 | [Nov 25th meeting summary](#2025-11-25-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-11-25-conformity-meeting-7.pdf) and [Slides](/meetings/conformity-working-group/2025-11-25-Mtg-7-slides.pdf)|
| 2025-11-05 | [Nov 5th meeting summary](#2025-11-05-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-11-05-conformity-meeting-6.pdf) and [Slides](/meetings/conformity-working-group/2025-11-05-Mtg-6-slides.pdf)|
| 2025-10-14 | [Oct 14th meeting summary](#2025-10-14-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-10-14-conformity-meeting-5.pdf) |
| 2025-09-30 | [Sept 30th meeting summary](#2025-09-30-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-09-30-conformity-meeting-4.pdf) |
| 2025-09-02 | [Sept 2nd meeting summary](#2025-09-02-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-09-02-conformity-meeting-3.pdf) |
| 2025-08-13 | [Aug 13th meeting summary](#2025-08-13-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-08-13-UNTP-Conformity-slides.pdf) |
| 2025-07-15 | [Kick-off of the conformity working group](#2025-07-15-meeting-summary) | [Meeting Materials](/meetings/conformity-working-group/2025-07-15-Conformity-Project-intro.pdf) |

## Terms of Reference

**Abbreviations used**

- DCC - Digital Conformity Credential
- CVC - Conformity Vocabulary Catalogue

### Purpose & functions

The purpose of the Group is to coordinate UNTP aspects relating to conformity credentials, under the direction of the UNTP Steering Committee. Specific functions are as follows:

- To maintain, subject to oversight from the Steering Committee, the UNTP Core DCC specification, including definitions and vocabulary
- To develop and maintain the SVC specification, including Conformity Topic Classification and the Conformity Vocabulary Schema.
- To maintain the UNTP Certifier Implementation Register
- To maintain the UNTP Conformity Scheme Register
- To maintain the DCC Test harness
- To provide advice to the UNTP Adoption subcommittee regarding conformity-related issues arising in relation to UNTP adoption
- To provide technical advice, as required, to Industry Extension Groups
- To liaise with UN/CEFACT to ensure continuing compatibility with applicable CEFACT standards, including the Digital Product Conformity Certificate Exchange standard.
- To maintain awareness of developments within ISO CASCO and other relevant global conformity assessment institutions to facilitate alignment with international practices
- To liaise with other UNTP sub-committees to ensure that compatibility between UNTP elements is maintained.
- To maintain the Group mailing list

### Roles & Responsibilities

**Group Lead**

- Arrange and Chair Group meetings
- Provide updates as required to the UNTP Steering Committee
- Attend UNTP Steering Committee meetings
- Act as liaison point for identified global conformity assessment institutions
- Provide recommendations to the Steering Committee on matters having potential to affect other UNTP sub-committee activities
- To cooperate with the Steering Committee in handling complaints and disputes relating to the DCC or SVC
- To provide advice and to participate when appropriate in Suspension proceedings and Appeal proceedings relating to DCC or SVC
- Maintain mailing list specific to Sub-committee participation
- Delegate duties to other Group members as applicable

**Group Technical Editor**

- Maintain relevant Github repository pages
- Maintain Pull Requests relating to the DCC and SVC specifications
- Maintain classification lists, implementation registers
- Maintain DCC Test Harness

### Operation

- The Group is open to anyone to participate as an observer.
- Contributors to specifications and content maintained by the group must be registered UN/CEFACT experts.
- The Group will meet monthly, or more frequently.
- Where deemed necessary by the Group Lead, working groups may be established for dealing with specialized matters
- While consensus among group participants is always desirable, decisions affecting the UNTP Core DCC Specification are taken by the Group Lead and are subject to oversight by the Steering Committee.

## 2026-02-10 Meeting Summary
UNTP Conformity Meeting #11 - 10 February 2026

### Agenda
- Welcome & Rules of the Road
- New member intros
- Conformity Credential webpage prep for Public Comment
- UNTP Digital Identity Anchor in our work
- UNIDO publication update

### Key Outcomes
- The Assessment Assurance documentation was reviewed and has now been submitted for processing.
- The subgroup on Scheme Vocab will be reactivated to consider Issue #590

## 2025-12-03 Meeting Summary
UNTP Conformity Meeting #8 - 03 December 2025

### Attendance
Brett Hyland
Etty Feller
Reinaldo Figueiredo
Gideon Richards
Ulas Nalbantoglu
Zach Zeus
Neil Savery
Georgia Alsop
Adrienna Zsakay
Phil Archer
Anil Jauhri
Rama Ha
Alison Jose

### Welcome & Rules of participation (BH)
### New participant intro - Rama Ha
### Discussion topic:  
Decide if the draft Conformity Assurance Guide is ready to be socialised beyond our own group
Discussion indicated broad support for the Assessment Assurance approach that was circulated ahead of the meeting.   A number of upcoming external stakeholder mtgs were identified that would provide opportunities for socialising the concepts.  
New action : Write intro for the UNTP Assessment Assurance doc to provide context and then get Steering Committee permission to commence preliminary consultancy.  Updated doc sent to group on 5/12 with approval to socialise within our networks - Action to be closed
New action: Raise Gitlab issue for incorporating UNTP Assessment Assurance as a normative part of UNTP.  Issue #563 raised and Updated document linked on 5/12 - Action to be closed
 
### Previous action items completed:
•	Problem with selecting national delegation for CEFACT Expert registration - Zach advises this interface is now stable - Action closed
•	Gitlab Issue #79 (open) has been discussed in terms of credible processes for gathering human observations to form conclusions (such as human welfare).  It was agreed that work just completed by the UNTP-Conformity group in defining credible scheme evaluation represents a possible resolution of this issue - Action closed  
Note: Gitlab Item #79 has since been annotated as follows:
The UNTP-Conformity group has been discussing closely related matters to Issue#79 over the past few months. In relation to 'accumulating evidence of ethical participation' through mechanisms other than formal audits, this does seem a worthy goal and yet to be packaged as a conformity credential it would still need to be structured and managed through some set of processes (let's call this a 'scheme', which is the formal term in ISO CASCO).  The UNTP-Conformity group has been working hard on describing what a credible scheme should look like, in terms of: scheme development/management, governance, standards development, competency of personnel and oversight of conformity assessment (refer to Issue #563 for more detail).  While the UN wouldn't wish to be involved in judging schemes, there are classes of organisations who carry out this exactly this function. 
So, such a human welfare scheme has the option of issuing conclusions that depend on a user's own belief in the value of the scheme (ie, does not align with UNECE Rec49 principles), or the scheme could submit to an evaluation of their scheme by a recognised authority such that there is alignment with REC49 principles.
In terms of the other matter raised in the thread above, that of an isolated, stand-alone, human observation, this doesn't really sound like the subject of a conformity credential. Perhaps a record of such an observation could be used as one form of 'evidence' which might be linked directly from a claim that is contained in a DPP or DFR.

### Outstanding action item list:

1. (Updated) Scope the terms of engagement with the conformity credential implementors previously nominated by the subgroup and have Zach approach those groups - BH & ZZ to draft ToR
2. (Updated) Articulate a framework for referencing SDO-published standards such that everyone can digitally reference these in the same way, regardless of who's doing the implementation - PA to liaise with BH
3. (Updated) Seek advice on whether the Conformity Topic Classification can be moved to its own Gitlab page as it isn’t exclusive to the Scheme Vocab subject and also note that the Waste Framework Directive is missing from the list of references (ZZ action)
4. (Updated) If a particular scheme requires all CABs assessing to their scheme to use a hierarchical structure for criteria then should this be accommodated as an extension (Gitlab open issue #344) or must we update the Core conformity credential structure (Subgroup action)
5. (Update) Establish whether the scheme header/vocab structure allows reference to scheme assurance pathways and seek to have the Logical Model updated in not (BH & ZZ action)
6. Steve Capell is to investigate any implications for UNTP information security in light of the EU CapGemini initiative (SC action)

## 2025-11-25 Meeting Summary
UNTP Conformity Meeting #7 - 25 November 2025

### Attendance
 - See [Transcript](/meetings/conformity-working-group/2025-11-25-conformity-meeting-7.pdf)

#### Welcome & Rules of participation 

#### Participant intro (All)

### Item Discussion
 - See [Slides](/meetings/conformity-working-group/2025-11-25-Mtg-7-slides.pdf)

#### Outstanding Action items:
Not reviewed so carried forward:
1 - Problem with nominating national delegation for CEFACT Expert registration interface has been fixed, but instabilities in the platform remain, Zach to continue to monitor and advise group (ZZ action)

2 - Worked Example subgroup to scope the terms of engagement with the conformity credential implementors previously nominated by the subgroup and have Zach approach those groups (Subgroup action)

3 - Articulate a framework for referencing SDO-published standards such that everyone can digitally reference these in the same way, regardless of who's doing the implementation (BH action in conjunction with PA)

4 - Seek advice on which UNTP group is tasked with maintenance of the Conformity Topic Classification, move it to the appropriate Gitlab page and also advice the owner that the Waste Framework Directive is missing from the references (ZZ action)

5 - If a particular scheme requires all CABs assessing to their scheme to use a hierarchical structure for criteria then should this be accommodated as an extension (Gitlab open issue #344) or must we update the Core conformity credential structure (Subgroup action)

6 - Gitlab open issue #79 has implications for defining where observations finish and CA begins, so BH to draft response based on insights from Mtg#4 and circulate for feedback before annotating the Gitlab issue log.

7 - Confirm whether the scheme header/vocab structure allows reference to scheme endorsements (BH action)

8 - Steve Capell is to investigate any implications for UNTP information security in light of the EU CapGemini initiative

## 2025-11-05 Meeting Summary
UNTP Conformity Meeting #6 - 05 November 2025

### Attendance
 - See [Transcript](/meetings/conformity-working-group/2025-11-05-conformity-meeting-6.pdf)

#### Welcome & Rules of participation 

#### Participant intro (All)

### Item Discussion
 - See [Slides](/meetings/conformity-working-group/2025-11-05-Mtg-6-slides.pdf)

#### Outstanding Action items:
Not reviewed so carried forward:
1 - Problem with nominating national delegation for CEFACT Expert registration interface has been fixed, but instabilities in the platform remain, Zach to continue to monitor and advise group (ZZ action)

2 - Worked Example subgroup to scope the terms of engagement with the conformity credential implementors previously nominated by the subgroup and have Zach approach those groups (Subgroup action)

3 - Articulate a framework for referencing SDO-published standards such that everyone can digitally reference these in the same way, regardless of who's doing the implementation (BH action in conjunction with PA)

4 - Seek advice on which UNTP group is tasked with maintenance of the Conformity Topic Classification, move it to the appropriate Gitlab page and also advice the owner that the Waste Framework Directive is missing from the references (ZZ action)

5 - If a particular scheme requires all CABs assessing to their scheme to use a hierarchical structure for criteria then should this be accommodated as an extension (Gitlab open issue #344) or must we update the Core conformity credential structure (Subgroup action)

6 - Gitlab open issue #79 has implications for defining where observations finish and CA begins, so BH to draft response based on insights from Mtg#4 and circulate for feedback before annotating the Gitlab issue log.

7 - Confirm whether the scheme header/vocab structure allows reference to scheme endorsements (BH action)

8 - Steve Capell is to investigate any implications for UNTP information security in light of the EU CapGemini initiative

#### Close -

## 2025-10-14 Meeting Summary
UNTP Conformity Meeting #5 - 14 October 2025

### Attendance
 - See [Transcript](/meetings/conformity-working-group/2025-10-14-conformity-meeting-5.pdf)
  
#### Participant intro (All)

#### Outstanding Action items:
Agreement was reached that we need to find ways to establish trust in UNTP conformity credentials. if the protocol is to become credible.  

1 - Problem with nominating national delegation for CEFACT Expert registration interface has been fixed, but instabilities in the platform remain, Zach to continue to monitor and advise group (ZZ action)

2 - Worked Example subgroup to scope the terms of engagement with the conformity credential implementors previously nominated by the subgroup and have Zach approach those groups (Subgroup action)

3 - Articulate a framework for referencing SDO-published standards such that everyone can digitally reference these in the same way, regardless of who's doing the implementation (BH action in conjunction with PA)

4 - Seek advice on which UNTP group is tasked with maintenance of the Conformity Topic Classification, move it to the appropriate Gitlab page and also advice the owner that the Waste Framework Directive is missing from the references (ZZ action)

5 - If a particular scheme requires all CABs assessing to their scheme to use a hierarchical structure for criteria then should this be accommodated as an extension (Gitlab open issue #344) or must we update the Core conformity credential structure (Subgroup action)

6 - Gitlab open issue #79 has implications for defining where observations finish and CA begins, so BH to draft response based on insights from Mtg#4 and circulate for feedback before annotating the Gitlab issue log.

7 - Confirm whether the scheme header/vocab structure allows reference to scheme endorsements (BH action)

8 - Steve Capell is to investigate any implications for UNTP information security in light of the EU CapGemini initiative

#### Close -

## 2025-09-30 Meeting Summary
UNTP Conformity Meeting #4 - 30 September 2025

### Attendance
 - See  [Transcript](/meetings/conformity-working-group/2025-09-30-conformity-meeting-4.pdf)

### Item Discussion

#### Welcome & Rules of participation (BH)

#### Participant intro (All)

#### Outstanding Action items:
1 - Problem with nominating national delegation for CEFACT Expert registration interface has been fixed, but instabilities in the platform remain, Zach to continue to monitor and advise group (ZZ action) 

2 - Worked Example subgroup to scope the terms of engagement with the conformity credential implementors previously nominated by the subgroup and have Zach approach those groups (Subgroup action)

3 - Articulate a framework for referencing SDO-published standards such that everyone can digitally reference these in the same way, regardless of who's doing the implementation (BH action in conjunction with PA)

4 - Prepare version 4 of the Gitlab SVC page incorporating the various insights from Mtg#4 and circulate to UNTP-Conformity for feedback (BH Action)

5 - Seek advice on which UNTP group is tasked with maintenance of the Conformity Topic Classification, move it to the appropriate Gitlab page and also advice the owner that the Waste Framework Directive is missing from the references (ZZ action)

6 - If a particular scheme requires all CABs assessing to their scheme to use a hierarchical structure for criteria then should this be accommodated as an extension (Gitlab open issue #344) or must we update the Core conformity credential structure (Subgroup to action as part of engagement with implementors)

7 - Gitlab open issue #79 has implications for defining where observations finish and CA begins, so BH to draft response based on insights from Mtg#4 and circulate for feedback before annotating the Gitlab issue log.

8 - Confirm whether the scheme header/vocab structure allows reference to scheme endorsements (BH action)

9 - Steve Capell is to investigate any implications for UNTP information security in light of the EU CapGemini initiative

#### Close -

## 2025-09-02 Meeting Summary
UNTP Conformity Meeting #3 - 2 September 2025

### Attendance
Brett Hyland
Phil Archer
Gideon Richards 
Zach Zeus
Steve Capell
Ulas Nalbantoglu 
Ladin Camci 
Neil Savery
Alison Jose
David McNeil 

### Item Discussion

#### Welcome & Rules of participation (BH) Per slides.

#### Participant intro (All)

#### Outstanding Action items:
1. CEFACT Expert registration interface - Problem acknowledged, fix requested, Zach to chase up - **New Action 1 (ZZ)**

2. Edit of SVC Gitlab page - Circulate again for further review after Eurozone holiday - **New Action 2 (BH)**

3. Conformity examples - agreed on the need for a new Sub-group to be formed - volunteers requested **New Action 3 (BH)**

**Discussion:**
Steve: Concentrate not just on edge cases but also formalise some routine examples and highlight any progress towards comparability of conformity outcomes across different schemes

Gideon: we have a baseline MRA/MLA but this will be tested when different scheme types both fall under a MLAMRA

Steve: Maybe schemes can recognise each other under mutual acceptability

Gideon: We must recognise the commercial nature of Schemes and rely on objective information

#### Open issues assigned to group (ZZ)

**Open Issue # 344:** https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/344

        **Discussion**

        Gideon: need to be clear on what is a Scheme (eg, contract between a CAB and a Client)

        Phil: can have a flat list that is mapped to a hierarchy using a schema

        Gideon: cognizant of ‘pick&choose’ standards like IFRS 

        Steve: a question would be - has anyone ever seen a certificate of conformity issued by a CAB that had anything other than a flat list of assessments?

        BH: flat list would obviously be the current norm, so if someone can help express the idea of a schema for mapping such to a hierarchy in terms that non-IT folk can understand - Phil Archer? **New Action 4 (BH)**

**Open Issue # 343:** https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/343

Incorrectly assigned ! Organise transfer to Tech group **New Action 5 (ZZ)**

**Open Issue #79:** https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/79

**Discussion**

Complex question - raises issues of reliability (objective evidence), the need for an incentive in place for providing factual outcomes and consideration of varying local legislative compliance rules. All to give consideration to this complex issue to help clear this longstanding open issue **New Action 6 (All)**

Alison queried information security issues in light of CapGgemini https://www.capgemini.com/solutions/eu-ai-act-compliance

Steve will investigate implications **New Action 7 (SC)**

#### Close -

## 2025-08-13 Meeting Summary

Meeting 13 August 2025 11pm CEST

### Attendance:

Roger Meikle 
Ulas Nalbantoglu
Brett Hyland
Zach Zeus
Andrew Wheeler 
Adrienna Zsakay 
Emiliano Sune
Gideon Richards
Jose Saiz de Oneñaca
Rembrandt Koppelaar 
Todd Taylor
Ryan Colker
Ladin Camci
Matthias Prellwitz
Martin Pompéry
Leslie Lopez Aria

### Item Discussion

#### Welcome & Rules of participation (BH) Per slides.

Per slides.
**Action 1:** Participants encouraged to register as CEFACT experts.

https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration

#### Participant intro (All) -

#### Outstanding Action item: Presentation from SVC ad hoc sub-group (BH)
Per slides

#### Open issues assigned to group (ZZ)
Open Issue #344: https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/344
Open Issue #343: https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/343
Open Issue #79: https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/79

**Action 2:** Group to consider the above and to either directly comment in GitLab or notify BH of interest in contributing to offline work on these issues

#### Gitlab changeover

GitHub now moved to UNICC GitLab
Updated links:
UNTP Conformity Credential page:  https://untp.unece.org/docs/specification/ConformityCredential
UNTP Conformity Vocabulary page: https://untp.unece.org/docs/specification/ConformityVocabularyCatalog
Issues list: https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues

**Action 3:** BH to circulate a MS Word edited version of the Gitlab SVC page for review/comment

#### Technical discussion (ALL)

Group sees value in a set of detailed worked examples, to highlight possible edge cases.

Chat comments from RK:  
What nesting types and degrees of nesting are allowed. Few cases that may be useful (perhaps not clear enough yet) 
- Example 1 - can a criterion be nested to multiple scheme credentials - Company A needs to provide data under Sustainability Scheme AA, Scheme BB, Scheme CC, Scheme DD, all because each brand mandates a different sustainability schemes.. Each of these have the same criterion (ID=URI...)
- Example 2 - can a sub-criterion link to a criterion that links to multiple sustainability schemes ; and can a sub-criterion also a be a criterion in another scheme - Company A measures sub-criterion Water consumption which is a criterion for resource consumption, which is part of a circular economy sustainability scheme credential (for example WBCSD circular economy measurement scheme). Company A has the same data but as a criterion Water consumption under an ESG sustainability scheme
Example 3 - can part of a Scheme conformity vocabulary be linked to another scheme - Scheme AA has Criteria 1 to 15, Scheme BB has criteria 7 to 15, Is there a 'smart way' to re-use these in the vocabularies.

**Action 4:** Ideas sought on how to convincingly demonstrate the power and/or limitations of the various combinations of DPP, DCC and SVC to address a realistic range of conformity examples (CAB & Scheme volunteers?)

#### Close -

## 2025-07-15 Meeting Summary

### UNTP Conformity Group Meeting minutes

Meeting 15 July 2025 10am CEST

### Attendance:

Roger Meikle
Ulas Nalbantoglu
Kylie Sheehan
Alison Jose
Roberto Perez-Franco
Brett Hyland
Zach Zeus
Alex Lubbock
David McNeil
Andrew Wheeler
Jeff Ruddle
Kris Tucker
Lalit Mehta
Adrienna Zsakay
Emiliano Sune
Ann Dao
Brad Moore
Martin Michelot
Phil Archer
Neil Savery
Gideon Richards
Christof Ameye
Jose Saiz de Oneñaca
Anil Jauhri
Rembrandt Koppelaar
Alice Paisley-Carruthers
Richard Kubwalo
Michael Shea

### Item Discussion

#### Welcome & Rules of participation (BH) Per slides.

Action 1: Participants encouraged to register as CEFACT experts.
https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration

#### Participant intro (All) -

#### Existing UNTP Conformity Implementations (ZZ) For information

#### Terms of reference & Rec 49 (BH) Per slides

#### Github walk-through (ZZ)

    Links:

1. http://untp.unece.org/docs/specification/ConformityCredential
2. http://untp.unece.org/docs/specification/ConformityVocabularyCatalog
3. https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues

#### Technical discussion (ALL)

Focus on Sustainability Vocabulary as the major new work item. Some lack of clarity identified as to the nature and granularity of information in attestations that will be required to “unambiguously reference conformity criteria (from standards or regulations) they are based on, requiring each criterion to have a globally unique identifier”.  
Action 2: To translate this expectation into language actionable by CA professionals, initial scoping to be provided ahead of the August meeting by a volunteer group [Ulas, Gideon, Jeff, Brett]

#### Close -

---

## UNTP General Updates

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

## Terms of Reference

Following the split of the technical work on the core UNTP into four working groups, the former central UNTP Working Group will transition into a General UNTP Group. This group will serve as a hub for coordinating and sharing information and updates on the UNTP and the progress of the technical working groups. The group is open to anyone interested in learning about the UNTP and interoperability in the exchange of ESG data across global supply chains. It also provides a welcoming entry point for newcomers to the UNTP who may wish to engage more deeply with one of the technical working groups. As well as providing updates and general information about the UNTP, the group offers opportunities to ask questions and participate in discussions about the opportunities and challenges of the decentralized, interoperable exchange of verifiable, trustworthy and reliable ESG data. The General UNTP Group meets monthly, on the last Thursday of each month and is moderated by the UN/CEFACT Secretariat.

## Mailing List

A group mailing list is maintained and can be used by any list member to post messages to the group. The list also maintains an archive of all messages sent to the group.

- To [join the mailing list](https://gaggle.email/join/untp@gaggle.email) - your request will be reviewed by a list administrator.

## Meetings

UNTP general update meetings are held monthly, on the last Thursday of each month at 10:00 a.m. CET / 8:00 p.m. AEDT.

**[Add UNTP to your Calendar](https://www.addevent.com/calendar/Ed909942)** (you can subscribe to the entire calendar or just add specific events)

## Previous Meetings

Previous meeting dates, recordings, and minutes are summarised below with the most recent meeting at the top.

| Date       | Summary                                                                                                                                                                                                                                                                                                                                                                                                         | Recording                                                                                                                    |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
|2026-04-30| [The meeting focused on the upcoming public review of UNTP, with v0.7 to be released in early May and v1.0 expected around August. Steve and Matthias outlined the GitLab-based feedback process, presented a new explainer video, and addressed questions on implementation approaches, cross-jurisdiction data sharing, Chinese data protection laws, and intellectual property.](#2026-04-30-meeting-summary)|video not recorded|
|2026-03-26| [The meeting covered working group updates on conformity, technical, supply chain, and adoption progress, preparation for v0.7 public review, website updates including core vocabulary and taxonomies, business case templates, and sector-specific developments including hydrogen and textiles.](#2026-03-26-meeting-summary)|video not recorded|
|2026-02-26| [The meeting covered UNTP development progress toward v0.7 and v1.0, working group updates, sector-specific adaptations, stakeholder engagement including European Commission collaboration on supply chain sustainability legislation, and new participant introductions.](#2026-02-26-meeting-summary)|video not recorded|
|2026-01-29| [The UNTP general meeting introduced the protocol’s role as an industry-neutral digital framework for verifiable, interoperable supply chain data, outlined working group progress and adoption priorities, and confirmed plans for implementation guidance and a public review of UNTP v1.0 in Q2](#2026-01-29-meeting-summary)|[video](https://us02web.zoom.us/rec/share/brwlueVUM0Gp5Um2j6uAGv4hjgF6aTiH_iL3-j-uEM9QUzjtjZYcFFEiWbGRu1Ib.lr3264_98qPDfzsj)|
|2025-09-18|[The meeting confirmed that the UN Secretariat will assume hosting of broader UNTP update sessions while Steve and others focus on advancing working groups, improving transparency, developing a sustainability taxonomy, and engaging with worker-voice platforms and market surveillance authorities.](#2025-09-18-meeting-summary)| [video](https://us02web.zoom.us/rec/share/EYAy75uB5hKJfu3Zlnsh8mXuaOXQnXj94Hk8agFav1o-4gghTCmpr9pvWWlwLdHK.tn81dcyPZceEw-8i)|
| 2025-09-04 | [The UNTP information group meeting reviewed updates from conformity, adoption, supply chain, and technical working groups, and brainstormed concrete use cases—ranging from sustainable finance and packaging compliance to livestock traceability, Scope 3 emissions, waste/materials management, and data centers—to shape pilots and the emerging Value Assessment Framework.](#2025-09-04-meeting-summary) | [video](https://us02web.zoom.us/rec/share/Igpg3jPX4lWk_HwhfoFgveMflg8DgUzBt4Ux4ZfQ_AbAZep_LuoM33YmLwh8RpJU.PwPC3BAlTuejLKfU) |
| 2025-08-21 | [The UNTP general updates meeting focused on improving communication and scheduling, introducing new participants, and prioritising the development of clear governance, onboarding, and support frameworks for industry extensions as the critical pathway to validating UNTP in real-world sectors.](#2025-08-21-meeting-summary)                                                                             |  [video](https://us02web.zoom.us/rec/share/6wt91uvU8PNyo8y_BphZVUJB1cYyYQLEwmhIXIa5lE0Chlc-gpgi0vV312c2GkoO.FIKTbb39sHrzp4Jk) |
| 2025-08-07 | [The UNTP meeting provided updates from all working groups, confirmed the migration to UN GitLab, discussed governance of industry extensions, clarified UNTP’s role versus regulatory passports, and identified key actions on adoption, conformity, supply chain, and technical leadership.](#2025-08-07-meeting-summary)                                                                                     |  [video](https://us02web.zoom.us/rec/share/qVsuFOeg2AhjswEKcSOaF69aHgnz-neIIxm9rhb8Qa9nPiIhRUufFBVEl2AAQoUr.uHEncjE3fFApbF_U) |

## 2026-04-30 Meeting Summary

### Quick recap

The meeting focused on the upcoming public review of the United Nations Transparency Protocol (UNTP), with Steve and Matthias providing updates on the standard's development and governance structure. They explained that version 0.7 would be released for public review in early May, with version 1.0 expected around August, and outlined the process for providing feedback through GitLab issues. The team presented a new explainer video about UNTP, which received positive feedback from participants. Questions were addressed regarding implementation approaches, data sharing across jurisdictions, and intellectual property considerations. The conversation ended with a reminder that the next monthly update would be held on the first day of May.

---

### Next steps

**Matthias**

* Share the presentation slides to participants at the end of the meeting.

**Steve**

* Put up real verifiable credential examples with rendering templates in the next day or two.
* Produce approximately one explainer video per week during the public review period.
* Send out emails to notify implementers if substantive changes are made based on feedback.

**UNECE_Immanuela**

* Post all public review links into the chat.

**Collaboration**

* UNECE: File approval request with the Bureau this week for public review.
* UNECE: Launch public review process officially by second week of May.
* UNECE: Freeze version 0.7 on the UNCFACT specification site for public review.
* Steve and team: Embark on more expansive collaboration and marketing program over the next few weeks.
* Steve and team: Push a series of announcements about collaborations with Responsible Business Alliance, Global Battery Alliance, ISO, and others.

---

### Summary

#### UNTP Public Review Preparation

The meeting focused on the upcoming public review of the United Nations Transparency Protocol (UNTP). Steve explained that the team has been working on finalizing technical details, including schema fixes, vocabulary completion, and reference examples. He introduced new features such as classification taxonomies for conformity and metrics, and highlighted the updated governance model that separates technical implementations from business communities. The group discussed how different industry sectors can leverage UNTP while maintaining consistency through a hierarchical structure with a common trunk (UNTP) and branching sectors. The public review is expected to launch in the next day or two.

---

#### UNTP Public Review Process

The meeting focused on the public review process for the UNTP (United Nations Transparency Protocol) standard. Matthias explained that the standard has completed intensive development work and is now entering the review phase, with public review expected to launch in early May. Emanuela detailed how participants can provide feedback through the UNCFAC public review page, UNTP webpage banner, and GitLab issues system. Steve clarified that the public review process will be similar to the existing development process, with increased transparency through GitLab issues tracking. The team confirmed that slides and links would be shared with participants after the meeting.

---

#### UNTP Version 0.7 Public Review

The team discussed the upcoming public review of UNTP version 0.7, which is now considered stable enough for pilot implementations. Steve clarified that while version 0.7 is a beta version, it can be shared and reviewed by other federations without waiting for version 1.0, which is expected around August 2026. Matthias explained that only normative parts of the GitLab UNTP site are subject to public review, and the team shared useful links for accessing the public review materials and providing feedback.

---

#### UNTP Version 0.7 Implementation

The group discussed implementation recommendations for version 0.7 of UNTP. Steve recommended building against the frozen 0.7 version rather than tracking the working progress version, citing the difficulty of building on a moving target. He explained that the feedback mechanism would send emails with a ready-made template to public review, with substantive comments potentially becoming GitLab tickets. When asked about integration, Steve clarified that UNTP is primarily a publish and discover mechanism rather than a system-to-system API exchange, focusing on human-readable and machine-readable credentials that can be discovered through identifiers like barcodes or GLNs.

---

#### UNTP Implementation Discussion Meeting

The meeting focused on discussing the UNTP (United Nations Transparency Protocol) and its implementation. Steve explained how to submit comments on UNTP specifications, recommending separate comments for each page or URL to ensure proper association with the relevant parts of the site. The group watched and discussed a new explainer video about UNTP, which received positive feedback for its high-level overview. Participants also asked questions about the potential impact of Chinese data protection laws on UNTP implementation and about intellectual property rights related to customizing UNTP for specific sectors. Steve clarified that UNTP's IP is owned by the UN and freely available for use and modification, with a process in place for registering and publishing sector-specific extensions. The next meeting was scheduled for the first day of the following month.

---

## 2026-03-26 Meeting Summary

### Quick recap

The meeting focused on updates from various working groups including conformity, technical, supply chain, and adoption groups regarding the United Nations Transparency Protocol (UNTP) development and implementation. Key discussions centered around the progress of UNTP specifications, website updates, and preparation for public review processes, including new content and business case templates. The meeting also addressed technical aspects of the protocol, implementation approaches, and sector-specific developments while encouraging feedback and participation from interested parties.

---

### Next steps

* **Constantin Pittrov**: Raise a ticket or write an email about sensor data integrity proofs concerns for the hydrogen sector digital product passport implementation.
* **Steven**: Upgrade the test service to version 0.7 before formal release.
* **Harley Thomas**: Connect with Stephan from UNISOT regarding textile working group participation.
* **Matthias Altmann**: Connect interested parties with stakeholder forum contacts for textile sector work.
* **UN/Matthias**: Send out announcement for 0.7 public review within a week or two.
* **Implementers (general call)**: Register intent to implement on the implementers page and test digital product passports on the self-service test harness once upgraded to 0.7.
* **Anyone interested**: Test the AI prompt business case template using company annual reports and provide feedback on its usefulness and accuracy.
* **Anyone close to mentioned standards/initiatives**: Review the alignment page and provide feedback on assessment of how UNTP relates to various technical and business standards.

---

### Summary

#### UNTP Protocol Specifications Discussion

Matthias opened the meeting and announced that no presentation slides would be needed for updates, as information about working groups is readily available. He introduced himself as working with the United Nations Economic Commission for Europe on the United Nations Transparency Protocol (UNTP), a CFACT project nearing completion. The main focus of the discussion would be on the specifications of the UNTP that would be submitted for public review. The meeting was set to begin with updates from working groups, starting with the conformity group.

---

#### Conformity Credential Specification Update

Brett reported that the Conformity Credential Specification version 0.7 is now live on the UNTP site, along with the updated conformity vocabulary page. Harley updated on the Technical Working Group's progress, including work on selected disclosure of claims and upcoming focus on transparency graph validation to ensure data constraints are met across digital product passports and related systems. Harley invited interested individuals to join the Technical Working Group's efforts.

---

#### Digital Supply Chain Progress Update

The Supply Chain Working Group, led by Steven, reported progress on the digital product passport, digital facility record, and digital traceability events specifications, with updates made based on field feedback. The group is preparing for a 1.0 release after achieving testing and quality improvements in the 0.7 version. Michael from the Adoption Working Group discussed a strategic shift toward community-driven adoption, emphasizing the importance of activating communities of practice before extending functionality, with plans to reorient the website to reflect this new approach.

---

#### UN Transparency Protocol Updates Overview

Steven presented an overview of the UN Transparency Protocol (UNTP), emphasizing its purpose to facilitate automated and continuous compliance assessment rather than occasional manual audits. He demonstrated recent updates to the website, including new pages for core vocabulary and taxonomies, and highlighted changes to the Best Practices section addressing topics like variant-based disclosure and mass balance questions. Steven encouraged participants to review the updated content and provide feedback before the formal public review process begins in a week or two, and mentioned the addition of a business case template for potential implementation.

---

#### Business Case Template Updates

Steven discussed updates to a business case template that can generate tailored reports from company annual reports, though he noted it needs more testing to ensure accuracy. He announced significant updates to content explaining how their work relates to various technical and business standards, and mentioned plans for public review with a new feedback mechanism. Steven also mentioned that self-paced training materials with short videos are being developed, though these won't be ready for public review yet.

---

#### Website Review Process Preparation

The meeting focused on preparing for a website review process, where comments will be tracked as GitLab issues for transparency. Steven announced that version 0.7 is considered stable enough for implementers to test their digital product passport credentials on the self-service test harness, though the test service upgrade to 0.7 will happen before formal release. The meeting also included an invitation to join active Adoption Working Groups and information about signing up for the Adoption WG newsletter.

---

#### UNTP Framework Data Model Changes

Constantin asked about the exclusion of integrity proofs from sensor data in visibility events in the UNTP framework. Steven explained that there were changes between versions 0.6 and 0.7 of the traceability events model, moving away from the previous GS1 EPCIS-based approach to create a more aligned and simpler model for those not using GS1 EPCIS. Steven noted that the new model offers two options: using GS1 EPCIS-CBV for existing EPCIS users or using UNTP's lifecycle event-focused model for others. The discussion was cut off before Steven could fully address Constantin's specific question about sensor data and integrity proofs.

---

#### UNTP Implementation and Development Discussion

The meeting focused on discussing UNTP implementation and development. Steven explained that while UNTP allows for hashed data links for audit purposes, this functionality hasn't been extensively tested in pilots yet, and encouraged Constantin to raise concerns for potential inclusion in the specification. The discussion covered mass balance verification approaches, where Steven described how pilots revealed that organizations wouldn't share sensitive supplier information, leading to a proposed solution where auditors could verify claims and issue credentials. Tobias from Preferred by Nature provided feedback on this approach, sharing experience from the forest sector and noting challenges with yield variations. The meeting also addressed sector-specific developments, with Matthias explaining that while UNTP is sector-agnostic, specialized working groups are developing sector-specific protocols, including one for textiles led by Harley Thomas. The session concluded with a discussion about blockchain implementation, where Steven clarified that while blockchain isn't required, it can be used as an optional trust anchor within UNTP's broader verifiable credentials framework.

---

## 2026-02-26 Meeting Summary

### Quick recap

The meeting focused on updates and progress of the United Nations Transparency Protocol (UNTP), including its development, working groups, and implementation across various sectors. Participants discussed the upcoming release of version 0.7 and plans for version 1.0, as well as progress on sector-specific adaptations and interoperability efforts. The session also highlighted ongoing stakeholder engagement, new participant introductions, and collaboration with European Commission departments on supply chain sustainability legislation.

---

### Next steps

* **Steven**: Release draft version 0.7 of UNTP (digital product passport, digital facility record, and digital traceability events) in about 2 weeks.
* **Brett**: Pull across updated UNT Vocabulary page after the next Conformity meeting on the 10th of March.
* **Brett**: Pull across Conformity Credential page for public review (essentially ready, may happen later today).
* **Harley**: Continue working on variant-based disclosure solution and invite stakeholders to review and contribute.
* **Harley**: Address durable storage problem for digital product passports when manufacturers go out of business.
* **Harley**: Work on Persistent Identifiers issue regarding what happens if identifier schemes cease to operate.
* **Michael**: Provide more information about potential summer event for software implementers and community members in upcoming meetings.
* **Steven**: Make it clearer how to find information about sector-specific implementations through the UNTP site when releasing version 0.7 in a few weeks.
* **Christian**: Finalize documents about the six working groups for textile stakeholder forum.
* **Christian**: Reach out to stakeholders next week with options for engaging in textile working groups.
* **Matthias**: Send information to Michaela about UNTP and how it relates to EU legislation on supply chain sustainability and human rights due diligence.
* **Matthias**: Reach out to European External Action Service in future Brussels visits.
* **Helmer**: Contact Michael to connect to the Adoption Working Group.
* **Helmer**: Contact Adrienna regarding communication work stream in Adoption Working Group.

---

### Summary

#### UNTP Information Call Overview

Matthias opened the second information call on the UNTP, explaining its purpose as an awareness-raising and engagement session rather than a technical meeting. He introduced the development of the United Nations Transparency Protocol (UNTP) and mentioned the existence of four technical working groups and a team of specialists supporting the project. Matthias encouraged participants to introduce themselves and provided information about communication channels, including a mailing list and Slack channel, for ongoing engagement. The meeting was transitioning to updates from working groups, with Steven scheduled to present on the supply chain working group's progress.

---

#### UNTP Version 0.7 Release Update

Steven announced that the Supply Chain Working Group is preparing to release version 0.7 of UNTP in about two weeks, which will address around 30 open issues including updates to digital product passport, digital facility record, and digital traceability events. Brett reported progress on the Conformity Working Group's two main work items: the UNT Vocabulary page and the Conformity Credential page, both of which are nearly ready for public review. The Conformity Credential page is expected to be published imminently, while the UNT Vocabulary page updates will be completed after the next Conformity meeting on March 10th.

---

#### Technical Working Group Progress Update

Harley from the Technical Working Group discussed their work on variant-based disclosure and challenges around durable storage and persistent identifiers. The group meets fortnightly on Thursdays at 9am CET and is seeking contributions to address these technical issues. Michael from the Adoption Working Group reported that they are proceeding with the release schedule, particularly for version 1.0 expected mid-year, and are building support for implementers. The Adoption Working Group, with over 50 members, meets fortnightly on Thursdays at alternating times to accommodate global participation.

---

#### UNTP Stakeholder Engagement Update

Christian Hudson provided an update on the team of specialists, which coordinates stakeholder engagement for the UNTP. He explained that the team has secured agreement from key players in the textile chain to facilitate the uptake of UNTP at scale through specific deployments and use cases. Christian also mentioned their work on extending this approach to the agri-food sector, focusing on EU deforestation regulation compliance and interoperability between different tools. The team is currently working on specifying these deployments and mapping the landscape to identify synergies between initiatives.

---

#### UNTP Protocol Implementation Discussion

Catalina from Drive Sustainability and Stefan from UNISOT introduced themselves as new participants interested in learning about the UNTP protocol and its implementation for supply chain sustainability. Jodie from ASOS explained her role in working with 800 partner brands and the potential for incorporating DPPs into their platform, while Helmer shared details about his research on DPPs for the cotton supply chain in collaboration with MoSIP. Michael encouraged all participants to join the UNTP GitLab repository to contribute to the development process, even if their involvement is in an observational capacity.

---

#### EU Supply Chain Sustainability Discussion

Matthias welcomed Michaela Dodini from the European External Action Service to the meeting and explained that UNTP works closely with European Commission departments including DG Grow and DG Just on supply chain sustainability legislation. Michaela expressed interest in learning more about UNTP's role in implementing EU legislation on human rights due diligence. Bogharald discussed his involvement with WeBuild's work on business wallets, noting that European public sector organization wallets will be mandatory and should be interoperable globally, with practical progress being made on implementing credentials like IBAN for cross-border e-invoicing.

---

#### UNTP Protocol Implementation Discussion

The meeting focused on the UNTP protocol and its implementation across different sectors. Matthias explained how UNTP is a sector-agnostic protocol designed to make traceability systems interoperable, with sector-specific adaptations called sector extensions or protocols. Steven clarified that UNTP's scope extends beyond digital product passports to include facility records and conformity credentials, and emphasized its focus on facilitating performance claims against various schemes and regulations rather than replacing them. The discussion covered ongoing implementations in agriculture, critical minerals, and textiles, with the 0.7 release expected in two weeks and 1.0 release planned for mid-year. Christian provided an update on working groups, indicating that documents have been finalized and stakeholders will be reached out to for engagement next week.

---

## 2026-01-29 Meeting Summary

### Quick recap

The meeting began with Steve and Sabir clarifying meeting time details before discussing challenges around digital product passports and supply chain interoperability.  

Matthias introduced the UNTP general information sessions, including presentations from Steve on the standard protocol for maintaining verifiable data sharing across supply chains, followed by updates from working group leads on conformity, technical, and adoption aspects.  

The meeting concluded with discussions about UNTP implementation, including government roles, training needs, and the importance of digital infrastructure development, along with announcements about upcoming events and the public review of UNTP version 1.0.

### Next steps

- **Steve**  
  - Create a generic group user account in Zoom so anyone can start a meeting  
  - Send meeting materials to Zach  
  - Update the calendar event with the new meeting link  

- **David Jensen**  
  - Work with Michael Shea offline to develop playbook/guidance for developing countries on digital infrastructure needed for UNTP adoption  

- **Adoption Working Group**  
  - Collect feedback from community members via Slack on what training, guidance, and communication materials are needed  

- **Brett**  
  - Update the UNTP website to reflect the latest thinking from the Conformity Working Group in coming weeks  

- **UNECE / UNTP Team**  
  - Share presentation slides via the UNTP mailing list  

- **UNTP Team**  
  - Launch public review process for UNTP in the second quarter of this year  
  - Reach out to the Digital Public Goods Alliance to make the protocol a digital public good  
  - Reach out to the GovStack partnership / ITU regarding open-source building blocks for UNTP  

### Summary

#### Time zone meeting coordination

Steve and Sabir clarified a time zone confusion, confirming the meeting was scheduled for 10:00 AM CET. Steve noted he would keep the discussion short and send information to Zach.

#### Digital passports and interoperability challenges

Participants discussed challenges with digital product passports and supply chain interoperability.  

Key points included:

- Most software providers now prioritize interoperability rather than attempting to dominate supply chains  
- Need to clarify concepts around conformity credentials and product passports  
- Some confusion exists about UNTP being perceived as a policy instrument rather than a digital implementation framework for verifiable due diligence at scale  

#### UNTP general information session overview

Matthias introduced the UNTP general information sessions and encouraged newcomers to introduce themselves via chat.  

Key points:

- Monthly sessions with updates via mailing list  
- Agenda: UNTP introduction, working group updates, and open Q&A  
- Development process is transparent, inclusive, participatory, and volunteer-led under UN/CEFACT  
- Deliverables are technology-neutral and non-proprietary  

#### UNTP: supply chain data protocol

Steve presented UNTP as a standard protocol for maintaining the value of evidence for sustainable behavior through scalable, verifiable, and trustworthy data sharing.

Highlights:

- Share data once, reuse many times  
- Reduce costs and audit fatigue  
- Support decentralized ecosystems  
- Building blocks: facility records, product passports, independent assessments  
- Ongoing work on mass-balance for bulk materials  
- Invitation to join the Supply Chain Working Group (meets fortnightly)

#### UNTP working groups overview

- **Conformity Working Group** (Brett): implementing UNECE Recommendation 49 on transparency and trust  
- **Technical Working Group** (Harley): identity resolution and decentralized access control  
- **Adoption Working Group** (Michael): communication, training, and business elements  

Participants were encouraged to join relevant working groups.

#### UNTP implementation and market surveillance

Matthias explained that while UNTP is primarily targeted at companies, governments play a role in:

- Building digital infrastructure  
- Supporting market surveillance  

Michael and Steve discussed development of implementation guidance and playbooks, particularly for developing countries.

#### UNTP adoption working group update

Adrienna requested detailed feedback on training, guidance, and communication needs via Slack.  

Additional points:

- Use Slack and mailing list for communication  
- Trust anchors often rely on government implementation  
- Spain and India are committed to implementing the GRID project  

#### UNTP trust architecture implementation

UNTP instruments existing trust architectures to make institutional and social trust networks digitally verifiable.

Key enablers:

- Registry operators  
- Rule definers  
- Software systems  
- Industry associations  

Discussion included:

- Multiple identifiers and crowd-sourced data  
- Cross-source approaches involving audit firms and brands  
- Potential for labels to add trust measures linked to UNTP  

#### UNTP and DPP interoperability

Discussion covered how UNTP can complement the EU Digital Product Passport (DPP) and benefit SMEs, particularly in developing countries, through interoperability between traceability systems.

Matthias announced:

- Public review of UNTP v1.0 planned for Q2  
- Side session at OECD Forum on Due Diligence in the Garment and Footwear Sector – 9 February  
- Monthly UNTP sessions continue on the last Thursday of each month  

## 2025-09-18-meeting-summary

**Date:** 18 Sept 2025
**Facilitator:** Steve Capell

### Attendees (as identified in transcript)

* **Steve Capell** (Chair/Facilitator)
* **Brett**
* **Adrian**
* **Suzanne**
* **Nick Smith**
* **Jason**
* **Michael Shea**
* **Abdel (Canada)**
* **Other participants** (UN Secretariat: Matthias mentioned; extension groups referenced)

### Key Discussion Points

#### 1. Meeting Timing & Participation

* Low attendance from US despite meetings scheduled for their time zone.
* Suggestion: shift meetings to European/Asia-Pacific time zone.
* UN Secretariat (Matthias and team) will take over hosting of general update meetings, inviting wider participation from member states, UN organizations, and ISO.
* Expectation: meetings may grow to 100–200 participants.

#### 2. Transition of Role & Focus

* Steve will step back from chairing general updates, focusing instead on:

  * Supporting **supply chain working group** (towards spec v0.7).
  * Helping extension groups (textiles, batteries, electronics) increase transparency and visibility.
* Emphasis on making working group outputs more **public and transparent** (using GitLab and updated websites).

#### 3. Website & Domain Issues

* Current GitLab-based site has long, confusing URLs.
* UN is developing custom code for custom domains (planned: `untp.unaicc.org`).
* Jason registered temporary domain **untp.site** and set up forwarding for easier access.
* Steve will circulate new access details to participants.

#### 4. Worker Voice & Alternative Performance Evidence

* Steve reported on discussions with **Open Supply Hub, Wikirate, ISARA Institute** regarding forced labour monitoring.
* Issues raised with traditional audit regimes: audits often ineffective at surfacing forced labour issues.
* Alternative: bottom-up, worker-voice approaches generating reliable evidence.
* Discussion on whether these could be packaged as **verifiable credentials** to flow down supply chains.
* Agreement that this needs further exploration and engagement with relevant groups.

#### 5. Sustainability Taxonomy & Data Points

* Current UNTP specification pages are too technical for business users.
* Stakeholders request clarity on **sustainability data points** (e.g., carbon, water use, labour rights).
* Steve proposed accelerating development of a **standardised sustainability topic map/taxonomy**, linked to IFRS, SASB, ESRS for corporate reporting alignment.
* Consensus:

  * Remove redundant “scorecard” boxes (emissions/circularity performance).
  * Use **claims categorised by sustainability topics** as the basis for digital product passports.
  * Add more **examples and clearer guidance** for industry groups.

#### 6. Extension Groups & Industry Engagement

* Growing interest from industries (e.g., tyres) to start new extension groups.
* Matthias to coordinate extension group engagement.
* Steve encouraged greater cross-group visibility and participation.

#### 7. Market Surveillance & Customs Authorities

* Adrian reported from **German Market Surveillance Forum**: EU moving towards requiring full DPP body for surveillance, not just identifiers.
* Steve noted parallel discussions with customs authorities globally (India, Norway, UK, US) around using **verifiable credentials** for invoices, waybills, and product passports.
* Trend: shift from **self-declared compliance** to **data-driven compliance**, where authorities assess obligations directly from trade data.
* Consensus:

  * Product passport complements traditional trade docs (invoices, waybills).
  * UNTP architecture supports discoverability and decentralisation, avoiding centralised databases.

### Actions

1. **Steve** – Draft communication to worker-voice platforms (Open Supply Hub, Wikirate, ISARA) inviting them to engage with UNTP performance evidence discussions.
2. **Steve** – Circulate announcement of new temporary domain `untp.site` for easier access.
3. **Steve & Brett** – Initiate work on sustainability taxonomy/topic map aligned with IFRS/ESRS/SASB.
4. **Extension Group Leads (Matthias to coordinate)** – Improve transparency of textile, battery, and electronics groups; encourage publication of work in GitLab.
5. **Adrian** – Follow up with EU’s Franziska Thibault for clarity on DPP integration with market surveillance systems; share slides from Berlin forum in Slack once available.
6. **Jason** – Finalise publication of adoption commitments in GitLab.
7. **All participants** – Provide feedback on sustainability vocabulary draft shared by Steve; suggest refinements.

## 2025-09-04-meeting-summary

**Date:** 4 September 2025
**Format:** Virtual meeting (recorded)

### Participants (Named in Discussion)

- **Steve** – Chair/facilitator (Speaker 1)
- **Gideon** – Conformity group participant (Speaker 2)
- **Matthias** – Adoption group lead, UNEC representative (Speaker 3)
- **Nick Smith** – Supply chain working group (Speaker 4)
- **Harley** – Technical working group lead (Speaker 8)
- **Adriana** – Participant raising value assessment and waste/materials management topics (Speaker 5)
- **Martina** – Impact, global strategy and partnerships (Speaker 6)
- **Clary** – Participant focusing on packaging and finance (Speaker 7)

---

### Working Group Updates

#### Conformity Group

- Focused on **Conformity Vocabulary Catalog** and refining terms for conformity professionals.
- Exploring **credential types and use cases** (e.g., facility-level carbon footprint reports under GHG protocol).
- Challenge identified: **comparability across schemes** (e.g., carbon intensity standards, social welfare measures).

#### Adoption Group

- Currently defining **work packages** and assigning experts.
- Preparing an **FAQ document** to explain UNTP to non-technical audiences.
- Developing **Value Assessment Framework** page on UNTP site to measure impact against UN SDGs and donor metrics.
- Discussion around linking UNTP to **specific SDG targets**; recognition that broader societal value beyond SDGs should also be reflected.

#### Supply Chain Group (Nick Smith)

- Resumed engagement with **Global Battery Alliance (GBA)** on battery passport mapping.
- Working with **Chemex** on chemical supply chain mapping.
- Key issue: handling **multiple claims disclosure** and assigning access groups (government vs. customers).
- Noted overlap with conformity group on mutual recognition and disclosure consistency.

#### Technical Group (Harley)

- First meeting scheduled immediately after this call.
- Goal: **Version 0.7 of UNTP** by Christmas, resolving open GitLab issues.
- Workstreams include:

  - Identity Resolver
  - Decentralized Access Control
  - Verifiable Credentials profile harmonization
  - Verification rules and transparency graph interpretation

---

### Key Thematic Discussions

#### Value Assessment Framework

- Aim: Close feedback loop on adoption and measurable impact.
- Challenge: Defining **metrics that demonstrate societal benefits** as well as company-level business cases.
- OECD frameworks noted as reference points; need for UNTP-specific adaptation.

#### Use Cases and Value Propositions

Participants proposed diverse potential pilots and applications:

- **Finance and Trade**

  - Tracking subsidies, tariffs, and credit incentives in supply chains (Nick).
  - Sustainable finance access and comparability of data for green bonds (Clary).
  - Microcredit and insurance for livestock in Africa, enabled by traceability (Matthias).

- **Circular Economy & Waste**

  - Solid recovered materials and Basel Convention complexity (Gideon).
  - Proposal to shift terminology from “waste” to **materials management** (Adriana).
  - Packaging schemes and compliance with EU PPWR (Clary).

- **Scope 3 Emissions & Traceability**

  - Brands (e.g., sportswear) needing supplier data for emissions reporting (Martina).
  - Issues of **inconsistent Scope 3 data** and reliance on industry averages (Steve).
  - Proposal to develop **hierarchies of default values** (global → regional → national) for comparability (Gideon).

- **Sector-Specific Applications**

  - **Data centers**: traceability of building materials, electronic inputs, and energy sourcing (Adriana).
  - **Biosecurity** flagged as potential future use case (Harley).

---

### Closing

- Agreement to **collect, categorize, and publish use cases** in an online spreadsheet, inviting wider mailing list input (\~250–300 members).
- Recognition that regulatory-driven use cases (e.g., EUDR, beef exports, carbon rubber) remain strong drivers for pilots.
- Meeting adjourned on time with thanks to all participants.

## 2025-08-21-meeting-summary

**Format:** Virtual call
**Attendance (selected named participants):**

- **Steve Capell** – Chair, UNTP coordination
- **Matthias** – UN Secretariat / adoption group lead
- **Adriana** – Adoption group
- **Clary** – Adoption group
- **Michael** – Adoption group
- **Zach** – Technical contributor
- **Virginia** – Participant (clarification on UNTP scope)
- **Ben Hayworth** – Wholechain (traceability provider, guest introduction)
- **Other attendees:** Nancy, Gideon, and additional unnamed participants

---

### 1. Meeting Logistics and Calendar Challenges

- Steve reported ongoing issues with calendar invitations, especially with ICS subscription links and Zoom link errors.
- Proposal: keep meetings fixed at **8am and 8pm UTC**, allowing participants to choose the time that suits their region.
- Discussions highlighted difficulties caused by daylight saving shifts and clashes with other working group calls (notably the adoption group).
- Agreement: continue with the dual UTC-based schedule, improve clarity of communication, and test invites more rigorously.

---

### 2. Purpose of the General Updates Meeting

- This meeting is now positioned as a **status-sharing forum**, rather than a decision-making body.
- Role: to update broader UNTP participants (\~200+ mailing list members) on activities across the **four working groups** (Supply Chain, Conformity, Adoption, Technical) and the **industry extensions**.
- Aim: funnel interested participants into more focused working groups or industry extension projects.

---

### 3. New Participant Introduction

- **Ben Hayworth (Wholechain)**:

  - Traceability solution provider with strong experience in seafood, beef, and leather.
  - Expertise in GS1 standards, integration with ERP systems, FDA Rule 204 compliance.
  - Connected via Jason Berryhill (CEO).
  - Expressed enthusiasm to contribute to UNTP work.

---

### 4. Focus Topic: Industry Extensions

### Concept and Rationale

- **Extensions** tailor the UNTP core to specific industries (e.g., agriculture, textiles, batteries, automotive).
- Core UNTP remains abstract and interoperable; extensions add **sector-specific identifiers, vocabularies, and conformity criteria**.
- Goal: enable **cross-industry interoperability** (e.g., livestock → leather → automotive seats) without requiring each sector to directly coordinate.

#### Governance

- Extensions should ideally be governed by **industry associations** (e.g., Global Battery Alliance, International Copper Association, Responsible Business Alliance).
- Governance principles:

  - Open and transparent development.
  - Outputs published under permissive licenses.
  - Version management and public documentation.
  - Clear extension owner with trusted convening power in the sector.

#### Communication Gaps

- Current UNTP site lists extensions but lacks **contacts, engagement pathways, and sub-pages**.
- Proposal: each extension should have a **dedicated sub-site or page** (example: Australian Agriculture Traceability Protocol).
- Extensions are the “acid test” of UNTP – demonstrating adoption, sectoral value, and cross-sector use.

---

### 5. Key Discussion Points

- **EU Deforestation Regulation (EUDR):**

  - Clary raised whether EU would accept UNTP credentials.
  - Steve noted EU has only recently proposed DPPs as carriers of compliance data.
  - Too early for formal acceptance, but agriculture and textiles extensions may drive progress.

- **Extension Methodology & Support:**

  - Agreement that extensions need **structured onboarding guidance** to avoid chaos.
  - Options discussed: onboarding toolkits (videos, PDFs), extension governance group, cross-working group input (especially technical and adoption).
  - Concern: volunteer bandwidth and funding for supporting multiple extensions.

- **Consistency vs Flexibility:**

  - Debate over whether extension websites should follow a common template/branding.
  - Consensus: allow flexibility in look/feel, but require consistency in **vocabularies, semantics, and technical interoperability**.

- **Scaling Participation:**

  - Adriana: adoption group could draft guidelines and communication frameworks for extensions, then hand over governance.
  - Matthias: plan to create a dedicated **Extensions Technical Working Group** to support methodology and interoperability testing.
  - Clary: scalable onboarding tools will be crucial for broad adoption.

---

### 6. Outcomes and Next Steps

- Reinforce meeting schedule at **8am/8pm UTC** and improve calendar communication.
- Engage industry extension owners more actively; add **contacts, scope, and participation info** to the UNTP website.
- Develop **extension governance and onboarding methodology** (initially via adoption group, later via extensions working group).
- Explore scalable support models and onboarding toolkits.
- Treat extensions as the **core path to real-world validation** of UNTP.

---

**Closing:**
Steve thanked participants, noting the current phase as “peak risk and confusion” but also a crucial moment to ensure extensions succeed as the foundation for real UNTP implementation.

## 2025-08-07-meeting-summary

**Date:** 7 August 2025
**Facilitator:** Steve Capell

---

**Participants (named in transcript):**

- Steve Capell (Chair, UNTP Lead)
- Brett (Conformity Group Lead)
- Michael (Adoption Group Lead)
- Nick (Supply Chain Group Lead)
- Zach (Technical Support/Contributor)
- Ashley (Technical Admin, GitLab/registration guidance)
- Harley Thomas (appointed Technical Group Lead – mentioned, not speaking)
- Matthias (UN Secretariat / Extensions Group)
- Virginia (Participant – login/access questions)
- Detlef (New participant – trust infrastructure/identity focus)
- Secretary’s representative (UN Secretariat, Speaker 6 – expressed support)
- Bertus (Participant – traceability/source discussion)
- Adriana (Adoption Group – language clarification)

---

**Opening Remarks (Steve Capell):**

- Reiterated UN code of conduct and non-commercial nature of meetings.
- Clarified IP contributions are shared freely under UNTP.
- Reviewed subgroup structure: four working groups (Supply Chain, Conformity, Adoption, Technical), with momentum building at different rates.
- Emphasised that detailed technical/content work should occur in working groups, not the main call.
- Proposed distinction between:

  - **Steering Group Meetings** (small, closed, UN-organised, addressing tricky project issues).
  - **Open Communication Meetings** (general updates, broad participation, training, and topic-of-the-day discussions).

- Announced migration from GitHub to UN-hosted GitLab for accessibility and neutrality. A new domain (e.g., `untp.unece.org`) is being prepared.

---

**Secretariat Statement (Speaker 6):**

- Confirmed full support for Steve’s proposal.
- Clarified: steering groups will remain closed; this open meeting is a communication forum for broad participation.

---

**Participant Introductions and Questions:**

- **Detlef:** Introduced himself, interested in global trust infrastructure alignment (EIDAS in Europe vs. global registries). Asked which subgroup this belongs in.
- **Steve’s Response:**

  - Two UNTP trust dimensions:

    - _Identity integrity_ → handled by UN Digital Identity Anchor (moving to Global Trust Register project).
    - _Claim veracity (sustainability claims)_ → remains in UNTP Conformity Group.

  - Suggested Detlef engage with both the Global Trust Register and UNTP Conformity Group.

- **Virginia:** Asked about login issues with new UN GitLab.

  - **Steve & Ashley’s Response:** Registration now possible, but contribution requires approval by project leads. Viewing remains public. Ashley clarified contributors can comment and raise issues, but need extra steps for specification edits.

---

**Working Group Updates:**

- **Supply Chain Group (Nick):**

  - 14 members (11 active). Seeking more practitioners with real-world data and schemes.
  - Focus: mapping between business disclosure schemes and UNTP data framework.
  - Current work:

    - Battery Passport extension mapping.
    - Chain-of-custody for chemicals in Europe.
    - Potential extensions (Coppermark paused; possible shift to leather/textile).

  - Emphasised importance of cross-group communication (esp. with Conformity).
  - Implementation guidance in development.
  - Steve added: extensions will be industry-led, governed by UN, but overlap/conflict management remains a challenge.
  - **Matthias (Extensions Group):** Extensions require trusted industry associations as leads. Difficult sectors (e.g., textiles) will need strong consensus for semantic interoperability.

- **Conformity Group (Brett):**

  - 58 members, strong global expertise.
  - Kickoff meeting on 15 July with \~28 participants.
  - Work focuses on _Conformity Vocabulary Catalog (SVC)_ – a logical model linking conformity outcomes to claims in product passports.
  - Subgroup (IEC, ISO, UCAS experts) confirmed model validity; will report back.
  - Next meeting scheduled for next week.

- **Adoption Group (Michael):**

  - 25–26 members. Meetings scheduled in multiple time zones.
  - Recently reissued Terms of Reference, broken into work packages. Assignments underway.
  - Priority: define certification/implementation processes for organisations wanting to adopt UNTP.
  - Coordination with Zach on GitLab processes.
  - Collaboration with Matthias on extension governance.
  - Steve shared a prototype AI tool (ChatGPT-based) to generate draft business cases for UNTP adoption from annual reports – group invited to test.

- **Technical Group:**

  - New lead appointed: **Harley Thomas** (Australia, long-time UNTP contributor).
  - Will lead ongoing technical development, including decentralized access control.

---

**Other Project Updates:**

- **Meeting Management (Steve):**

  - Transitioning to Google Calendar for meeting subscriptions.
  - UNTP website will host a unified calendar.
  - Challenges with ICS file integration across platforms remain unresolved.

---

**Topic of the Day: UNTP vs. Regulatory Passports (Steve):**

- Clarified differences:

  - **Regulatory Passports (e.g., EU DPP):** consumer-facing, legal declarations for finished products.
  - **UNTP Passports:** focus on upstream supply chain transparency (shipments of raw materials, intermediates, or components).

- Each UNTP DPP applies only to the product/material at a given transaction step, not the entire end-to-end chain.
- Challenge: managing confidentiality and supplier disclosure limits.

**Discussion:**

- **Bertus:** Raised parallels with diamond trade (“blood diamonds”) – importance of source-level traceability and risks of obfuscation.
- **Steve:** Confirmed UNTP supports redaction/obfuscation; highlighted ongoing challenges with bulk commodities and mass balance verification.
- **Adriana:** Suggested introducing clearer taxonomy (e.g., “Supplier DPP”, “Primary Resource DPP”) to avoid confusion, especially given SME participation in global trade.

---

**Action Items:**

1. Steve to circulate link to GitLab registration guidance and confirm new workflow.
2. Ashley to ensure contributor instructions are clear in GitLab templates.
3. Nick to update Supply Chain group pages on UN GitLab with Steve’s help.
4. Brett’s subgroup to report back on SVC findings to Conformity Group.
5. Michael to assign Adoption Group work packages and circulate priorities.
6. Steve to circulate AI business case tool for group testing and feedback.
7. Secretariat/Matthias to finalise governance process for extensions (avoiding overlaps/conflicts).
8. Explore taxonomy/terminology refinements for different categories of DPPs (Adoption Group).
9. Steve to consolidate UNTP meeting calendar and improve cross-platform subscription options.

---

## Meetings

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

# UNTP Meetings

UNTP meetings are organised into three tiers with different audiences and purposes. Minutes of all meetings are public. See the [governance overview](../index.md) for details on observer and contributor roles.

## General Update Meetings

**Open to anyone.** The monthly general update meetings are intended for anyone interested in staying informed about UNTP developments — whether you are evaluating UNTP for your organisation, tracking progress as an observer, or simply curious. No registration or commitment is required.

| Meeting | Audience | Frequency | Details |
|---|---|---|---|
| [General Updates](generalUpdates.md) | Anyone interested in UNTP | Monthly | Progress updates, Q&A, community announcements |

## Working Group Meetings

**Open to all, intended for active contributors.** The four specialist working groups are where the UNTP specifications are developed and maintained. Anyone may attend, but these meetings are designed for participants who want to engage deeply with the specification content and potentially contribute changes. Contributing participants must be [registered UN experts](https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration).

| Working Group | Scope | Details |
|---|---|---|
| [Adoption Working Group](adoptionGroup.md) | Business case, implementation guidance, promotion of new implementation commitments | [Terms of reference and meetings](adoptionGroup.md) |
| [Supply Chain Working Group](supplyChainGroup.md) | DPP, DFR, and DTE specifications | [Terms of reference and meetings](supplyChainGroup.md) |
| [Conformity Working Group](conformityGroup.md) | DCC and CVC specifications | [Terms of reference and meetings](conformityGroup.md) |
| [Technical Working Group](technicalGroup.md) | VCP, DAC, and IDR specifications, reference implementations, test suites | [Terms of reference and meetings](technicalGroup.md) |

## Steering Group

**Closed meeting, public minutes.** The steering group provides overall governance and coordination for UNTP. It includes membership from each working group, UN secretariat representatives, and coordinates with the extensions governance board and other DPP initiatives. Steering group meetings are not open to general attendance, but all meeting minutes are published.

| Meeting | Membership | Details |
|---|---|---|
| [Steering Group](steeringGroup.md) | Working group leads, UN secretariat, invited stakeholders | [Minutes and decisions](steeringGroup.md) |

## [Meeting Archive](meetingArchive.md)

Archive of past meeting notes and recordings from before the current working group structure was established.

---

## UNTP Meeting Archive

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

In August 2025, the UNTP project team completed it's split into four working groups and a steering group. This page contains UNTP and Recommendation 49 team meeting minutes since the project started in November 2023 until the split into separate working groups in August 2025.

## Previous Meetings

| Meeting    | Summary                                                                                                                                                                                                                                                                                                                                                              | Recording                                                                                                                                            | Transcript                                                                                                                   |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| 2025-07-24 | [The UNTP coordination meeting on 24 July 2025 focused on resolving calendar and GitLab access issues, progressing textile and copper extensions, aligning supply chain and conformity efforts, and onboarding new contributors.](#2025-07-24-meeting-summary)                                                                                                       | [video](https://us02web.zoom.us/rec/share/6-bXQ0Iww9Ar9qv5GPejo37wgDewbg0mMtiymCIwXcBcHQ_WibiYwlPqahsEGSWo.WBO6sWfFbXQWh9WX)                         | [transcript](/meetings/2025-07-24-Recording.txt)                                                                             |
| 2025-07-10 | [The 10 July 2025 UNTP Steering Group meeting addressed the adoption of Recommendation 49, the migration to UN-hosted GitLab, the formation of an extenders governance framework, working group progress, and challenges in confidentiality, mass balance accounting, and trust communication in supply chain traceability.](#2025-07-10-meeting-summary)            | [video](https://us02web.zoom.us/rec/share/H4uFlvs6S_3keaIRbLZyCEji3Xba28RUi9_XNfdhTBUhLF-bj20zuwm2u3sFipN0.3z6fxOkMHWvz6dV4)                         | [transcript](/meetings/2025-07-10-Recording.txt)                                                                             |
| 2025-06-26 | [The UNTP steering group discussed preparations for the upcoming Geneva plenary and Recommendation 49 approval, addressed mailing list and meeting coordination issues, reviewed subgroup progress, and explored governance for future UNTP extensions and interoperability.](#2025-06-26-meeting-summary)                                                           | [video](https://us02web.zoom.us/rec/share/OcIx5O0HxKBaRWtrqYI2SASCAveWewG41hQdpc59y-nvBil9YMJrXxcKmWSrwjE.pXM_7O156GH_SsSe)                          | [transcript](/meetings/2025-06-26-Recording.txt)                                                                             |
| 2025-06-12 | [The UNTP meeting formalized four new working groups—Conformity, Product Passports, Adoption, and Technical—to advance implementation readiness ahead of the upcoming UN plenary, with subgroup leads outlining plans and new collaborations announced with GBA, ITC, and VC4Trade.](#2025-06-12-meeting-summary)                                                    | [video](https://us02web.zoom.us/rec/share/ncrJ1zDu8Ubfs9GsXKx-VTvmDRgN1OwFhD8TRyutxVJCw40ISJmOHdfBts2dv5FL.6hPttmI5YEHlzk2z)                         | [transcript](/meetings/2025-06-12-Recording.txt)                                                                             |
| 2025-05-29 | [The UNTP Working Group discussed copper supply chain traceability challenges, mass balance and book-and-claim models, credential mapping within UNTP, and previewed Tier 3 testing for verifying relationships between multiple verifiable credentials.](#2025-05-29-meeting-summary)                                                                               | [video](https://us02web.zoom.us/rec/share/41Qwol7tGBl8ISM0zvDioLy8dTggFFRFZmA_Kc1lM5HBf0YsaoGnNXc09PD49XhE.pxfdPbPOVjaihWXJ)                         | [transcript](/meetings/2025-05-29-Recording.txt)                                                                             |
| 2025-05-14 | [The UNTP Technical Working Group reviewed and approved schema updates, demonstrated a new validation and mutual verification testing pipeline, discussed data model interoperability across ecosystems like GS1, and prepared for the upcoming 0.6 release with contributions from new and returning participants.](#2025-05-14-meeting-summary)                    | [video](https://us02web.zoom.us/rec/share/busUMzc0brcbdFVBFXPpfUUOnyMRVZgO2HssV_-LcnVvkVmBOFNJgTUu8OUvVF7c.FUuxe8bXmucP1joO)                         | [transcript](/meetings/2025-05-14-Recording.txt)                                                                             |
| 2025-04-17 | [The UNTP team met to discuss updates on Recommendation 49, roadmap milestones, pilot project planning across sectors, subgroup formation, and key terminology and data structure decisions, welcoming several new participants to the initiative.](#2025-04-17-meeting-summary)                                                                                     | [video](https://us02web.zoom.us/rec/share/CEZuLKkqS1OmzPXhinc1UDmLeDEn-ottyW17ZzG3BgYa8WpTWPArTvOQGKz88bc3.QXWJ6am-Kt7S_bRx)                         | [transcript](/meetings/2025-04-17-Recording.txt)                                                                             |
| 2025-04-03 | [The UNTP working group, led by Steve and Brett, reviewed draft terms of reference for subgroups and introduced a proposed Sustainability Vocabulary Catalog to standardize and digitize conformity criteria, while participants raised concerns around governance, classification, and AI integration.](#2025-04-03-meeting-summary)                                | [video](https://us02web.zoom.us/rec/share/4gZmOdWIZ6qO3X3kSnHFfOEIXKTCwNeurVx3lBHk8LjWA2sWFZFADkoBOWT2V4Gp.bTZgsXCWizVbmj9B)                         | [transcript](/meetings/2025-04-03-Recording.txt)                                                                             |
| 2025-03-20 | [The UNTP meeting focused on strengthening governance, introducing subcommittees for scalability, and advancing work on a machine-readable sustainability criteria catalog to support digital product passports.](#2025-03-20-meeting-summary)                                                                                                                       | [video](https://us02web.zoom.us/rec/share/peh1TXSSwynNkdt3NupX2t23TVtOz4ygI5JDoFfXfadYxM5irHhgYS2VTX3XxCz_.FjrlrwC7vj1qTyDS)                         | [transcript](/meetings/2025-03-20-Recording.txt)                                                                             |
| 2025-03-06 | [The meeting covered updates on GS1's commitment, improvements to the information architecture, the UNTP Playground's credential validation features, and a discussion on whether bulk materials require a separate Digital Material Passport, concluding that further testing is needed.](#2025-03-06-meeting-summary)                                              | [video](https://us02web.zoom.us/rec/share/LS0ZS4wMm45ZUBZNrH-oQJkpT2R7a4F8Ma9GOeW6ZHk1HwhLFPMVdVXI8Vy14IEK.lej3QWxOntusXGsK)                         | [transcript](/meetings/2025-03-06-Recording.txt)                                                                             |
| 2025-02-20 | [The meeting focused on preparing UNTP for public review, addressing governance, simplifying specifications, improving usability, and ensuring alignment with Recommendation 49 while planning for future pilots and implementations.](#2025-02-20-meeting-summary)                                                                                                  | [video](https://us02web.zoom.us/rec/share/hIBsxqAMi7tw1z5Rj-me3ZtbOS-IQnuJR1zYSuER41676BM_JO8lNPi6MEAqhtrL.Sto8AESpUGhaph5Z)                         | [transcript](/meetings/2025-02-20-Recording.txt)                                                                             |
| 2025-02-06 | [The UNTP meeting focused on reviewing change requests, refining the identity resolver framework, approving the verifiable credentials update, discussing implementation guidance, exploring certification and governance models, and addressing open issues for future development.](#2025-02-06-meeting-summary)                                                   | [video](https://us02web.zoom.us/rec/share/ayxfoRJH0z9FXI25UWNuZ4KQ0LQ7N3GoLHTxbz-wTW4fjjOfMjQ3_zr-uNp6jUhk.dwHfJ3YszOvW9aLb)                         | [transcript](/meetings/2025-02-06-Recording.txt)                                                                             |
| 2025-01-23 | [The meeting focused on enhancing UNTP governance, fostering community engagement through CAP, refining chain of custody models, and exploring tools for effective collaboration, setting the stage for further iterations and sector-specific applications.](#2025-01-23-meeting-summary)                                                                           | [video](https://us02web.zoom.us/rec/share/kQt_d4JsLMrfy3iCGf1hoD04b-7Rg5ksuGML-Sj8wSMZL7l3uWqhkO4HEPpr8nBG.eHleGSxocBLfQumY)                         | [transcript](/meetings/2025-01-23-Recording.txt)                                                                             |
| 2025-01-08 | [The meeting addressed progress on UNTP implementations, focusing on decentralized access control, sustainable mining, and selective disclosure, while initiating discussions on managing mixed commodities and advancing public review of specifications.](#2025-01-08-meeting-summary)                                                                             | [video](https://us02web.zoom.us/rec/share/u7PDvJjbvgcJui79hqIYoh-CAzgoKVZtt5fieXWZkenCMkMCpbnmA4XKrEJjBJsT.eIZrcLXd5eSP72e2)                         | [transcript](/meetings/2025-01-08-Recording.txt)                                                                             |
| 2024-12-12 | [The meeting discussed progress on UNTP collaborations, technical updates, and pilot projects, with participants emphasizing interoperability, schema flexibility, and industry-specific implementations for 2025 goals.](#2024-12-12-meeting-summary)                                                                                                               | [video](https://us02web.zoom.us/rec/share/XLYqWl-SuqhWB8BvudCHewjB-ds60wD6AyDAafxVB0SSKdm4PBbCKm0bTiY_xYRy.4SVCRR3yzrsJ2w4c)                         | [transcript](/meetings/2024-12-12-Recording.txt)                                                                             |
| 2024-11-28 | [The meeetingunderscored the progress in developing agricultural extensions for UNTP, the usability of tools like the playground, and the importance of addressing business challenges alongside technical ones.](#2024-11-28-meeting-summary)                                                                                                                       | [transcript](/meetings/2024-11-28-Recording.txt)                                                                                                     | [video](https://us02web.zoom.us/rec/share/HVySh1IQGfWbWrZzJDwVqWZgTFhhJV3JKboYcS50zvr2B4jx5lU9UBsNCxCKtmuF.8BMJxuD20MrOmRko) |
| 2024-11-14 | [The UNTP working group discussed recent industry commitments, advanced business case documentation, and proposed a community-driven testing support ecosystem to enhance UNTP implementation and interoperability.](#2024-11-14-meeting-summary)                                                                                                                    | [video](https://us02web.zoom.us/rec/share/diHIQ18nhFsX7h5bEaNia9n9FxuS3GYBaLZdSp7MxEKVjhu7PiuVi3VYhUYaCd5r.lnj0ChgXR4TskJuU)                         | [transcript](/meetings/2024-11-14-Recording.txt)                                                                             |
| 2024-10-31 | [The team discussed updates on UNTP governance, digital product passport collaborations, and the methodology for industry-specific extensions, focusing on security, visibility, and implementation compliance.](#2024-10-31-meeting-summary)                                                                                                                        | [video](https://us02web.zoom.us/rec/share/IHBm8m69es-EaEl_Je01fsqUNAzY4QuumwJZaeI0ihah6wrZADAmyRC2bK8Jt-lZ.3FxFLsOE9Fjkvsvx)                         | [transcript](/meetings/2024-10-31-Recording.txt)                                                                             |
| 2024-10-17 | [The team discussed the latest updates on UNTP credential implementation, focusing on testing, identity resolution processes, and potential trust anchors for bulk commodity tracking.](#2024-10-17-meeting-summary)                                                                                                                                                 | [video](https://us02web.zoom.us/rec/share/EgwRbS_jvLwwsLqJ4ddM55Je-OnpxkvDxcn6WhsWwZZwKS35Ts6JDXneurvWfxgQ.D9GdxgqUbFOPmCv3)                         | [transcript](/meetings/2024-10-17-Recording.txt)                                                                             |
| 2024-10-03 | [The meeting focused on reviewing and refining the business case content for Digital Product Passport implementation, addressing technical bugs, and preparing the materials for broader feedback and publication.](#2024-10-03-meeting-summary)                                                                                                                     | [video](https://us02web.zoom.us/rec/share/KDARf7eHzuXRW4F2OkrF7JgNgMvnSHkBx_3UXf3LEpAo2jTSYTghVBv2gvAr75ig.QsEeOK3KSd4VlcnE)                         | [transcript](/meetings/2024-10-03-Recording.txt)                                                                             |
| 2024-09-19 | [The meeting focused on reviewing new registration requests, addressing syntax and human-readability issues in traceability events, planning updates to the REC 49 policy document, and discussing business case development for public and private sector value.](#2024-09-19-meeting-summary)                                                                      | [video](https://us02web.zoom.us/rec/share/ZzkAqJFNRuDgJ9On4Uvg7cp2MU-1N5Sas6GDK0VIVid00Zx9vYLdWe1gEZSCDm4F.VTPpBJyEtiQHYYgQ)                         | [transcript](/meetings/2024-09-19-Recording.txt)                                                                             |
| 2024-09-11 | [The meeting covered updates on standards integration, implementation commitments from key stakeholders like the British Columbia government, and the plan to freeze UNTP version 0.4.0 for upcoming pilot programs.](#2024-09-11-meeting-summary)                                                                                                                   | [video](https://us02web.zoom.us/rec/share/TLDhFQPgXJ8CksSqR3CvWp3je0oiBuJyS8o0djx4shDXVha71lJMuPU94m4UMPhW.sT8AgEAZJkesR_FQ)                         | [transcript](/meetings/2024-09-11-Recording.txt)                                                                             |
| 2024-09-05 | [The meeting focused on updates and discussions around the development of a global digital product passport, business case frameworks, and the importance of community activation in implementing UNTP extensions.](#2024-09-05-meeting-summary)                                                                                                                     | [video](https://us02web.zoom.us/rec/share/AC4BGb0zEH0UFQBTw1V0wgbT-oMlsSKGYDxZV08tU_uhS7CW_W6ODIor8k1vGH4X.4H1NEA5vs-2yl-hZ)                         | [transcript](/meetings/2024-09-05-Recording.txt)                                                                             |
| 2024-08-28 | [The meeting focused on updates and discussions around the development of a global digital product passport, business case frameworks, and the importance of community activation in implementing UNTP extensions.](#2024-08-28-meeting-summary)                                                                                                                     | [video](https://us02web.zoom.us/rec/share/Sul2KkyH8LYUiNJDTwT3JR9gNR4uxL8JGvPIvyp202fO-NfN2anAZtjRkFH4me9w.8hQdXJfine_JzV6b)                         | [transcript](/meetings/2024-08-28-Recording.txt)                                                                             |
| 2024-08-22 | [The meeting focused on refining the business case content, updating the digital product passport schema, and preparing to solicit implementation commitments as the team moves towards a stable 1.0 release by the end of the year.](#2024-08-22-meeting-summary)                                                                                                   | [video](https://us02web.zoom.us/rec/share/YWThMHYlAdjry0oG-4ytceAKGn-qUDW3cuGiP2hkBwMRMOiYWTsY5oeAwjgNsaiF.TljvfQcuaW-ckYbo)                         | [transcript](/meetings/2024-08-22-Recording.txt)                                                                             |
| 2024-08-15 | [The meeting focused on refining digital product passports, facility records, and conformity assessment schemes while establishing a working group to develop the business case pages.](#2024-08-15-meeting-summary)                                                                                                                                                 | [video](https://us02web.zoom.us/rec/share/4aCZG5zqAMVtI7wSYUFLsiWTWBrUnBU54WHuq5UL99BbtXc_n_2IzPOHfX7yUXWy.H-f8GsYaQm4RUyUI)                         | [transcript](/meetings/2024-08-15-Recording.txt)                                                                             |
| 2024-08-01 | [The meeting focused on refining the business case for the UNTP, discussing the inclusion of emissions and circularity performance in digital product passports, and balancing simplicity with the need for reliable data to encourage voluntary adoption.](#2024-08-01-meeting-summary)                                                                             | [video](https://us02web.zoom.us/rec/share/GWtQbYEYvwLllNWX_MU3sDngPkcl73prtAnNrsZ-BUKof611JFmf_SfpjjM-BHar.XJrZ23Mu-s3EkZiH)                         | [transcript](/meetings/2024-08-01-Recording.txt)                                                                             |
| 2024-07-25 | [The meeting focused on updates from recent presentations in Geneva, a planned demo on TrustGraphs, reviews of multiple pull requests, discussions on various issues including human observations as sensors, and setting action items for updating digital product passport pages and creating a glossary for standards and acronyms.](#2024-07-25-meeting-summary) | [video](https://us02web.zoom.us/rec/share/rXhYqvNX6fcC6acRfBmWGb5Yfe1tNemDuDhCNCdJjemMrUKiWHUTsnI9fOHQOUjg.ElNsOY95VnBDv5QO)                         | [transcript](/meetings/2024-07-25-Recording.txt)                                                                             |
| 2024-07-17 | [The meeting discussed integrating business experts, collaboration with CENELEC on global standards, and reviewing a significant pull request to enhance data model consistency and governance.](#2024-07-17-meeting-summary)                                                                                                                                        | [video](https://us02web.zoom.us/rec/share/9yfJtJ-BFGkrEEYemfpxJU-FhLilK6iMdWjk5-hao8Hvx8uBF5d_bR05WMc1GQIo.5OQR4eACNiJRyUNE)                         | [transcript](/meetings/2024-07-17-Recording.txt)                                                                             |
| 2024-07-04 | [The meeting focused on reviewing PRs for digital product passports, discussing the integration of JSON-LD and JSON Schema for transparency graphs, and planning next steps for refining and testing the models.](#2024-07-04-meeting-summary)                                                                                                                       | [video](https://us02web.zoom.us/rec/share/aDNOqKQ6itVCWtOlezhyhs4epYW6jiU6B7ZSKB4pOg5mMvH_rwOFWHblkd8vIg6v.xw2yXaIkKZbwyRSW)                         | [transcript](/meetings/2024-07-04-Recording.txt)                                                                             |
| 2024-06-27 | [The meeting focused on reviewing and addressing public comments on Recommendation 49, planning the consolidation of these comments over the weekend, introducing a new digital identity anchor credential, and discussing the governance and versioning of standards.](#2024-06-27-meeting-summary))                                                                | [video](https://us02web.zoom.us/rec/share/YSHGiEQEKosYGKgkhtcFr68qpnVtuLGrYMUBueSvgETyaZZ7B9oUT6dMPFDH5gdu.U3JwPcN8cEahYQbx)                         | [transcript](/meetings/2024-06-27-Recording.txt)                                                                             |
| 2024-06-19 | [The meeting focused on aligning implementation tools and conformity credentials with VCDM, renaming digital link resolver to identity resolver, restructuring the site, and discussing the use of the Jargon tool for generating context files.](#2024-06-13-meeting-summary)                                                                                       | [video](https://us02web.zoom.us/rec/share/huqG1vXNf21SH4fXNDzPPR4fIqg-OI0X3y0CeMpwRIfw6w6vf3nho1dExIoqIGOb.9G_tdVSmRB-eufKg)                         | [transcript](/meetings/2024-06-19-Recording.txt)                                                                             |
| 2024-06-13 | [TThe meeting focused on reviewing and merging key pull requests, discussing the UNTP architecture and methodology, and planning actions for schema and context file alignment.](#2024-06-13-meeting-summary)                                                                                                                                                        | [video](https://us02web.zoom.us/rec/share/R6x_ui0ZMeb7JwlERt_Vj3Ag7YIt8fJ_2e-AXZt_0xeQLY5_oma5pguUYvKqvhaN.r97B1NuWbPqM1ec2)                         | [transcript](/meetings/2024-06-13-Recording.txt)                                                                             |
| 2024-06-05 | [The meeting focused on improving meeting participation, managing transcription and summary processes, handling JSON schema and JSON-LD context differences, addressing challenges with semantic interoperability, and establishing principles for managing context files.](#2024-06-05-meeting-summary)                                                             | [video](https://us02web.zoom.us/rec/share/Vfcr6ZV7Bw0Z8uTKyM1_P8nLkpKaZU0VBLCH9Hlu4xRWbfD8tE5_gL6F87Ny7u3Y.jX5z3_867OAXwB3l)                         | [transcript](/meetings/2024-06-05-Recording.txt)                                                                             |
| 2024-05-30 | [The meeting focused on addressing pull requests, aligning with EU right-to-repair regulations, and discussing the challenges and strategies for maintaining and verifying digital product passports within the supply chain.](#2024-05-30-meeting-summary)                                                                                                          | [video](https://us02web.zoom.us/rec/share/vd5oKvWwlRDVlxImzoovy7VsocYbTZgTf5bwKjPuruXUBhPvWJodg24FAD_MLqps.9E3v0xVpCeyefeqD)                         | [transcript](/meetings/2024-05-30-Recording.txt)                                                                             |
| 2024-05-23 | [The Working Group discussed updates to the digital product passport sample file, terminology adjustments, and the adoption of a "transparency graph" to better align with the VC data model and enhance data validation and provenance.](#2024-05-23-meeting-summary)                                                                                               | [video](https://us02web.zoom.us/rec/share/SdwSmtENQawZpdXpnurPv5wkP4L-mg2pjbRdzK1wi2itXXkgXbe6OBT4RqImwD5m.KKXfqVY1njdUt3ax)                         | [transcript](/meetings/2024-05-23-Recording.txt)                                                                             |
| 2024-05-16 | [In the meeting, the team discussed updates to project examples and data models, alignment with international standards, and strategies for maintaining interoperability and accurate mappings in linked data while preparing for upcoming pilot implementations.](#2024-05-16-meeting-summary)                                                                      | [video](https://us02web.zoom.us/rec/share/B4wZX-BYXPWg0tuDWSotj572qmUKWOHF0l4k2EFiLI_A7_V83gMATKN_-Nfx9sNR._aXbdvOi2fICOFRy)                         | [transcript](/meetings/2024-05-16-Recording.txt)                                                                             |
| 2024-05-09 | [The meeting focused on aligning digital product passport models with the VC data model, removing scoring elements to simplify the structure, and discussing the implementation of trust graphs and multilingual support using governed overlays.](#2024-05-09-meeting-summary)                                                                                      | [video](https://us02web.zoom.us/rec/share/eABzv6OBR_sjL3y9LgHzaVgKchOM8oyZjdS2GnM63Lzanf1yr0kcEAAppJ9sPRDc.6883MbcV4-aA3GPY)                         | [transcript](/meetings/2024-05-09-Recording.txt)                                                                             |
| 2024-04-25 | [The meeting focused on reviewing and processing pull requests, assigning stale issues, and emphasizing broader collaboration within the group, with key discussions on traceability event schema updates and the verification of identifiers.](#2024-04-25-meeting-summary)                                                                                         | [video](https://us02web.zoom.us/rec/share/8QIKuM-X89PbBR7dVxag34wEhR6P2152HDkv0TwHNAj_nldDc_T73Ngkf3mKAU6T.SqXk0F1TscOaMYZ1)                         | [transcript](/meetings/2024-04-24-Recording.txt)                                                                             |
| 2024-04-18 | [The April 18, 2024, meeting focused on streamlining specification sections, reviewing and merging several pull requests, and discussing key issues related to verification and trust graphs, with commitments to create examples and improve meeting efficiency.](#2024-04-18-meeting-summary)                                                                      | [video](https://us02web.zoom.us/rec/share/yLKR1_JwcBlaKM2fSzd1eXZ05cSsD2Qyvnj0u4KjrRGaom6dDq_TM6aKPpe04Uct.anqfPC0BPiHwfb1u)                         | [transcript](/meetings/2024-04-18-Recording.txt)                                                                             |
| 2024-04-11 | [The meeting focused on discussing industry use cases for the Digital Product Passport, trust and credential verification methods, and agreeing on future tasks and pilot projects, with an emphasis on more active use of Slack for ongoing discussions.](#2024-04-11-meeting-summary))                                                                             | [video](https://us02web.zoom.us/rec/share/RaLiDGP2pyCmOAPFqpJRcEnF9ojg8WabMv1L2xuKSHoKlAJCyCW3F_AZcvyVPptx.N2Z6iGWG3RjymbqN)                         | [transcript](/meetings/2024-04-10-Recording.txt)                                                                             |
| 2024-04-04 | [The meeting focused on refining digital product passports and verifiable credentials, emphasizing interoperability, traceability, and the development of clear business requirements to guide technical decisions.](#2024-04-04-meeting-summary)                                                                                                                    | [video](https://us02web.zoom.us/rec/share/zVeXVEPoDTQ47d6_rczVyrNDGiD6Vc21fy64MkDh2a4165B59cZ4ZIqCA1oF2gMX.htabo2zwpxjDMvmI)                         | [transcript](/meetings/2024-04-04-Recording.txt)                                                                             |
| 2024-03-28 | [The meeting focused on discussing and refining the digital product passport (DPP) structure, addressing the challenges of integrating claims and evidence at different levels, and planning further updates and reviews to ensure its practical implementation.](#2024-03-28-meeting-summary)                                                                       | [video](https://us02web.zoom.us/rec/share/HrpLjWU_cLtjo-gHIAs9xjSRIm_NzfVhxzld18XPPYMQKSpwcWo_b_H_7RRrwiwD.QqsvfDxuKkcwmxZD?startTime=1711569572000) | [transcript](/meetings/2024-03-27-Recording.txt)                                                                             |
| 2024-03-14 | [The team discussed the successful submission of the policy document, agreed on weekly meetings, reviewed technical specifications and PRs, and demonstrated GitHub contribution processes.](#2024-03-15-meeting-summary)                                                                                                                                            | [video](https://us02web.zoom.us/rec/share/fdrIhDXrEvwLcB5v08kdraTfC_7ywRWeYFa-J-LTpGxnCDdxVM6iwyQze_P2BX_z.c7dLspw0q6KCGQ0e?startTime=1710399547000) | [transcript](/meetings/2024-03-15-Recording.txt)                                                                             |
| 2024-02-29 | [The team discussed updates from Europe, aligned on the structure of recommendations and challenges in their document, and set a plan for finalizing the document for submission by the end of the week.](#2024-02-29-meeting-summary)                                                                                                                               | [video](https://us02web.zoom.us/rec/share/KQlvFMg2SSlNxsExQJhqzvVaRJSLUPv5SO2W6ze9qqd_Dqpos4blNxAELBbXan-f.z26h2PCKv-krbiX8)                         | [transcript](/meetings/2024-02-29-Recording.txt)                                                                             |
| 2024-02-15 | [The meeting focused on refining the policy document draft by incorporating feedback, simplifying technical language, and aligning with global frameworks to prepare for final review and public release.](#2024-02-15-meeting-summary)                                                                                                                              | [video](https://us02web.zoom.us/rec/share/FHQ1wz0jlb5cRl8mGeZXgYHE_jzbosvnTqBJCsxtxsdsGt_BJGiVx0gywOnj2vua.9B0mR7dX6nBcVzDg)                         | [transcript](/meetings/2024-02-15-Recording.txt)                                                                             |
| 2024-02-01 | [The meeting focused on refining the structure and content of the policy document, discussing the sustainability pledge, addressing collaboration challenges in value chains, and planning the next steps for finalizing the draft for public consultation.](#2024-02-01-meeting-summary)                                                                            | [video](https://us02web.zoom.us/rec/share/ZvEFJYTwbM9ER-gZ4jX6_4-gviurC4P7Kn2WgYnIfahG3mLx77hz7NMM_c8284h5.s3UwWFYpeCIt6aMr)                         | [transcript](/meetings/2024-02-01-Recording.txt)                                                                             |
| 2024-01-25 | [The meeting focused on refining the structure and content of the policy document, discussing the sustainability pledge, addressing collaboration challenges in value chains, and planning the next steps for finalizing the draft for public consultation.](#2024-01-25-meeting-summary)                                                                            | [video](https://us02web.zoom.us/rec/share/XJ-SF0jKOj8BRMDStAWU2caoGfcxhW17ulwLAwhsLFfwOUt30eaQg5G92EEknvcm.z1USKwSJ38o6aYkC)                         | [transcript](/meetings/2024-01-25-Recording.txt)                                                                             |
| 2024-01-18 | [The meeting focused on reviewing GitHub issues, demonstrating verifier experiences, discussing schema context, developing a sustainability vocabulary, handling versioning and implementation profiles, and planning for industry-specific extensions of UNTP.](#2024-01-18-meeting-summary)                                                                        | [video](https://us02web.zoom.us/rec/share/oPEDPSpZGLBBP5qykEBDaG5NxxMrQu_snm3NmiqZQuGhBVxlWv5bf-70jeuqMvd5.S_8jH8Vk8IW57B0X)                         | [transcript](/meetings/2024-01-18-Recording.txt)                                                                             |
| 2024-01-11 | [The meeting focused on reviewing the registration status, introducing the structure of the GitHub repository for technical specifications, discussing key sections and their alignment with existing standards, and planning to split into separate technical and policy teams for focused work.](#2024-01-11-meeting-summary)                                      | [video](https://us02web.zoom.us/rec/share/jX87C2PZ55iY3hFW-5L2rroXL7HoGY20Qg_m2h0B6a92_u6nk7tKkvfUKfIW6HLp.c_0QNnRPl6anrzyW?startTime=1704956458000) | [transcript](/meetings/2024-01-11-Recording.txt)                                                                             |
| 2023-12-14 | [The meeting focused on revising the structure of Recommendation 49, enhancing communication strategies, inviting contributions, and planning technical content development for implementation, with follow-up actions and scheduling outlined.](#2023-12-14-meeting-summary)                                                                                        | [video](https://us02web.zoom.us/rec/share/gh8BWTuMrZL0TOka76YVHwbZ_ZTIPhCJTn4LJv7YbxhlK4ZOudb24I3J9t9m9zCE.v6Di5lRXOLHSLQMy)                         | [transcript](/meetings/2023-12-14-Recording.txt)                                                                             |
| 2023-11-30 | [The meeting focused on refining communication strategies and restructuring Recommendation 49 to align with previous UN recommendations, emphasizing flexibility, implementability, and stakeholder engagement.](#2023-11-30-meeting-summary)                                                                                                                        | [video](https://us02web.zoom.us/rec/share/3QJpW_xq7ljVf5UTWKtz_gCYrTO6cP5ZlsNZKhNccA0bY9iSfPcaFP6crO7jlFg.uotFEZa-l-bUgyI9)                          | [transcript](/meetings/2023-11-30-Recording.txt)                                                                             |

## 2025-07-24 Meeting Summary

#### Participants

- Steve Capell (Chair, UN/UNECE)
- Matthias Knappe (UNECE)
- Nick Boyland (Supply Chain Working Group)
- Zach (Conformity Working Group)
- Bertus (Rhino Alliance)
- Virginia (Calendar coordination concerns)
- Emiliano (Cortec / BC Provincial Government)
- Dan Miller (Entrepreneur, Fashion Sector, Berlin)
- Carolyn (Trey Surfer, Uruguay)
- Jason Berry Hill (mentioned, Holochain)
- Adrian (UNTP contributor)
- Suzanne, Harley Thomas, Gerhard Helmskerk (mentioned contributors)
- Nancy, Susanne (consultants)
- Hilary (Coppermark – mentioned)
- Others unnamed due to anonymity in transcript (e.g., Speaker 13)

---

#### Key Discussion Points

**1. Calendar and Meeting Access Issues**

- Persistent issues with ICS calendar invites not syncing with Outlook or Google Calendar.
- Emails from Jason Berry Hill (Holochain) caused confusion.
- Steve acknowledged the limitations of GitHub-based distribution and proposed exploring ICS alternatives.
- Bertus suggested a unified, subscribable calendar, referencing experience with Basecamp.

**2. Migration to UN-hosted GitLab**

- UNTP is moving from GitHub to a UN-hosted GitLab under the UN Open Source Programme.
- Benefits include broader global accessibility and greater UN control.
- Some functionality differences from GitHub noted, especially around self-registration.
- UNICC is considering allowing low-permission self-registrations for visibility and join requests.
- Participants acknowledged some friction but agreed the move legitimizes the platform under UN auspices.

**3. Extension Updates**

Textile Extension

- Led internally by UNECE with early testing planned for early 2026.
- Builds on Recommendation 46 and past garment sector work.
- Supported by brands and consultants (e.g., Harley Thomas, Gerhard Helmskerk).
- An external owner will be sought as maturity increases.

Copper Extension

- In collaboration with the International Copper Association.
- Will serve as a model for future extensions.
- Overlaps with Global Battery Alliance and Recommendation 49.
- Plans for a broader UN recommendation on critical raw materials.

**4. Supply Chain Working Group Update (Nick)**

- Focused on practical implementation support for scheme owners.
- Active collaboration with Global Battery Alliance (GBA); Coppermark contact pending.
- Initiated knowledge-sharing interviews, beginning with Harley Thomas.
- Will explore mass balance accounting for bulk materials, possibly with Adrian and Steve.

**5. Conformity Working Group Update (Zach)**

- 28 participants joined the kickoff.
- Formed a subgroup to focus on the Sustainability Vocabulary Catalog (SVC).
- Emphasized need to align with supply chain mappings (e.g., Coppermark).
- Discussed importance of communicating technical concepts in a business-friendly language.

**6. Adoption Working Group Update (Speaker 3)**

- Light attendance due to summer holidays.
- Discussed communications, including simplifying FAQ content for non-technical users.
- Aims to streamline community questions toward appropriate working groups.
- Work continues on the communications package; Adriana and Christoph are leading.

**7. Technical Group**

- No updates this week.

**8. New Introductions**

- Emiliano (Cortec): Supporting BC government's UNTP implementation.
- Dan Miller: Supporting fashion brands with extended producer responsibility (EPR) regulations.
- Carolyn (Trey Surfer): Experience with DPPs, plastics, and textiles – interested in collaboration.

#### Action Items

| Item | Owner                 | Description                                                                                                                            | Due                 |
| ---- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
| 1    | Steve                 | Resolve ICS/calendar invite sync issues (Google, Outlook, Apple) and evaluate centralized calendar solutions (e.g. Basecamp approach). | Before next meeting |
| 2    | Steve / Bertus        | Discuss feasibility of UNTP-wide subscribable calendar, possibly outside GitLab.                                                       | ASAP                |
| 3    | UNICC                 | Investigate support for low-permission self-registration on GitLab.                                                                    | In progress         |
| 4    | Matthias              | Continue development of textile and copper extensions and plan engagement with stakeholders.                                           | Ongoing             |
| 5    | Nick / Adrian / Steve | Hold scoping call re: interoperable mass balance accounting for upstream bulk materials.                                               | Next week           |
| 6    | Nick                  | Start GBA mapping; initiate contact with Coppermark and align with conformity group.                                                   | In progress         |
| 7    | Zach                  | Coordinate SVC definitions with supply chain mapping efforts.                                                                          | Ongoing             |
| 8    | Zach / Nick           | Connect with Hilary (Coppermark COO) for deeper collaboration.                                                                         | Next call           |
| 9    | Adoption Group        | Draft FAQs with non-technical language. Route questions appropriately from implementers/extenders.                                     | In progress         |
| 10   | Steve                 | Provide interim process for registration requests that can't be submitted on GitLab (e.g., via email).                                 | Immediate           |
| 11   | Newcomers             | Emiliano, Carolyn, Dan to review UNTP materials and identify areas for contribution.                                                   | Self-directed       |

## 2025-07-10 Meeting Summary

**UNTP Steering Group Meeting – Summary**
**Date:** 10 July 2025
**Chair:** Steve Capell
**Purpose:** Governance, roadmap, and technical coordination for UNTP implementation.

**_Participants_**

- **Steve Capell** (Chair, UN/UNECE)
- **Matthias Knappe** (UNECE)
- **Nick Smith** (Supply Chain Working Group Lead)
- **Michael Wild** (Adoption Working Group Lead)
- **Gideon** (Conformity Assessment Specialist)
- **Suzanne** (GBA Technical Lead, Conformity Group)
- **Anil Jauri** (New participant, India)
- **Ali** (Candidate Technical Lead)
- **Zach** (Mentioned as site maintainer)
- **Additional silent participants or late joiners unnamed in transcript**

**_Key Updates and Discussion Points_**

**1. Recommendation 49 Adopted by UN Member States**

- The plenary approved Recommendation 49, a policy guidance document that legitimizes UNTP without locking in specific architecture details.
- Annex 1 (detailed UNTP architecture) was removed to ensure long-term relevance of the policy.

**2. Transition from GitHub to UN-Hosted GitLab**

- UNTP is migrating to GitLab under the UN Open Source Program for better control and global access.
- Transition supports the forthcoming _Public Review_ of v0.6 (leading to v0.7 pre-release and eventually v1.0).
- Some participants expressed difficulty navigating Git platforms; Steve emphasized that technical leads can handle updates based on business user input.

**3. Launch of the Extenders Governance Group**

- Led by Matthias Knappe; aims to define the rights and responsibilities of "extenders" (sector-specific adaptation communities).
- Existing and forthcoming extensions include:

  - Global Battery Alliance
  - Responsible Business Alliance
  - Australian Agriculture
  - Built Environment
  - Textiles (forthcoming)

- A temporary governance task force is forming, likely to report through the Adoption Working Group.

**4. Technical Gaps Identified for Further Work**

- **Confidentiality vs. Transparency:** Need better documentation on how to protect sensitive upstream data while preserving verifiability and traceability.
- **Mass Balance Accounting for Bulk Commodities:** Standard approaches needed for digital traceability of commodities like grain or copper concentrate across platforms.

**5. Working Group Updates**

- **Supply Chain Working Group (Nick Smith):**

  - Focused on practical implementation support for copper and battery extensions.
  - Gathering lessons from early implementers.
  - Holding weekly meetings across time zones; welcomes new contributors.
  - Aims to build momentum through small deliverables.

- **Conformity Working Group (Suzanne):**

  - Kick-off meeting scheduled for next Tuesday.
  - Brett (lead) was not present, possibly due to calendar delivery issues.
  - Suzanne offered tech support for GitLab contributions.
  - Discussion on aligning scheme owners and conformity standards (e.g., ISO/CASCO, Coppermark).

- **Adoption Working Group (Michael Wild):**

  - Second call to follow this meeting.
  - Terms of reference and meeting schedules now online.
  - Grouping activities into work packages (e.g., business case development, comms, capacity building).
  - Encourages participation from those interested in ecosystem and extension onboarding.

- **Technical Group:**

  - No formal lead yet; Ali identified as strong candidate.
  - Steve currently acting as interim lead.

**6. Confidentiality vs. Trust Models**

- Steve presented a visual maturity model:

  - **Low Trust / High Duplication:** Ambit self-declarations with minimal evidence.
  - **Medium Trust / Medium Duplication:** Third-party audits generating conformity credentials.
  - **High Trust / Low Duplication (Future):** Selectively redacted verifiable graphs (e.g., using zero-knowledge proofs).

- Participants emphasized:

  - The need to communicate trust level clearly (Gideon).
  - Support for self-issued claims as a low-barrier entry point (Suzanne).
  - Flexibility across use cases, sectors, and trust requirements.

---

**_Action Items_**

| Item | Owner                   | Description                                                                                          | Due                 |
| ---- | ----------------------- | ---------------------------------------------------------------------------------------------------- | ------------------- |
| 1    | Steve                   | Improve mail/calendar system to avoid spam folder issues (e.g., Gaggle Mail limitations).            | Before next meeting |
| 2    | Matthias                | Define and launch temporary Extenders Governance Task Force and onboarding framework.                | In progress         |
| 3    | Nick Smith              | Update supply chain working group page with meeting times, minutes, and join instructions.           | Immediate           |
| 4    | Suzanne / Brett         | Kick off Conformity Group and clarify how scheme conformity and digital credentials interrelate.     | Next Tuesday        |
| 5    | Michael Wild            | Define adoption working group work packages and assign members.                                      | Ongoing             |
| 6    | Steve / Technical Group | Explore and document confidentiality-preserving approaches (e.g., verifiable redacted graphs, ZKPs). | Ongoing             |
| 7    | All Group Leads         | Ensure next meeting times and Zoom links are updated on UNTP site steering page.                     | Immediate           |
| 8    | Suzanne / Steve         | Explore collaboration with Solid (Tim Berners-Lee project) on redacted graph proofs.                 | Backlog             |
| 9    | Gideon                  | Develop simplified terminology for levels of assurance (self-assessment vs. third-party).            | In progress         |
| 10   | All Participants        | Join relevant working groups and provide feedback on onboarding clarity and tooling support.         | Ongoing             |

## 2025-06-26 Meeting Summary

**Date:** 26 June 2025
**Location:** Virtual (Zoom)
**Chair:** Steve Capell

#### Attendees

(Note: list inferred from transcript; not all full names were captured)

- Steve Capell (Chair, UNTP)
- Nancy (UN/UNCEFACT Chair)
- Brett (Conformance Group Lead)
- Michael (Adoption Group Lead)
- Nick (Supply Chain Implementation Group Lead)
- Zach (Technical Contributor)
- Gideon (ISOCASCO/Conformity Assessment)
- Brie
- Finn
- Will Nixon (Australia)
- Additional unnamed participants from Canada, Austria/Ireland, UK, US

#### Key Discussion Points

1. **Attendance and Mailing List Confusion**

- Lower than usual turnout (\~10 vs expected 20) due to mailing list transition from Google Groups to Gaggle.
- Meeting invites likely ended up in participants’ junk folders.
- Calendar issues also noted due to time zone shifts; Steve committed to clarifying on the website and via direct email.

2. **Upcoming Geneva Events**

- UNCEFACT Plenary (2-day) to review work plan including sustainability and UNTP.
- Recommendation 49 (“Transparency at Scale”) is up for approval.
- UNECE is hosting several digital product passport (DPP) events in batteries, textiles, etc.
- Open Wallet Foundation hosting an in-person-only event on decentralized identity; UN is a co-organizer.

3. **Status of Recommendation 49**

- Nancy reported growing support, especially after her presentation at UN Open Source Week.
- Only notable concern from Germany, requesting either removal or modification of annex referencing UNTP.
- Language is being negotiated to reach consensus.
- Support letters to national Heads of Delegation from experts are encouraged.

4. **UNTP Extension Framework**

- Global Battery Alliance has formally requested to lead a battery-specific UNTP extension.
- A governance framework for extenders is being developed; first meeting in Geneva.
- Discussion on when and how extenders gain influence on UNTP core.

5. **Governance and Interoperability**

- Need for consistent criteria across different schemes (e.g., carbon measurement, conformance).
- Two interoperability concerns: data schema and scheme comparability.
- Gideon emphasized the importance of early alignment with global conformity assessment frameworks.

6. **Working Group Updates**

Conformance Group (Lead: Brett)

- 37 members; kickoff meeting scheduled for 15 July.
- Aligning with ISO/CASCO to avoid redundancy.

Adoption Group (Lead: Michael)

- First call held; lower attendance possibly due to timing and link confusion.
- 15 members on the list.
- Planning next meeting and stakeholder assignments.

Supply Chain Implementation Group (Lead: Nick)

- 8 members actively engaged.
- Draft terms of reference reviewed.
- Focus on real-world DPP implementations, capturing lessons learned, and data mapping.

7. **Technical Update**

- Awaiting lead.
- Playground testing tool being upgraded to support linked verifiable credentials.
- V0.6 release now available for pilot implementations.
- Discussion on possibly migrating key technical components (e.g., digital identity anchor spec) to broader UN projects like Global Trust Registry and VC for Trade.

8. **Blockchain Feedback**

- Feedback received requesting softer language regarding blockchain use in the verifiable credentials profile.
- Agreed to revise wording with care to remain inclusive but avoid platform bias.

9. **Transparency and Documentation**

- Agreement that subgroups should publish meeting summaries and optionally transcripts.
- GitHub tickets tagged by group are to be used for cross-group visibility and coordination.

#### Action Items

- **Steve:**

  - Send direct email (not via Gaggle) to clarify mailing list and meeting details.
  - Update meeting time on website.
  - Follow up with heads of delegation contacts for letter-writing support.
  - Add Brett and Michael to the Extenders Group Geneva meeting.

- **Working Group Leads:**

  - Publish meeting summaries on their respective UNTP pages.
  - Encourage issue tracking and cross-tagging in GitHub.

- **Participants:**

  - Review Recommendation 49 and consider writing support letters to heads of delegation.

## 2025-06-12 Meeting Summary

**Date:** 12 June 2025
**Recording:** Publicly available
**Chair:** Steve Capell

#### Participants

- Steve Capell (Chair)
- Brett Hyland (Conformity Group Lead)
- Michael Shea (Adoption Group Lead)
- Nick P (Product Passport Group Lead)
- Nis Jespersen (VC4Trade Initiative)
- Suzanne (Technical Contributor)
- Zach Seuss (Technical Editor for Conformity and Adoption Groups)
- Phil (noted in discussion)
- Other participants not individually named in transcript

---

#### Summary of Contributions

**Opening Remarks – Steve Capell**

- Welcomed attendees and introduced new structure: four subgroups (Conformity, Product/Facility, Adoption, Technical).
- Updated the group on UNTP progress:

  - Preparation underway for UN plenary (early July); lobbying to ensure RET49 passes without objection.
  - Participation in global events such as the Open Wallet Foundation’s collaboration summit.
  - Coordination with Global Battery Alliance (GBA) and CatenaX to develop battery-specific UNTP extensions.
  - Collaboration with the International Trade Centre (ITC) for tooling to support SMEs using UNTP.

- Apologized for the delay in publishing subgroup infrastructure on GitHub but committed to submitting a pull request the next day.

**Brett Hyland – Conformity Working Group**

- Outlined the purpose of the group: ensuring credibility of voluntary sustainability claims through recognized conformity assessment processes.
- Described the role of ISO/CASCO and WTO obligations for verified compliance.
- Highlighted legacy work under UN CFACT and its evolution into the new working group.
- Shared primary deliverables:

  - Digital Conformity Credential (DCC) specification.
  - Sustainability Vocabulary Catalogue (SVC).

- 26 people have expressed interest; first meeting to be scheduled soon.
- Zach Seuss to serve as technical editor.

**Michael Shea – Adoption Working Group**

- Role of the group: develop business case for UNTP, increase uptake, and support implementers.
- Meetings will occur fortnightly on alternating time zones to cover global participation.
- Goals include:

  - Finalizing business case content.
  - Drafting letter of intent templates for implementers/extenders.
  - Providing outreach and training resources.
  - Clarifying UNTP’s complementarity with EU, ISO, IEEE, and ITU standards.

- Active Slack channel renamed for the group; participants invited via Slack or email.

**Nick P – Product Passport & Facility Record Working Group**

- Focus on practical application of DPPs (Digital Product Passports), DFRs (Facility Records), and DTEs.
- Brought an industrial and ESG manager perspective to the effort.
- Emphasized harmonizing existing disclosure requirements using the DPP as a common carrier.
- Group will explore selective disclosure and re-use of existing DPP content across frameworks like CSRD and EUDR.
- Encouraged participation from technical experts to support the group’s efforts.

**Steve Capell – Technical Working Group (interim lead)**

- Covers maintenance of:

  - UNTP’s Verifiable Credentials profile.
  - Identity resolver and access control.
  - Test suites and schema validation tools.

- Version 0.6 of the technical artifacts is nearly ready and addresses prior semantic and JSON-LD issues.
- Group lead still to be confirmed.

**Nis Jespersen – VC4Trade Initiative**

- Introduced new project to apply UNTP architecture to traditional trade documents (e.g. invoices, bills of lading).
- Based on ICC KTDDE data models; aims to improve trade document interoperability with verifiable credentials.
- Project will coordinate with ICC DSI and UNECE.

#### Additional Comments

- Brett raised concern over ICC parent organization’s policy brief potentially overlapping UNTP without acknowledgment.
- Nick noted possible carbon-related duplications in ICC efforts and flagged for subgroup attention.
- Suzanne raised a GitHub permission issue, which Steve will investigate.

#### Action Items

| Task                                                               | Responsible   | Deadline      |
| ------------------------------------------------------------------ | ------------- | ------------- |
| Submit GitHub PR to establish subgroup pages and signup mechanisms | Steve Capell  | 13 June 2025  |
| Finalize and publish Conformity Group kickoff schedule             | Brett Hyland  | Mid-June 2025 |
| Promote Adoption WG on LinkedIn and begin first working session    | Michael Shea  | 26 June 2025  |
| Confirm technical lead for Technical WG                            | Steve Capell  | ASAP          |
| Resolve GitHub permission issue for Suzanne                        | Steve Capell  | ASAP          |
| VC4Trade project to finalize mailing lists and meeting structure   | Nis Jespersen | TBD           |
| Review ICC “Data Flows in Supply Chains” paper for overlap         | Brett/Nick    | TBD           |

## 2025-05-29 Meeting Summary

**UNTP Working Group – Meeting Summary**
**Date:** 29 May 2025
**Chair:** Steve Capell
**Recording:** Confirmed, to be published
**Session Type:** Technical status meeting

#### Participants (Named)

- **Steve Capell** – Chair, presented chain of custody models and led discussion
- **Phil Archer** – Provided update on IANA registration for DPP link relation type
- **Nancy Norris** – Chair of the UNCFACT Bureau; described UNCFACT’s oversight and copper industry interest
- **Nick Smith** – Commented on mass balance, government-linked registries, and emissions data aggregation
- **Michael** – Presented Tier 3 testing proof of concept for credential trust graphs
- **Adriana** – Raised questions on access control and data visibility for traders
- **Ali (Canada)** – Described practical implementation of mass balance in mining operations
- **Brett** – Asked about access to Tier 3 testing tools
- **Other noted speakers:** Zach (mentioned), Jordan, and unnamed participants from Surpass and other affiliated organizations

#### Key Topics Discussed

1. **IANA Link Relation Registration**

- Phil is registering "dpp" as an IANA link relation type.
- UNTP will be cited as the primary reference, with an equivalence note to GS1’s DPP.
- The working group agreed with the proposed short, precise definition.

2. **Chain of Custody in Copper Supply Chain**

- Steve presented a multi-step diagram from mine to EV recycling, explaining transformation from ore to concentrate, blister, cathodes, and manufactured goods.
- Discussion focused on identity, traceability, and batch blending complexities—especially where smelters/refiners mix inputs from multiple sources.

3. **Mass Balance and Guarantee of Origin**

- Mass balance models were discussed as key mechanisms to trace sustainability attributes through mixed material flows.
- The need for quota management and assurance was emphasized, with commentary from Nick and Ali on real-world practices in Australia and Canada.
- Nancy noted that Coppermark and IRMA already audit chain-of-custody systems rather than individual transactions.

4. **Trading and Obfuscation**

- Traders often redact source identities due to commercial sensitivities.
- Adriana and others discussed access control solutions using UNTP’s decentralized access model.
- Quality assurance requirements in sectors like defense and aerospace were noted as potential drivers for full traceability.

5. **Book and Claim Models**

- Explored as complementary to traceability, particularly when traceability is impractical or cost-prohibitive.
- Nancy and Nick highlighted their utility in incentivizing sustainability improvements at the source.
- Discussion raised the issue of potential double counting and the role of registry programs in preventing it.

6. **UNTP Mapping**

- Steve proposed that guarantees of origin be treated as digital conformity credentials (DCCs), and stock/flow data as traceability events (DTEs).
- The group generally agreed this was a practical mapping to UNTP concepts.

7. **Tier 3 Testing Demo**

- Michael demonstrated a CLI-based proof of concept that builds a trust graph from verifiable credentials and their relationships.
- Key functionality included JSON-LD parsing, schema validation, issuer trust chain verification, and semantic inference.
- Planned future integration with the UNTP Playground and improvements in visualization were discussed.
- GitHub repo was shared for early testing and contributions.

#### Outcomes and Next Steps

- Update the UNTP chain of custody page to include mass balance and book-and-claim explanations, with diagrams and credential mappings.
- Continue development of Tier 3 testing features and integrate into UNTP Playground.
- Reach out to Phil and Michael for offline collaboration on IANA registration and testing framework, respectively.
- Schedule next meetings targeted for European time zones, with ongoing discussions to continue online.

## 2025-05-14 Meeting Summary

**UNTP Technical Working Group – Meeting Summary**
**Date:** 14 May 2025
**Chair:** Zach
**Host:** Zach
**Recording:** Confirmed to be active, potentially recorded to Zach's Zoom cloud

#### Participants (Named)

- **Zach** – Facilitator, led discussion on governance, PRs, and technical updates
- **Ash** – Demonstrated the new data model validation and mutual verification testing processes
- **Phil Archer** – Provided feedback on testing and verification; discussed GS1 identifier systems
- **Alex (Checked)** – Introduced interest in DID-based trust registries and UNTP contributions
- **Christophe (Queer Factum)** – Joined as a contributor to DPP-related work, not representing GTC24
- **Nabil Ahmed (Circularize)** – Observing UNTP developments due to alignment with traceability goals
- **Unnamed expert from Cirpice2 / Impact** – Introduced herself as a first-time participant, working on traceability in the fashion sector
- **Adriana** – Mentioned being assigned a task by Steve but unable to locate it
- **Jordan** – Provided technical validation feedback and support for Ash's demo
- **Nick Smith** – Asked questions about validation pipeline context and real-world change examples
- **Stefano** – Mentioned in the list of open GitHub tickets
- **Michael** – Collaborated on addressing schema validation issues (mentioned by Ash)

#### Key Topics and Discussions

1. **Meeting Opener and Introductions**

- Zach emphasized that the meeting follows the UN Open Development process.
- New participants introduced themselves, notably from Europe, fashion, and the Circularize traceability platform.

2. **Pull Request Reviews**

- Zach reviewed PR #43 concerning updates to FAQs on DPP topics like late data and repair events.
- Ash approved and merged the PR with no objections.
- Plan: remaining PRs to be reviewed by participants post-meeting; objections must be submitted by week's end.

3. **Jargon Release and Validation Pipeline**

- Ash presented the new validation workflow:

  - Snapshots now trigger schema and context validation pipelines.
  - Errors caught pre-release instead of post-release.
  - Includes JSON-LD expansion and schema conformance checks.

- The process reduces error rates and increases community collaboration.
- Human review remains critical for semantic accuracy.
- Future improvement: enforce check statuses to block PR merges until validations pass.

4. **Mutual Verification Testing Demo**

- Ash presented the UNTP Playground tool:

  - Supports mutual verification for VCs against UNTP schema and VCDM.
  - Users upload their own VCs and verify others' to prove interoperability.

- Documentation now explains Tier 1 and Tier 2 testing stages.
- W3C VCDM v2 test suite was found insufficient; custom mutual verification is used for now.

5. **Discussion on Data Model Interoperability**

- Phil raised concerns about overlapping verification logic across different ecosystems (e.g., existing global identifier schemes vs UNTP).
- Zach explained Tier 1 (technical VC compliance), Tier 2 (schema-level), and Tier 3 (cross-credential trust graph) validations.
- Alex emphasized the future role of global trust registries in resolving schema equivalence and issuer accreditation.

6. **Open Issues and Next Steps**

- Zach reviewed the GitHub issues list for the 0.6 release and reminded participants to address their assignments.
- Phil confirmed recent contributions and encouraged peer review of IDR-related spec additions.
- Adriana will follow up with Steve to confirm her assigned task.

7. **FIWARE DPP Announcement**

- A participant shared that they will be presenting UNTP at the FIWARE Global Summit in Morocco, focusing on Open DPP frameworks for SMEs and smart city applications.

#### Next Steps

- Review and comment on current open pull requests before end of week.
- Prepare for next session where Tier 3 testing and trust graph validation will be showcased.
- Steve to follow up with Adriana on task assignment.
- Continue collaboration on global trust registries and identity scheme integration.

## 2025-04-17 Meeting Summary

**Facilitator:** Steve Capell (Speaker 1)  
**Duration:** Approximately 1 hour  
**Recording:** Yes, available publicly  
**Purpose:** Regular UNTP team meeting covering updates, new participants, recommendation development, roadmap planning, pilots, and discussion of issues.

#### **Key Participants**

- **Steve Capell** – Lead facilitator, overseeing agenda and project direction
- **Matthias Altmann** – Consultant joining UNECE Secretariat, working on traceability projects
- **Virginia (Speaker 14)** – Participant recovering from illness
- **David (Speaker 10)** – New participant from GraphVise, interested in DBPs
- **Eric Drury (Speaker 11)** – Independent consultant in digital identity and trust
- **Adriana (Speaker 7)** – Contributor with a focus on circular performance
- **Michael (Speaker 5)** – Involved in DPP, IEEE, and regulatory frameworks
- **Suna (Speaker 4)** – Provided input on upcoming EU regulations
- **Peter (Speaker 6)** – Raised points about GS1 and upstream supply chains
- **Christophe (Speaker 9)** – Commented on DPP terminology and structure

#### **Discussion Highlights**

**1. Introductions & Participation**

- Welcomed newcomers: Matthias Altmann, David, and Eric Drury.
- Updates from returning members, including Virginia’s recovery.

**2. Administrative Notes**

- Clarified meeting recording and IP contributions for UNTP participation.
- Addressed time zone confusion due to daylight savings.
- Group agreed to continue meetings at 8 a.m. UTC.

**3. UNTP and Recommendation 49**

- Steve provided updates on **Recommendation 49 (Transparency at Scale)**:
  - Separated implementation guidance into **design principles**.
  - UNTP positioned in the annex as one of several supporting instruments.
  - Diagram introduced to explain framework lifecycle generically.

**4. Roadmap Planning**

- Current version: **0.5**; goals set for versions 0.6, 0.7, and 1.0.
- 0.6: Technical fixes.
- 0.7: Incorporate business functions and feedback.
- 1.0: Stable release planned for fall 2025.
- Steve encouraged tagging issues in GitHub with target versions.

**5. Subgroups Formation**

- Announced the formation of subgroups:
  - **Conformity Subgroup** (lead: Brett)
  - **Adoption Subgroup** (lead: Michael)
- Two more subgroups in planning; volunteers still needed.
- Plan to spin off groups as soon as leads are ready.

**6. Pilots and Testing**

- **Steve** detailed the **Responsible Business Alliance (RBA)** pilot in electronics and automotive.
- **Matthias** discussed pilots in **garments** and **critical raw materials (starting with copper)**:
  - Aim to demonstrate **scalability and interoperability**.
  - EU project funding supports pilot facilitation.
- Additional pilot opportunities:
  - **Tire industry** (Michael & Adriana to explore GDSO involvement)
  - Collaboration with **Surpass Initiative** and European **data spaces**.
  - Alignment with **Gaia-X / Catena-X**.

**7. Open Issues & Feedback**

- Terminology:
  - Discussion on continuing to use **"DPP" (Digital Product Passport)** vs. “product data.”
  - Consensus: Retain "DPP" with clear guidance on voluntary vs. regulatory use.
- Data Structure:
  - Discussion on **flattened vs. hierarchical** conformity structures.
  - Tendency toward flat for simplicity, but open to structured representation.
- Naming clarity:
  - Debate on whether to rename **Digital Conformity Credential** to **Attestation**.
- Schema usage:
  - Reviewed use of **schema.org** and **semantic context files**.
  - Issues raised about schema.org inheritance quirks (e.g., "drive-thru" countries).

#### **Action Items**

- Participants to **review and comment on GitHub issues**.
- Volunteers needed to lead additional subgroups.
- **Adriana** to raise circular performance concerns via GitHub.
- **Matthias** to document pilot progress and stakeholder coordination.
- **Michael** and team to explore tire industry and DPP regulations.
- Further exploration of **schema.org compatibility** in the UNTP model.

## 2025-04-03 Meeting Summary

#### **Meeting Summary**

**Date:** April 3, 2025  
**Topic:** UNTP Working Group Meeting  
**Duration:** ~1 hour  
**Recorded & Transcribed:** Yes  
**Chair:** Steve

#### **Agenda**

1. Review of draft Terms of Reference (ToR) for working groups (led by Brett)
2. Presentation of the draft **Sustainability Vocabulary Catalog** specification (by Steve)
3. Open discussion on governance, classification schemes, and next steps

#### **Participants**

There were 20 participants with contributions as described below.

| Name         | Role/Notes                                                               |
| ------------ | ------------------------------------------------------------------------ |
| **Steve**    | Chair, presenter of UNTP structure and Sustainability Vocabulary Catalog |
| **Brett**    | Lead of Conformity Credential Group, drafted ToR                         |
| **Virginia** | Contributor, raised key concerns on roles, classification, AI usage      |
| **Zach**     | Provided strategic input, supported linking previous conformity work     |
| **Bree**     | Asked governance and extension implementation questions                  |
| **Phil**     | Aligned current work with machine-readable credentialing                 |
| **Clary**    | Inquired about handling activities, mitigation risks, registry process   |
| **Nick**     | Cautioned about overreach and subjectivity in standards                  |
| **Robertus** | Advocated clarity for new readers, suggested keeping helpful visuals     |
| **Marcus**   | Asked about URIs and issues with paywalls                                |
| **Michael**  | Inquired about EU regulations like CSRD/CSDDD                            |

#### **Key Discussion Highlights**

#### 1. **Working Group Terms of Reference**

- **Brett** presented a draft ToR for the Conformity Credential Group.
- Roles proposed: **Group Lead**, **Technical Editor**, possibly additional roles (e.g. Register Maintainer).
- Feedback:
  - **Virginia**: Watch for workload — suggested splitting tasks.
  - **Phil/Zach**: Tie-in with UNCFACT and earlier conformity projects.
  - **Robertus**: Asked for acronym clarity and onboarding support.
- Consensus: Keep the ToR flexible and evolving.

#### 2. **Sustainability Vocabulary Catalog (SVC) Draft**

- **Steve** walked through a proposed model for scheme owners to:
  - Publish digitally referenceable criteria.
  - Be included in a **scheme register**.
  - Classify criteria using a controlled vocabulary.

**Key features:**

- Clear distinction between **self-claims** (Digital Product Passports) and **third-party audits** (Conformity Credentials).
- Encourages scheme owners to publish **granular, URI-addressable criteria**.
- Optional fields for scores, thresholds, and measurement types.

#### 3. **Classification Concerns**

- Proposed a 2-level classification model inspired by OECD, ESPR, ITC, etc.
- **Virginia**: Urged coordination with ITC; pointed out their taxonomy and data should be consulted.
- **Clary**: Raised concerns around registering mitigation activities.
- **Michael**: Suggested alignment with CSRD, CSDDD.
- **Marcus**: Asked how the model handles URIs behind paywalls (e.g. ISO).

---

#### **AI and Automation Debate**

- **Nick & Phil**: Cautioned against overreliance on AI for standards mapping.
- **Steve**: Clarified AI references were exploratory and not core.
- **Virginia & Zach**: Suggested AI-related notes should be relocated to adoption/business case docs.
- **Consensus**: Remove “AI” terminology from spec and refer to “Assessment Assistance Tools”.

---

#### **Next Steps**

- **Steve** to update the SVC draft:
  - Remove direct AI references.
  - Reframe visuals for clarity.
  - Publish revised draft for peer review.
- Plan to **formally initiate sub-working groups** based on ToRs in the coming weeks.
- Consider organizing a **joint discussion** with ITC to align classification vocabularies.

## 2025-03-20 Meeting Summary

**Date:** March 20, 2025  
**Project:** United Nations Transparency Project (UNTP)  
**Facilitator:** Steve (Speaker 1)  
**Recording Note:** Meeting was recorded and will be posted.

#### **Participants & Introductions**

- **Steve** (Facilitator): Based in Canberra, Australia. Emphasized the need for better governance and decentralization.
- **Herman van der Pooy**: From FIDES (Netherlands). Introduced his colleague Victor van der Hulst. Interested in UNTP, especially discovery based on decentralized identifiers and invoicing.
- **Daria**: Starting April 1 as Chief Sustainability Officer at Ressos, a metals traceability company. Based in Germany.
- **David Jensen**: From UN Environment Programme. Focused on environmental aspects of digital transformation. Interested in overlap with UNEP's Digital Product Passport blueprint.
- **Marcus**: Working with local agriculture and seaweed production communities. Raised points about innovation at grassroots levels.
- **Phil Archer**: Advocated for better semantic mappings and URI-based standards for sustainability criteria.
- **Michael**: Raised governance questions and proposed aligning with open source governance models (e.g., Linux). Volunteered to help with business case documentation.
- **Adriana**: Proposed forming sub-working groups, including one on standards. Shared her experience analyzing sustainability standards for SERPAS.
- **Nick**: Suggested a matrix structure—subgroups by sector and technical focus—for scalability.
- **Zach**: Supported subcommittees and emphasized the need for leadership and community contribution to make the UNTP sustainable.
- **Bertus**, **John**, and several others also participated actively.

#### **Key Discussion Points**

#### 1. **Governance Update**

- Steve admitted to bypassing the formal GitHub process when making a governance diagram change.
- Proposal to transfer the GitHub repository ownership to the UN Secretariat to enforce governance practices.
- **New Governance Addition**: An “Extensions Governance Board” was added to give extension owners formal input into core UNTP development.

#### 2. **Subcommittees Proposal**

- General agreement on forming subcommittees to decentralize and scale work.
- Possible structure:
  - By **technical components** (e.g., identity, traceability, resolver)
  - By **industry sectors** (e.g., agriculture, mining, electronics)
- Steve will propose a structure and seek feedback via email.

#### 3. **Standards Integration**

- UNTP will act as a global open standard and complement JTC24 (EU's DPP regulation body).
- TC154’s Joint Working Group 9 (UN/ISO collaboration) was cited as a global standardization path.
- Emphasis on how UNTP differs by not dictating centralized registries and allowing for decentralized implementations.

#### 4. **Sustainability Vocabulary Catalog (New Work Item)**

- The team is developing a way to make sustainability-related **criteria URI-addressable and machine-readable**.
- Key challenges:
  - Different schemes (e.g., IRMA, TSM) define sustainability criteria differently.
  - Need a referenceable taxonomy for these criteria.
  - Determine whether referencing should be a “must” or “should”.
- General support for the effort. Recognized as **critical for data credibility and interoperability**.

---

#### **Next Steps & Action Items**

- **Steve** to draft a proposal for working group structure.
- **Team** to provide feedback on subcommittee structure and volunteer for leadership.
- **Sustainability Vocabulary Work**: Continue researching schemes and URIs. Draft guidance for scheme owners on publishing machine-readable criteria.
- **Michael** to resume work on business case documentation.
- Update diagrams to reflect **facility records** as a core component.

## 2025-03-06 Meeting Summary

**Chair:** Steve  
**Attendees:** Nick, Zach, Alberto Spritorius, Ali Bezirizadeh, Peter, Patrick, Danika, Ashley, Adrian, Albertus, and other contributors

#### **1. Welcome and Introductions**

- **Steve** welcomed attendees and acknowledged voluntary participation.
- **Alberto Spritorius** (Tuneas International) introduced himself, explaining his background in vehicle license plate manufacturing and standards.
- **Ali Bezirizadeh** (AI Simpro, Canada) introduced his work on bulk material traceability in the mining sector.

#### **2. GS1 Commitment to UNTP**

- **Steve** announced GS1’s commitment to implementing the UNTP Identity Resolver (IDR).
- **Peter** confirmed GS1's commitment but emphasized a gradual approach due to its 150+ member organizations.
- **Patrick** raised concerns about GS1’s position on verifiable credentials, which **Steve** clarified, noting GS1's intention to implement the Digital Identity Anchor (DIA).

#### **3. UNTP Information Architecture Update**

- **Danika** presented an improved site structure for UNTP documentation.
  - Focus on simplifying navigation and making content more user-friendly.
  - Hierarchical model preferred over multidimensional structures to ease maintenance.
  - Stakeholder-specific guides added to streamline access to relevant information.
- **Patrick and Nick** supported the changes, emphasizing their clarity and usability.

#### **4. UNTP Playground for Credential Validation**

- **Ashley** demonstrated the latest features of the UNTP Playground, a tool for validating digital credentials.
  - Now supports conformance testing with **VCDM v2**, JSON-LD validation, and schema checks.
  - Users can generate downloadable **conformance reports** (eventually verifiable credentials).
  - Planned features include public **credential repositories** for verified implementations.
- **Patrick** suggested allowing direct downloads of **rendered HTML reports** from the Playground.
- **Zach** proposed highlighting the **extension model** for bulk materials to demonstrate practical applications.

#### **5. Discussion: Bulk Materials & Digital Material Passport**

- **Steve** raised the question of whether bulk materials (e.g., grain, crude oil, copper concentrate) require a **Digital Material Passport** separate from the **Digital Product Passport**.
- **Albertus, Nick, and Zach** argued that bulk materials should remain under **UNTP with extensions** rather than creating a new passport type.
- **Ali Bezirizadeh** noted different traceability needs between **radioactive materials, iron ore, and concentrates** and asked whether classifications would be standardized.
- **Peter** emphasized that **facility credentials** play a crucial role in bulk material traceability, not just the material itself.
- **Adrian** (from a crude oil trading and chemical background) argued that **a material passport is necessary** because crude oil and intermediates differ from finished products.
- **Steve** concluded that **real-world testing** should determine whether an extension is sufficient or if a new model is needed.

#### **6. Closing Remarks**

- **Steve** mentioned plans to create a **UNTP Media Page** listing external references to UNTP.
- Next steps:
  - Collect feedback on the **UNTP Playground** and **information architecture updates**.
  - Continue practical tests for **bulk materials in UNTP** before deciding on a separate material passport.
  - Publish the **media page** for community contributions.

## 2025-02-20 Meeting Summary

**Facilitator:** Steve (Speaker 1)  
**Attendees:** Stefano, Danique, Suzanne, Virginia, Proc, Nis, Zach, Michael, Bart, Alex, Nick, David, and others.

#### **Key Discussion Points:**

1. **UN-Sponsored Pilots and Governance of Extensions (Steve, Stefano)**

   - Steve shared updates on the UN-sponsored pilots on textiles and critical minerals, discussing whether they should have separate definitions or be grouped globally.
   - Stefano emphasized the importance of the 80-20 approach for UNTP extensions.
   - Discussion on governance and whether international bodies exist for specific minerals.

2. **Public Review of Recommendation 49 (Suzanne, Steve, Virginia)**

   - Suzanne provided an update on Recommendation 49, which is about to go for public review.
   - The review will be structured to minimize incoming changes before final approval.
   - Virginia clarified that REC 49’s review is distinct from the public review of UNTP, and it is important to ensure it is approved in July without unnecessary complications.

3. **Concerns on UNTP Specification Readiness (Steve, Nis, Alex)**

   - Steve raised the question of whether the UNTP specification pages are sufficiently developed for public review.
   - Nis suggested limiting the scope of what is reviewed, keeping only mature and essential parts.
   - Alex proposed a more structured approach to incomplete sections by using placeholders instead of “TBC” labels.

4. **Feedback on UNTP Documentation & Usability (Danique, Nis, Michael, Zach)**

   - **Danique’s Review Findings:**
     - **Overload of information:** Fragmented resources, lack of clear examples.
     - **Navigation Issues:** Users find it hard to access the right content.
     - **Need for Role-Specific Guidance:** Different audiences require tailored documentation.
     - **Business Case Clarity:** Implementers need to understand the practical value.
   - **Recommendations:**
     - Consolidate resources, improve navigation, enhance onboarding with examples.
     - Use progressive disclosure to present information in digestible steps.

5. **Simplifying UNTP and Restructuring Specs (Nis, Steve, Zach, Bart)**

   - Nis proposed removing unnecessary complexity from specifications, particularly in role-based access control.
   - Steve agreed that UNTP should focus on essential functionalities and possibly split off components that are more general-purpose.
   - Bart highlighted the challenge of transitioning from paper-based supply chains to digital ones and called for a phased approach.

6. **Global Trust Register & Future Pilots (Steve)**

   - The Global Trust Register, involving the Spanish Business Register and Australian Livestock Identification Scheme, will conduct pilots to refine identity-related UNTP components.
   - There’s a need to balance current spec development with learnings from these pilots.

7. **Action Items & Next Steps:**
   - **Steve:** Draft introductory guidance for the public review of UNTP.
   - **Danique:** Continue improving the site’s structure and usability.
   - **Michael & Nis:** Publish an article simplifying UNTP’s purpose and implementation.
   - **Zach:** Implement better documentation flags (e.g., what’s under review and how to give feedback).
   - **All Participants:** Review and address outstanding issues to improve UNTP specs before public review.

## 2025-02-06 Meeting Summary

**Chair:** Steve (Speaker 1)  
**Participants:** David (Speaker 6), Nancy (Speaker 7), Zach (Speaker 4), Virginia (Speaker 2), Clary (Speaker 7), Marcus (Speaker 5), and others

---

#### **Key Topics Discussed:**

**1. Opening Remarks**

- **Steve** welcomed participants, reminding them that this is a **UNTP meeting** and that contributions are **UN intellectual property (IP)**.
- **Meeting was recorded**, with no objections raised.

---

#### **2. Change Requests & Technical Updates**

**Identity Resolver Page Updates**

- **Steve** walked through the process of how identifiers (product, facility, business) are resolved to find additional data (e.g., digital product passports).
- The page was reviewed to ensure it supports **existing identifier schemes** while accommodating **decentralized identifiers**.
- **Key Discussion Points:**
  - **David** raised concerns about persistence of product identifiers for **circularity** (e.g., for recycled materials).
  - **Steve** clarified that the document **focuses on resolving identifiers rather than defining data carriers** but acknowledged that **traceability extensions** address linkage between raw materials and finished products.
  - **Nancy** questioned the inclusion of **glyph identifiers**, and **Steve** clarified that examples were provided **without preference**.
  - **Virginia** suggested improving the diagram wording to **clearly show that different identifier schemes are supported**.
  - **Zach** proposed creating a **ticket to further discuss identifier persistence** in future updates.

**Verifiable Credentials Specification Update**

- **Ashley** proposed a change requiring **version 2.0** of the verifiable credentials specification instead of allowing both versions 1.1 and 2.0.
- **Technical team (Patrick, Nis)** had reviewed and approved the change, with no strong objections from others.
- **Decision:** **PR approved** to enforce the use of **Verifiable Credentials version 2.0**.

**New Implementation Commitment**

- **K4 Security (Korea)** expressed commitment to implementing UNTP.
- **Steve** verified their legitimacy and **no objections were raised** to adding them to the implementation list.

---

#### **3. Implementation Guidance Page**

- **Steve** introduced a new draft page to help organizations navigate the implementation of **UNTP**.
- **Five-Step Implementation Framework** was proposed:
  1. Assess the **business case** for implementation.
  2. Identify **relevant pages** and register **intent to implement**.
  3. Choose **software solutions** or ask vendors for support.
  4. Run **pilot tests** and refine implementation.
  5. Scale up.

**Key Discussion Points:**

- **Clary** suggested adding a section for **consulting and implementation services** to assist companies.
- **John** proposed including a section on **long-term governance** for managing UNTP extensions.
- **Virginia** recommended promoting **awareness of UNTP among SMEs**, encouraging them to request **UNTP-compatible software**.
- **Marcus** raised the question of whether software vendors should have **branding or certification** for implementing UNTP.
- **Steve, Virginia, and Zach** discussed the feasibility of an **accreditation or certification** program but agreed it would likely be managed by external certifiers, not the UN.

**Decision:**

- PR for **Implementation Guidance Page to be reviewed and merged**.
- A **ticket will be created** for future discussions on **certification and branding** for software vendors.

---

#### **4. Certification and Standards Governance**

- Discussion on **who should maintain long-term governance of industry extensions** (e.g., Australian Agriculture Traceability Protocol - AATP).
- **Steve** proposed that **National Standards Bodies (NSBs)** (e.g., **Standards Australia, Canadian Standards Authority**) could be a good home for maintaining **industry-specific extensions**.
- **Virginia** and **Zach** agreed that **commercial certification bodies (e.g., SGS)** could handle **third-party accreditation** instead of the UN.
- **Zach** suggested forming a **working group** to explore governance models.

**Decision:**

- **A ticket will be created** to explore a **UNTP Certification & Accreditation Framework**.

---

###% **5. Closing Remarks**

- **Steve** noted that **open issues had increased** from **50 to 81**, urging participants to **discuss issues between meetings** rather than waiting for calls.
- **Final call for comments**, with **Marcus** expressing interest in joining discussions on **Australian standards**.
- **Meeting adjourned**, and **minutes to be shared shortly**.

---

#### **Next Steps & Action Items:**

✔ **Merge** approved PRs (Verifiable Credentials update, Implementation Guidance).  
✔ **Create tickets** for:

- **Persistence of identifiers discussion**.
- **UNTP Certification & Accreditation Framework**.
- **Improving implementation guidance** for SMEs.  
  ✔ **Continue governance discussions** with **National Standards Bodies**.  
  ✔ **Review open issues** and prioritize for resolution before the next meeting.

## 2025-01-23 Meeting Summary

**Date**: January 23, 2025  
**Purpose**: To review progress on the UNTP project, including governance updates, community activation plans, chain of custody models, and upcoming contributions.

---

**Key Participants**

1. **Steve** - Lead Facilitator, UNTP Working Group.
2. **David** - Contributor to the Community Activation Plan (CAP).
3. **Harley** - Presenter on chain of custody models.
4. **Suzanne** - Contributor on governance and Recommendation 49.
5. **Virginia** - Reviewer of governance and CAP documents.
6. **Phil** - Technical advisor on identifiers.
7. **Nick** - Contributor to CAP and technical workflows.
8. **Brock** - Expert on battery supply chains and assurance models.
9. **Adriana** - Advocate for collaboration tools like online whiteboards.
10. **Zachary** - Contributor to sector-specific extension discussions.

---

**Key Discussion Points**

1. **Governance Updates**:

   - **Steve** presented updates to the governance framework, emphasizing the relationship between core UNTP efforts and sector-specific extensions.
   - Suggestions were made to clarify and simplify terms in the governance diagram, ensuring alignment between core and community-managed projects.

2. **Community Activation Plan**:

   - **David** introduced a revised CAP focusing on engaging industry associations and encouraging adoption of UNTP extensions.
   - Feedback included emphasizing ongoing maintenance of UNTP as a living framework, aligning diagrams with text, and including tangible examples for industry relevance.

3. **Chain of Custody Models**:

   - **Harley** outlined four models: identity-preserved, segregation, mass balance, and book-and-claim.
   - Discussions centered on how UNTP could support these models, particularly for industries like grain and aviation fuels.
   - Feedback included adding examples, workflows, and details about trusted registries and technical implementations.

4. **Collaboration Tools**:
   - **Adriana** suggested using online whiteboards like Mural for brainstorming, which was well-received.

---

**Next Steps**

1. Governance and CAP documents will be updated based on feedback and re-shared on Slack for further review.
2. Harley will refine the chain of custody draft, adding diagrams and examples before the next meeting.
3. Further discussions on identifiers and ontologies to be scheduled.

## 2025-01-08 Meeting Summary

**Date**: January 8, 2025  
**Purpose**: Discuss progress and challenges in implementing UNTP projects, focusing on decentralized access control, sustainable mining, and collaborative contributions.

---

**Participants**

1. **Steve**: Meeting lead, discussed new implementation commitments, decentralized access control, and UNTP updates.
2. **David Haycock**: Introduced as a new participant; emphasized experience in health and interoperability.
3. **Nancy**: Shared insights on sustainable mining practices and challenges in global adoption.
4. **Patrick**: Raised questions about right access and updating lifecycle events in decentralized models.
5. **Adriana**: Asked about secret key management and user access to encrypted data.
6. **Danica**: Provided clarity on publishing event histories and differentiating data updates.
7. **Clary**: Highlighted European supply chain act requirements and selective disclosure use cases.
8. **Harley**: Volunteered to lead discussions on managing mixed commodity challenges.
9. **Nick**: Expressed interest in contributing to clean energy and mass balance discussions.

---

**Key Discussion Points**

#### 1. **New Contributions and Implementation Commitments**:

- **Health LOQ** and **Simba Chain** (US-based) registered their intent to implement UNTP solutions following presentations on sustainability and traceability.
- The **Mining Association of Canada** committed to supporting the "Towards Sustainable Mining" (TSM) standards for global adoption.
- A pull request to update implementation lists was approved.

#### 2. **Decentralized Access Control**:

- Explored models for granting secure access to non-public data, especially in cases involving lifecycle events or regulatory needs.
- Key challenges discussed:
  - Sharing secrets (e.g., QR codes or embedded keys) for access while preventing unauthorized use.
  - Managing sensitive updates, such as repair or recycling events, through authentication.
- Proposed approaches:
  - Encrypted data with secret keys shared through products.
  - Federated and decentralized authentication methods to scale access for unknown yet authorized roles (e.g., recyclers).

#### 3. **Sustainable Mining and Conformity Credentials**:

- Nancy discussed the global adoption of TSM standards and their integration with UNTP frameworks.
- Highlighted regional adaptations and the importance of accreditation processes.

#### 4. **Selective Disclosure in Supply Chains**:

- Clary emphasized the need for selective disclosure to comply with European regulations while protecting commercial sensitivities.
- Discussed methods for hiding specific attributes in digital product passports (DPPs).

#### 5. **Managing Mixed Commodities**:

- Harley introduced challenges in managing blended commodities (e.g., grain, copper concentrate) under mass balance and book-and-claim systems.
- A working group was proposed to address technical and compliance requirements.

---

**Tangible Outcomes**

- Approved updates to implementation commitments and standards documentation.
- Initiated discussions on selective disclosure, lifecycle event management, and decentralized authentication.
- Agreed to form a subgroup to address mixed commodity challenges in agriculture and industrial contexts.

---

**Next Steps**

1. **Documentation and Review**:
   - Update UNTP specifications for public review.
   - Clarify technical details in decentralized access control and selective disclosure.
2. **Collaborations**:
   - Engage stakeholders (e.g., recyclers, regulators) for pilot testing.
   - Advance work on agricultural and clean energy projects (e.g., grain and hydrogen tracking).
3. **Community Activation**:
   - Encourage Slack discussions and business-focused presentations to improve adoption.

---

**Closing Remarks**
Steve emphasized the need for timely contributions and invited participants to join ongoing Slack discussions and subgroups for unresolved challenges. The next meeting is scheduled in two weeks.

## 2024-12-12 Meeting Summary

**Date**: December 12, 2024  
**Purpose**: Discuss updates, collaboration opportunities, and next steps for UNTP and related projects.

---

**Participants**

- **Steve**: Meeting lead, discussed UNTP updates and coordination with various organizations.
- **Adriana**: Provided updates on the CERPAS project and emphasized the importance of interoperability and regulatory compliance in DPPs.
- **Patrick**: Shared experiences with BC Mines Act permits and raised technical concerns about schema flexibility.
- **Phil**: Contributed insights on updating DPPs and discussed GS1-related work.
- **Nick Smith**: Introduced his work on supply chain credentialing for emissions reporting.
- **Danika**: Highlighted her contributions to visual design for human-readable credentials.
- **Virginia**: Clarified distinctions between IEC, ITU, and other standards organizations.

---

**Key Discussion Points**

1. **Updates from the Rome Forum**:

   - Progress on UNTP and collaboration with ISO, CENCENELEC, and ITU.
   - A UNECE co-lead for ISO TC154 work was introduced to ensure alignment with UNTP.
   - Upcoming WWF pilots on sustainable practices in food and agriculture.

2. **CERPAS Collaboration**:

   - Adriana discussed challenges and progress in interoperability and regulatory standards for DPPs.
   - Identified gaps in user stories and opportunities for collaboration on pilots.

3. **Testing and Implementation**:

   - UNTP aims to finalize data models for conformity credentials by April 2025.
   - Volunteers sought to test mapping for industries like batteries, agriculture, and the built environment.

4. **Technical Concerns**:

   - Patrick raised issues about schema flexibility for extending digital conformity credentials.
   - Discussions on managing updates and linking credentials (e.g., service events).

5. **Future Collaboration**:
   - Interoperability testing planned for early 2025.
   - Interest in pilot programs with industrial partners like Century Batteries.

---

**Actions and Next Steps**

1. **Pilot Projects**:

   - Explore pilots in various industries, including Australian agriculture and batteries.
   - Adriana and Nick Smith to coordinate potential Australian collaborations.

2. **Schema Flexibility**:

   - Patrick to raise a GitHub issue to address schema concerns and ensure extension compatibility.

3. **Testing**:

   - Volunteers to test mapping of UNTP credentials to specific industries.
   - Focus on identifying gaps and refining data models before the first release.

4. **Documentation**:

   - Update UNTP pages on decentralized access control and interoperability patterns.
   - Publish mapping tools to assist contributors unfamiliar with JSON schema.

5. **Next Meeting**:
   - Scheduled for January after the holiday break.

---

**Closing Remarks**

- Participants shared holiday greetings.
- Steve emphasized ongoing collaboration through Slack and the mailing list.

## 2024-11-28 Meeting Summary

**Meeting Summary: UNTP Agricultural Extensions and Tools**

**Date:** November 28, 2024  
**Chair:** Zachary  
**Participants:**

- **Zachary (Speaker 1):** UNTP facilitator, leading discussions.
- **Ashley (Speaker 2):** Consultant, showcased technical tools and developments.
- **Adrian (Speaker 9):** Representing the BSF Group, Switzerland, focusing on supply chain transparency.
- **Adriana Zacche (Speaker 3):** Circular Economy Asia, specializing in resource management.
- **Suna (Speaker 10):** SME in Brussels, leading EU compliance initiatives for digital product passports.
- **Phil (Speaker 4):** GS1 advocate for verifiable credentials.
- **Michael (Speaker 5):** Provided feedback on business case development.
- **Stefano (Speaker 7):** EU-focused discussions on UNTP implementation.
- **Additional Contributors:** Marcus, Charles, Brett, and others engaged with questions and insights.

---

**Agenda:**

1. **Introductions and Updates**

   - New participants introduced their roles and interests in digital transparency and supply chain management.
   - Zachary highlighted the meeting's focus on agricultural traceability protocols and business case discussions.

2. **Demonstrations:**

   - **Sample Credentials:**  
     Ashley showcased the development of sample digital product passports and credentials, highlighting user-friendly rendering formats for non-technical stakeholders.
   - **UNTP Playground:**  
     A prototype tool for testing the compliance of digital credentials with UNTP standards was demonstrated, receiving positive feedback from participants.

3. **Australian Agriculture Traceability Protocol (AATP):**

   - Ashley and Zachary detailed AATP’s role as an extension of UNTP, tailored to livestock and agricultural needs in Australia.
   - Examples included livestock passports incorporating biosecurity data and deforestation compliance for feed sources.
   - Discussion on the readiness and potential launch timeline, targeting late 2024.

4. **Feedback and Questions:**

   - **Phil:** Raised concerns about demonstrating the value of technical standards to business users and emphasized practical evidence over technical details.
   - **Adriana:** Discussed resource management challenges and access controls for circular economy-focused businesses.
   - **Marcus:** Advocated for linking traceability tools to complementary systems (e.g., methane reduction from seaweed-based feed).

5. **Extensions and Use Cases:**

   - Discussion on replicability of the AATP model for other sectors, including critical minerals, electronics, and the built environment.

6. **Business Case Development:**

   - Participants sought updates on pending business case materials for the UNTP repository, with action points for follow-up on outstanding documentation.

7. **Future Plans:**
   - Expansion of UNTP applications in agriculture and alignment with global standards.
   - Continued refinement of tools like the playground and integration of user feedback.

---

**Next Steps:**

- Finalize and publish AATP materials.
- Address pending business case and technical issues.
- Provide demonstrations linking agricultural traceability with broader sustainability objectives.

## 2024-11-14 Meeting Summary

**Meeting Summary:**

On **November 14, 2024**, the UNTP working group convened to review recent updates, discuss business cases, and explore testing strategies for the UN Transparency Protocol (UNTP) implementation. The meeting, hosted by **Steve (Speaker 1)**, began with a brief welcome and a reminder of upcoming meetings that cater to global time zones.

Participant Introductions:

- **Adriana Zachary (Speaker 7)**: CEO of Circular Economy Asia, volunteered on digital product passport initiatives and contributes to user access, data authentication, and standards working groups.
- **Pat (Speaker 5)**: Technical Product Manager from San Francisco with experience in digital product passports for OEMs.
- **Nancy (Speaker 3)**, **Luca (Speaker 6)**, **Michael (Speaker 3)**, and **Zach (Speaker 10)** also actively contributed to the conversation, particularly regarding business cases and technical support needs.

Key Discussion Points:

1. **New Commitments from Industry Sectors**:

   - The **Responsible Business Alliance (RBA)**, representing major electronics and automotive companies, committed to implementing UNTP extensions for digital product passports and traceability.
   - The **International Code Council**, in collaboration with Standards Australia, aims to create sustainability vocabulary for building codes. This commitment includes alignment with European Union regulations.

2. **Business Case Development**:

   - Michael has been refining the business case templates to differentiate between **government** and **industry** needs. Steve reviewed the new layout, adding contextual insights on historical and current trends in corporate sustainability, noting a shift from regulatory compliance toward strategic integration.
   - The business case content, which includes **value and cost categories** for implementing UNTP, is structured to assist organizations in building tailored cases for executives. The group agreed on the necessity of further refinement, with Michael suggesting a follow-up review session.

3. **Implementation and Testing**:

   - To support the various software providers implementing UNTP, Steve proposed creating a **community-driven technical support ecosystem**. The group discussed leveraging an open-source approach for the test suite, allowing mutual support and continued development.
   - **Pat** and **Nis** were suggested as potential leaders of this technical support group, which would guide implementers through the **UNTP test suite**. Testing will include both technical conformance and business use case validations specific to industries.

4. **Testing Structure**:
   - The testing approach includes three layers:
     - **Technical interoperability** for ensuring compliance with W3C standards.
     - **Schema conformance** for validating UNTP’s unique frameworks.
     - **Industry-specific testing** for sectors using custom extensions.
   - **Jason (Speaker 2)** emphasized reporting tools to document testing results, which could serve as valuable evidence of compliance for implementers.

Closing Remarks:

Steve concluded by celebrating the day’s progress, noting the importance of industry extensions and the growth of the business case documentation. He thanked the team for their collaboration and welcomed further input from new and existing members.

The next steps involve finalizing the business case documentation, establishing a technical testing support group, and resolving any issues with the public release of content updates. The meeting adjourned with gratitude for the participants' contributions and commitments to the UNTP initiative.

## 2024-10-31 Meeting Summary

Meeting Summary

**Participants**:

- **Steve (Speaker 1)**: UN Representative, project lead on UNTP.
- **Stefano (Speaker 6)**: Liaison with EU directorates, providing updates on coordination efforts.
- **Virginia (Speaker 6)**: Providing feedback on governance and licensing.
- **Phil (Speaker 4)**: Brief input on registration processes.
- **Suzanne (Speaker 2)**: Contributed insights on standard profiles and security specifications.
- **Nis (Speaker 5)**: Discussed implementation requirements and test cases.
- **Luca (Speaker 8)**, **Jordan (Speaker 9)**, **Dr. Wang**, and **Martina Paul**: Various inputs related to standards and technical topics.

**Key Topics**:

1. **UNTP Governance and Extension Methodology**:

   - Steve introduced the UNTP extension methodology, designed to create industry-specific standards based on UNTP’s core. Discussions focused on extension governance, transparency, and the criteria for official UN endorsement.

2. **Digital Product Passport (DPP) Initiatives**:

   - Updates were provided on new collaborations with ISO TC154, IEC, and other regulatory groups to align DPP standards across industries. Dr. Wang’s potential involvement in the ISO TC154 project was noted.

3. **Technical Specifications for Extensions**:

   - Suzanne and others discussed the need for security profiles and identifier schemes for robust operational implementations. Agreement to add technical profiles, such as encryption and protocol requirements, to the extension methodology.

4. **Implementation Registration**:

   - Nis’s implementation of UNTP was acknowledged as the first to meet compliance requirements, with future test suites planned to verify consistency.

5. **Conformity and Visibility**:
   - Suggestions were made to improve visibility of UNTP implementations and their industry affiliations, enhancing marketing efforts to non-technical audiences.

**Next Steps**:

- Steve will merge the current extension methodology PR, and the team will refine with specific technical profiles.
- Nis and others will participate in initial test suite trials.
- UNECE will work on promoting UNTP implementation visibility, potentially adding links and marketing content for public accessibility.

## 2024-10-17 Meeting Summary

Meeting Summary

**Participants**:

- **Steve (Speaker 1)**: UN Representative and project lead on UNTP standards.
- **Phil (Speaker 5)**: Discussed the registration process for UNTP implementation.
- **Virginia (Speaker 6)**: Provided input on implementation and test suite requirements.
- **Gerhard (Speaker 4)**: Contributed insights on bulk product tracking.
- **GS1 Representatives (Speaker 2 and Speaker 3)**: Discussed identity standards and resolver frameworks.
- **Dr Wang Xiang**

**Key Discussion Points**:

1. **UNTP Credential Update**:

   - **Version 0.5.0**: Released for testing with credentials for digital product passports, conformity, traceability events, and facility records. Around 13-14 software providers and several regulatory bodies have committed to implementation.
   - **Implementation Registry**: A GitHub-hosted registration process guides companies in joining the initiative and tracks active implementers, marking a new approach for the UN in standard adoption tracking.

2. **Test Suite and Implementation Process**:

   - **Test Suite**: Expected in two weeks. The group recommended that companies wait for the suite to ensure consistent conformance testing.
   - **First Implementer**: Transmute has completed an initial implementation, but the group advised a formalized test to verify compliance.

3. **Identity Resolution Process**:

   - **Workflow Diagram**: Steve introduced a flowchart detailing steps to resolve, verify, and link identifiers, emphasizing both registered and self-issued identifiers. He highlighted a need to address bulk commodities like minerals.
   - **Challenges with Bulk Commodities**: Bulk products lack unique identifiers, complicating traceability. Suggestions included using shipment or consignment IDs for identification.

4. **Trust Anchors and Verification**:

   - **Potential of Trademark Offices**: EUIPO is considering involvement, where trademark verification could serve as a trust anchor for product claims.
   - **Domain and Business Registry Checks**: DNS ownership and business registries were discussed as potential trust mechanisms, though complex in some cases.

5. **GS1's Approach to Identity Resolution**:

   - **Cataloging Identifier Schemes**: Steve suggested a UN-hosted catalog for identifier schemes. Challenges included governance complexities and ensuring neutrality.

6. **Future Steps and Closing Remarks**:
   - **Further Asynchronous Feedback**: Steve invited ongoing comments on the resolver and bulk tracking processes.

**Next Steps**:

- Steve to raise a pull request (PR) for further review on the identity resolution process.
- Ongoing exploration of bulk commodity identification and potential collaboration with EUIPO on trademark verification.

---

This summary captures named participants, key decisions, and next steps discussed in the meeting.

## 2024-10-03 Meeting Summary

**Meeting Summary**

**Date:** October 3, 2024  
**Attendees:** Steve, Stefano, Brett, Virginia, Michael O'Shea, Christoph, Susanne, Peter Carter, Nancy, Luca, Dr Wang Xiang, and others.

---

**Agenda:**

1. **Zoom Meeting Timing Issues**

   - Steve mentioned difficulties with Zoom invites. Some participants received only the 8 a.m. invite and not the 8 p.m. one for the next meeting. Steve apologized and promised to resend the correct invites after the meeting.

2. **Business Case Content Discussion**

   - The meeting focused on reviewing the business case content developed by Michael O'Shea and his team. Steve emphasized that the business case section should be clear, simple, and provide value for stakeholders.

3. **Digital Product Passport (DPP) Technical Update**

   - Steve announced the release of version 0.4.1 for the DPP, including core vocabulary, facility records, and conformity credentials. There were a few minor technical bugs identified, which might lead to a version 0.4.2 release.
   - Michael also showcased a visualization tool for a lithium-ion battery passport, which was praised by the team.

4. **Bug Reports and Typos**

   - A participant from Canada found several bugs in the latest release, mostly typos and small technical issues like missing terms and empty context files. The team debated whether to fix these before the business case testing.
   - Christoph offered to help review the business case documents to ensure the technical and business sides align well.

5. **Business Case for Change**

   - Michael and his team presented their work on the business case for both private sector businesses and regulators. They discussed the need to balance the technical content and value statements in a way that appeals to both.
   - Christoph and Susanne provided feedback that the business case should distinguish between benefits for corporations and regulators to avoid confusion. They also suggested adding infrastructure-related benefits, specifically for regulators.

6. **Feedback on Business Case Template**

   - Steve asked for volunteers to review the business case model from a business perspective, ensuring it makes sense to potential adopters, especially in terms of convincing a CFO.
   - Christoph volunteered to help review the business case spreadsheet, and Steve proposed sending the document to the wider mailing list for feedback once it has been internally reviewed.

7. **Next Steps:**
   - Finalize version 0.4.2 of the DPP to address minor technical bugs.
   - Refine and simplify the business case content and spreadsheet to make it more accessible.
   - Collect feedback from the team and mailing list before publishing the business case template publicly.

---

**Next Meeting:**  
The next meeting will be in two weeks, and Zoom invites for both 8 a.m. and 8 p.m. sessions will be corrected and sent out.

## 2024-09-19 Meeting Summary

**Date:** September 19, 2024

1. **Steve (Speaker 1)** - Chairperson
2. **Stefano (Speaker 4)** - Contributor from Reload3P and Morpheus Network
3. **Nis (Speaker 5)** - Presenter of DPP implementation
4. **John (Speaker 6)** - Contributed to the discussion on meeting structure
5. **Suzanne (Speaker 3)** - Discussed the REC 49 policy document and traceability issues
6. **Sébastien (Speaker 9)** - Contributed to the technical discussion on GS1 standards
7. **Brett (Speaker 7)** - Provided insights on the TSM credential issue
8. **Michael (Speaker 2)** - Provided updates on the business case development

**Key Discussions and Contributions**

1. **Registration Requests:**

   - Steve introduced the agenda, primarily discussing new registration requests.
   - Stefano (Speaker 4) spoke about his contributions, including those from **Reload3P** and **Morpheus Network**. The work focuses on sustainability and transparency within supply chains.
   - Nish (Speaker 5) presented a **DPP implementation** on his platform, aiming to include **UNTP schemas** as a template, making it easier to issue credentials.
   - Steve also mentioned other registration requests, including those from Viko (not present) and an Australian scheme for structural steel.

2. **Pull Requests:**

   - Nish highlighted a pull request addressing minor **syntax bugs**. Steve admitted the errors might have occurred during manual editing and promised to check with Alistair.

3. **Upcoming Work on REC 49 Policy Document:**

   - Steve discussed the need to revisit the **REC 49 policy document**, considering feedback from the July 2024 plenary. The goal is to finalize the document for the next plenary in July 2025.
   - Steve proposed alternating **fortnightly meetings**, separating policy and technical discussions. John and Stefano supported this idea.

4. **Human Readability in Traceability Events:**

   - Steve proposed making **traceability events** more human-readable, adding optional human-readable properties. Stefano, Suzanne (Speaker 3), and Sébastien (Speaker 9) contributed to the discussion, suggesting using existing GS1 standards to improve readability.

5. **TSM Credential Issue:**

   - The group discussed a pattern where **different auditors** assess different sections of a standard over time, which leads to multiple assessments. Steve suggested adding an **auditor party reference** to the conformity credential model to solve the issue. Brett (Speaker 7) agreed with Steve's proposal.

6. **Business Case Updates:**

   - Michael and John provided an update on the **business case development**, focusing on business and public sector value arguments. Nancy’s input, particularly from the public sector perspective, was highlighted as key.

7. **Next Steps:**
   - Steve planned to raise tickets for various issues discussed and to prepare **pull requests** based on registration approvals and the business case document.

The meeting ended with a commitment to continue work on registrations, policy revisions, and technical improvements.

## 2024-09-11 Meeting Summary

**Participants:**

- **Steve Capell**
- **Virginia Cram-Martos**
- **Dr. Wang Xiang**
- **Christophe** (Association des Centraliens)
- **Joe** (last name not mentioned)
- **Esther** (last name not mentioned)
- **Brie** (last name not mentioned)
- **Patrick** (last name not mentioned)
- **Todd Taylor**
- **Nancy** (last name not mentioned)
- **Phil Archer** (not present, mentioned as being on holiday)

---

**1. Opening Remarks:**

- **Steve Capell** welcomed the participants and noted the absence of Phil Archer due to holiday. The meeting started with an agenda to discuss ongoing initiatives and updates on standards and implementations.

**2. Discussion on Standards and References:**

- **Virginia Cram-Martos** raised a couple of points regarding typos and clarity in a recently published page on references to standards. Specifically, she suggested improvements to the readability of certain sections, including changes to the terminology around cryptographic links and facility identities.
- There was a discussion on how UNTP should relate to standards like SEND and ISO, with the consensus being that these should focus on complementing existing standards rather than reinventing them.

**3. Technical Matrix for Standards:**

- **Virginia** and others provided feedback on a matrix listing standards and their relationship to UNTP components. There were suggestions to improve the readability of this matrix by possibly reformatting it or providing tooltips for acronyms to make it more accessible.

**4. Community Implementations:**

- **Steve Capell** reviewed several commitments to UNTP implementation that had been submitted over the past week. Notable entries came from the **British Columbia Government** and various software vendors.
- **Patrick** highlighted that BC's open-source governmental software could be leveraged by other provinces, emphasizing collaboration between BC, Ontario, and Quebec in developing tools like mobile wallets and identity solutions.

**5. Business Case and Metrics:**

- The discussion shifted to how UNTP would gather metrics on its implementation, with a consensus that any reporting should only include information that the implementing parties would be willing to publish publicly.
- **Brie** pointed out the importance of linking corporate-level and site/facility-level data, particularly for standards like TSM (Towards Sustainable Mining), which have different levels of granularity.

**6. Stability and Version Freezing for Pilots:**

- The group discussed freezing the UNTP version at **0.4.0** to stabilize the implementation for the next round of pilots. The goal is to ensure technical consistency while allowing further refinements based on pilot feedback.

**7. Next Steps:**

- **Steve Capell** proposed continuing discussions on identifying which remaining tickets need to be resolved before version 0.4.0 is finalized.
- There was also a brief discussion about cross-referencing implementations between UNTP and other projects, such as the **Critical Raw Materials (CRM)** project, to avoid duplication while maintaining transparency.

## 2024-09-05 Meeting Summary

**Meeting Participants:**

1. **Dr. Wang** - Provided an update on the UNTP presentation translation into Chinese
2. **Steve** - Discussed the TC154 project and provided updates
3. **Michael** - Business case development lead
4. **Phil** - Provided comments on vocabulary management
5. **Gerhard** - Commented on testing and evidence for implementations
6. **Nis** - Raised concerns about versioning and semantic context

**Key Discussion Points:**

1. **Translation and Feedback:**

   - Dr. Wang translated the UNTP (United Nations Trade Procedure) presentation into Chinese and received positive feedback during a workshop. This sparked further discussion on expanding outreach and engagement.

2. **TC154 Digital Product Passport Project:**

   - Steve provided updates on the ongoing work related to the TC154 Digital Product Passport. He mentioned that the ISO meeting, likely to occur in Korea in October, would decide whether to launch the project.
   - There was a one-on-one discussion with the project lead, emphasizing the need for a comprehensive program rather than a single standard, drawing parallels to existing multiple specifications.
   - Steve encouraged Dr. Wang to join future collaborations under TC154.

3. **Business Case Development:**

   - Michael shared that the team is working on a model to help businesses understand the impact of implementing UNTP and developing a business case around it.
   - Examples like the EU's Battery Pass Project and Surpass were discussed as templates for businesses to build their justification for implementation.

4. **Community Activation:**

   - There was a discussion on how community-level adoption of standards could enhance business cases, particularly in scenarios where multiple actors (e.g., farmers or manufacturers) use shared tools or processes, reducing costs and increasing benefits.

5. **Technical Infrastructure and Versioning:**

   - Several participants discussed the challenges related to managing vocabulary, version control, and ensuring consistency in the digital product passport pipeline.
   - A solution involving vocabulary sites, schema versioning, and simplified context files was introduced by Steve, while Nis raised concerns about frequent updates to context files and their potential to disrupt system setups.

6. **Implementation and Testing:**

   - The team discussed creating a register of implementations, inviting stakeholders to express their intent to implement UNTP standards. This will help assess the adoption of these standards.
   - The importance of evidence for successful implementation, such as test results, was emphasized by Gerhard and others.

7. **Next Steps:**
   - The pull request related to implementation registers and vocabulary updates was approved.
   - The meeting ended with a reminder to continue working on the pull requests and to solicit early expressions of interest from potential implementers.

## 2024-08-28 Meeting Summary

**Participants:**

- **Steve Capell**
- **Virginia Cram-Martos**
- **Dr Wang Xiang**
- **Ester Cunha**
- **Nancy** (last name not mentioned)
- **Michael O'Shea**
- **Anne** (last name not mentioned)
- **Joe** (last name not mentioned)
- **John Phillips**
- **Guy** (last name not mentioned)
- **Marcus** (last name not mentioned)

---

**1. Opening Remarks:**

- The meeting started with greetings from **Steve Capell**. **Steve** mentioned that the meeting might be brief due to a smaller group and the absence of full requests to review. The agenda was to share thoughts and discuss ongoing ideas.

**2. Project Updates:**

- **Steve Capell** provided an update on a meeting with ISO TC154 regarding a potential new project for a global digital product passport. This project is being pushed by the China National Institute of Standards and is in the early proposal stages. The project will be a joint collaboration with UNECE.

- **Nancy** discussed updates related to the UNTP extension site, focusing on the critical raw materials extension. She suggested creating a one-page value proposition template to assist early adopters, particularly mining companies, in implementing the UNTP.

**3. Business Case Development:**

- **Nancy** emphasized the importance of developing a business case framework that can evolve with more data during the pilot phases. She highlighted the need for a robust business case to secure funding for post-pilot projects.

- **Anne** and **Joe** provided updates on a spreadsheet they developed to guide participants through creating a value case or business case for UNTP implementation. The focus is on calculating ROI over a 10-year period.

**4. Community Activation:**

- **Steve Capell** discussed the necessity of community activation before moving into full implementation phases. He cited examples from Australian agriculture, where community activation was crucial for project success.

**5. Technical and Regulatory Challenges:**

- **Guy** raised challenges regarding the allocation of emissions to products, especially in critical minerals sectors. There was consensus that allocation rules are often unclear, and industry-specific guidance might be necessary.

- **Virginia Cram-Martos** asked about the conflict between counterfeit issues and the right to repair, leading to a discussion on the regulatory landscape and its impact on standards.

**6. Next Steps:**

- **Steve Capell** mentioned plans to establish a structure for registering commitment to implementation by different categories. There was also a focus on developing content for community activation and the business case guide.

- The meeting concluded with **Steve Capell** inviting participants to continue their contributions and to attend future meetings.

---

This summary includes the names of the participants and captures the key points discussed during the meeting. If you need further adjustments or more details on any section, please let me know!

## 2024-08-22 Meeting Summary

**Date:** August 22, 2024

**Speakers:**

- **Steve** (Host)
- **Michael O'Shea** (Speaker 4)
- **Phil** (Speaker 3)
- **Zach** (Speaker 2)
- **Nis** (Speaker 6)
- **Brett** (Speaker 7)

**Key Points:**

1. **Business Case Content Development:**

   - Steve introduced the development of business case content led by Michael O'Shea and his team.
   - The team has begun working on creating a table that outlines the business case by identifying stakeholders and categorizing value points.
   - The objective is to have a shareable document by mid-September, aiming to refine and organize the content for clarity.

2. **Digital Product Passport (DPP) Updates:**

   - Steve discussed updates to the digital product passport, including the inclusion of context and schema files to support future implementation.
   - Emphasis was placed on making the DPP consistent with existing standards and ensuring it is easy to implement while valuable for verification.

3. **Vocabulary and Schema Mapping:**

   - The team discussed the challenges of mapping data to established vocabularies such as schema.org and GS1.
   - The focus is on maintaining consistency and preventing issues like breaking proofs during versioning.

4. **Implementation Interest:**

   - There was discussion on the timing of soliciting commitments from organizations to implement the UNTP standard.
   - It was agreed that the right time is approaching, and efforts to socialize the project and secure interest should begin.

5. **Next Steps:**
   - Steve and the team will work on refining the business case and moving towards creating a stable 1.0 release by Christmas.
   - A call for implementers will be prepared to start gathering interest and commitments from potential adopters.

**Action Items:**

- Michael and his team will continue refining the business case content with the goal of having a draft ready by mid-September.
- Steve will work on fixing identified bugs and preparing materials to solicit implementation commitments.

**Next Meeting:**

- Focus will continue on the business case, schema updates, and gathering implementer commitments.

**Conclusion:**  
The meeting ended on a positive note, with everyone feeling that significant progress is being made towards finalizing the UNTP standard and building momentum for broader adoption.

## 2024-08-15 Meeting Summary

**Date**: August 14, 2024  
**Attendees**:

- **Steve** (Speaker 1)
- **Phil** (Speaker 2)
- **Virginia** (Speaker 4)
- **Zach** (Speaker 5)
- **Patrick** (Speaker 3)
- **Harley** (Speaker 13)
- **Todd Taylor** (Speaker 7)
- **Bree** (Speaker 8)

**Key Discussion Points**:

1. **Pull Request Review (Phil's Updates)**:

   - Phil discussed the simplification of terminology in the pull request. His changes primarily involved correcting typos and substituting GS1 references with corresponding ISO/IEC standards for event tracking and business vocabularies. This was done to align politically and avoid implying that GS1 identifiers are mandatory for using EPCIS.
   - Steve and others approved the pull request, agreeing to merge it as it was a simple update.

2. **ISO and UN Involvement in Global Digital Passport Standards**:

   - Steve mentioned an upcoming meeting at ISO to review a candidate project proposed by a Chinese standards authority to develop a global digital passport standard. He was invited to co-chair this initiative, potentially representing both the UN and ISO. The group discussed the significance of this project and the potential implications of having a UN co-chair involved.
   - Phil provided additional context, mentioning the Vienna Memorandum, an agreement between ISO and CEN-CENELEC to avoid duplication of efforts in standard development. He also noted GS1’s interest in participating in the project.

3. **New Digital Facility Record Proposal**:

   - Steve introduced the idea of adding a new credential type, a **Digital Facility Record (DFR)**, to the UN Transparency Protocol (UNTP). This record would focus on the facility itself rather than the product and could be used to track sustainability assessments at the facility level.
   - Virginia and Phil supported the idea, with Virginia suggesting the term "Facility Profile" to better represent the data. The group discussed how this could streamline sustainability reporting by making facilities first-order objects rather than secondary attributes of products.

4. **Challenges with Product Passport Updates**:

   - Zach raised concerns about updating digital product passports (DPPs) after they have been issued, such as adding post-sale repair events or certifications. The group acknowledged that while updates are crucial, there are challenges with ensuring that only authorized entities can modify the passport.
   - Steve proposed the idea of allowing certain events to be added to a product passport by authorized third parties, like certified repairers or recycling plants, using a delegated authority model.

5. **Formation of a Working Group**:

   - A new working group was formed, led by Zach, to explore solutions for managing updates to digital product passports. The group will work on defining the conditions under which updates can be made and will consider different approaches to identity resolution and authorization.

6. **Conformity Assessment Scheme Clarification**:
   - Bree raised a question regarding the linkage between conformity assessment schemes and regulations within the digital product passport framework. Steve clarified that in the context of product conformity, an assessment can reference multiple standards or regulations, bundled together in a scheme.
   - The group discussed how this framework might need to be adapted for regulatory permits and other credentials outside of product conformity.

**Action Items**:

- **Phil** and **Zach** to collaborate on a working group to explore digital product passport updates.
- **Steve** to create a proposal for the Digital Facility Record and present it for further review.
- **Bree** and **Patrick** to revisit the mapping of assessment schemes to regulations for conformity credentials and report back on potential updates to the framework.

**Conclusion**:
The meeting focused on refining standards around digital product passports, facility records, and conformity assessment schemes. The formation of a working group will drive further exploration of issues related to product passport updates and maintaining data integrity across complex supply chains.

## 2024-08-01 Meeting Summary

**Date:** August 1, 2024

**Speakers:**

- **Steve** (Host)
- **Martin Pompery** (Speaker 2)
- **Zach** (Speaker 3)
- **Christophe** (Speaker 4)
- **Virginia** (Speaker 5)
- **Nancy** (Speaker 6)
- **Phil** (Speaker 7)
- **Juliet** (Speaker 8)

**Key Points:**

1. **Introduction and Attendance:**

   - Steve began the meeting, noting the recording and summary availability.
   - Martin Pompery introduced himself as a co-founder of the SINA Foundation, focusing on carbon transparency protocols with the World Business Council for Sustainable Development.

2. **Business Case for the UNTP:**

   - Steve presented an initial contribution to the business case for the UNTP, highlighting the costs and benefits for potential implementers.
   - The business case was divided into three parts:
     - Costs and benefits for individual supply chain actors or regulators.
     - Costs and benefits for communities.
     - Reporting the value and cost of implementations for benchmarking.

3. **Feedback on Business Case:**

   - Christophe agreed with the categories but questioned the final product's specificity.
   - Virginia emphasized the need for cost-benefit arguments for public authorities and not-for-profits.
   - Nancy noted the importance of differentiating between pilot and long-term participation.

4. **Emissions and Circularity Performance in Digital Product Passports:**

   - Steve discussed adding emissions and circularity performance to digital product passports.
   - Emissions performance would include high-level carbon footprint data with scope and reference standards.
   - Circularity performance would measure linear flow index and utility, reflecting recycled content and product durability.

5. **Challenges and Considerations:**

   - Martin and Christophe highlighted the complexity and variability in measuring carbon footprints.
   - Zach questioned the governance structure for adding summary boxes and emphasized aligning with sustainable development goals.
   - The balance between simplicity for ease of implementation and the need for detailed, reliable data was a recurring theme.

6. **Future Steps:**
   - Agreement to merge the initial business case content and continue refining it.
   - Continued deliberation on representing frameworks like the Pathfinder Framework in digital product passports.
   - Emphasis on simplicity to encourage voluntary adoption while ensuring reliable and comparable data.

**Action Items:**

- Steve to merge the initial business case contribution and iterate based on feedback.
- Further discussion on the appropriate level of detail for emissions and circularity performance in digital product passports.
- Consideration of additional examples and practical applications to test the proposed structures.

**Next Meeting:**

- Focus on refining the business case and exploring practical examples of implementing the digital product passport framework.

**Conclusion:**
The meeting concluded with acknowledgment of valuable feedback and a commitment to ongoing collaboration to achieve a balanced and implementable framework.

## 2024-07-25 Meeting Summary

**Attendees:**

- Steve (Speaker 1)
- Phil (Speaker 2)
- Luis (Speaker 3)
- Suzanne (Speaker 4)
- Michael (Speaker 7)
- Virginia (Speaker 8)
- Zach (Speaker 5)
- Brett (Speaker 6)
- Marcus (Speaker 10)
- Vinayak (Speaker 9)
- Chris (mentioned)
- Gerhard (mentioned)
- Vladimir (mentioned)

**Agenda:**

1. Review of Previous Meetings and Updates
2. Discussion on TrustGraphs Demo
3. Pull Requests Review
4. Issues Discussion

**Key Points:**

**1. Review of Previous Meetings and Updates:**

- **Steve:** Recapped the presentations given at the recent forum and plenary sessions, highlighting the positive reception and support received, except for a minor objection from the European standards organization.
- Discussed expanding the group to include more people from non-technical backgrounds in sustainability and the potential for collaboration with CEN and ISO on new projects.

**2. Discussion on TrustGraphs Demo:**

- **Nis:** Inquired about a planned demo on TrustGraphs.
- **Steve:** Mentioned that Harley, who was supposed to present, is preparing a more refined demo incorporating recent standards, scheduled for two weeks later.

**3. Pull Requests Review:**

- **Suzanne's Pull Request:**
  - **Steve:** Suggested Suzanne review the latest content and update her pull request accordingly.
  - **Suzanne:** Agreed, mentioning she is still learning and appreciated the feedback.
- **Phil's Pull Requests:**
  - **Phil:** Made minor corrections to the naming of the W3C standard and clarified the terms VC and VCDM.
  - **Phil:** Added substantial content on global uniqueness and resolvability, including some necessary corrections.
- **Steve's Pull Request:**
  - **Steve:** Presented updates to the digital product passport page, making it more implementer-friendly with examples and snippets.
  - Discussions were held on further improvements, including explaining color codes in diagrams and fixing URLs and date formats.

**4. Issues Discussion:**

- **Sustainability Vocabulary Design:** Ongoing discussions on how to represent various standards and regulations meaningfully.
- **Units of Measure:** Phil confirmed that the current use of UN Rec20 codes is satisfactory.
- **Reference Standards Page:** Discussion on creating a separate page for reference standards and acronyms.
- **Human Observations as Valid Sensors:** Zach discussed the need for guidance on incorporating human observations in low digital maturity environments.
- **General Issues:** Several older issues raised by Gerhard and Vladimir were reviewed for potential closure.

**Next Steps:**

- **Steve:** Will address the feedback received on the digital product passport page and update the conformity credential page similarly.
- **Vinayak:** Volunteered to map the GBA's digital product passport data model to the UNTP framework.

**Action Items:**

1. **Suzanne:** To review steve's updates to her proposed changes
2. **Steve:** To fix issues on the digital product passport page and update conformity credentials.
3. **All:** To create a glossary page for standards and acronyms.
4. **Zach:** To incorporate feedback into discussions on human observations as sensors.
5. **Vinayak:** To map the GBA digital product passport data model to UNTP.

**Conclusion:**
The meeting concluded with thanks to all participants and a note that the next meeting will focus on further pull requests and issues.

## 2024-07-17 Meeting Summary

**Attendees:**

- Steve (Speaker 1)
- Jason (Speaker 2)
- Virginia (Speaker 2)
- Phil (Speaker 2)
- Zack (Speaker 2)
- Other unidentified speakers

**Key Points Discussed:**

1. **Meeting Logistics and Technical Issues:**

   - Steve welcomed participants and acknowledged technical issues faced by Virginia.
   - Virginia requested a list of acronyms to better understand emails and documents.

2. **Review of Recent Forum and Plenary Sessions:**

   - Steve reviewed the recent UNTP forum and plenary sessions, highlighting the presentations on VCs, security, language vocabularies, and business models.
   - Positive feedback and increased volunteer participation were noted.
   - Discussions on separating technical work from business use cases and engaging business experts from the UNECE Team of Specialists on Sustainable Value Chains.

3. **Concerns from CENELEC and Collaboration Opportunities:**

   - CENELEC, the European Standards Body, expressed concerns about potential duplication of work with the UNTP.
   - Robust discussion ensued, with other member states (USA, Canada, Australia, Singapore) supporting a global standard.
   - Proposal to collaborate with CENELEC to ensure interoperability and avoid duplication.
   - Discussion on lobbying the European Commission to support the UNTP's global standard approach.

4. **Integrating Business Experts into Technical Sessions:**

   - Suggestions on how to integrate business experts into technical sessions, either by inviting them to specific meetings or having dedicated sessions for business input.

5. **Pull Request Review and Data Model Updates:**

   - Steve presented a significant pull request addressing multiple issues and reorganizing business objects into a separate vocabulary for better consistency and reuse.
   - Discussion on the importance of proper data structure for creating transparency graphs in supply chains.
   - Request for a detailed walkthrough of the data model to help team members understand the changes and contribute effectively.

6. **Tooling and Versioning for Context Files and Vocabularies:**

   - Introduction of a deployment pipeline for versioned vocabularies and context files to ensure stable and robust implementations.
   - Emphasis on the need for good governance and tooling to maintain consistency and prevent breaking changes in issued credentials.

7. **Next Steps and Action Items:**
   - Plan to write a response to the German delegation, engaging with the European Commission for support.
   - Agreement to focus the next meeting on a deep dive into the data model and its associations.
   - Encouragement for team members to review the merged pull request and provide feedback.

**Meeting Conclusion:**

- Steve thanked everyone for their participation and contributions.
- The meeting concluded with a positive note on the ongoing implementations and the significant progress being made.

## 2024-07-04 Meeting Summary

**Participants:**

- Speaker 1 (Steve)
- Speaker 2 (Patrick)
- Speaker 3 (Joe)
- Speaker 4 (Marcus)
- Speaker 5 (Anne)
- Speaker 6 (Mark)
- Speaker 7 (Other Participants)

**Key Points Discussed:**

1. **Introduction and Agenda:**

   - Steve welcomed participants and reiterated the meeting recording policy and IP contributions disclaimer.
   - Mentioned the upcoming UNCFACT forum and plenary, highlighting sessions involving UNTP.

2. **New Participants:**

   - Mark, Rocky, and Tomas from Canada introduced themselves as potential implementers in the plastics value chain.
   - Anne and Dow from Canada also introduced themselves, working on digital product passports.

3. **Pull Request Reviews:**

   - **Digital Product Passport Update:**
     - Suzanne's PR suggesting a single unique identifier for products instead of an array was discussed.
     - Agreement to merge after minor adjustments (e.g., removing the 's' from identifiers).
   - **Trust Graphs and Wallets:**
     - Suzanne's PR on trust graphs and wallet presentations was not merged.
     - The team agreed to avoid technical dependencies on wallets, focusing instead on a publish and discover architecture.

4. **Discussion on JSON-LD and JSON Schema:**

   - Steve shared insights on the use of JSON-LD and JSON Schema for managing vocabularies and credentials.
   - Emphasis on making life easier for implementers by providing clear schemas and context files.
   - The goal is to construct meaningful transparency graphs for verifiers.

5. **Conceptual Model and Transparency Graph:**

   - Discussion on the conceptual model showing relationships between entities like products, organizations, and facilities.
   - The importance of identifiers and the relationship between entities was emphasized.
   - The aim is to create a transparency graph that can be easily consumed and interpreted.

6. **Future Steps:**
   - Plans to finalize and publish updated models for digital product passports, conformity credentials, and traceability events.
   - Encouragement for participants to review and provide feedback on the proposed changes.

**Action Items:**

- **Steve:** Finalize and merge the PR for the single unique identifier and update the digital product passport model.
- **Team:** Review and provide feedback on the proposed updates to the models and context files.
- **Steve:** Prepare pull requests to align models with the discussed conceptual framework.

**Next Steps:**

- Continue refining the models and schemas to ensure they are implementable and interoperable.
- Prepare for testing the models with various extensions and real-world use cases.

## 2024-06-27 Meeting Summary

**Date:** June 27, 2024

**Participants:**

- Steve
- Gerhard
- Zach
- Susanne
- Harley
- NIS
- Virginia

**Agenda:**

1. Review of Public Comments on Recommendation 49
2. Timeline and Plan for Addressing Comments
3. Discussion on Specific Comments
4. Digital Identity Anchor Credential
5. Governance and Versioning of Standards

**Key Points:**

1. **Introduction and General Updates:**

   - Steve welcomed everyone and emphasized the importance of contributions to the project.
   - The public review period for Recommendation 49 has concluded, and comments have been circulated via email.

2. **Review of Comments on Recommendation 49:**

   - Comments varied from editorial to substantive, with significant input from Gerhard.
   - The team has a weekend to draft responses and update the document before the plenary meeting in two weeks.
   - Steve asked for volunteers to help review and respond to the comments. Zach and Speaker 2 offered assistance.

3. **Discussion on Specific Comments:**

   - Gerhard suggested prioritizing substantive comments over editorial ones.
   - Some comments highlighted confusion between transparency and traceability in the document's title and content.
   - The team plans to consolidate and prioritize comments, creating a response log for internal review over the weekend.

4. **Digital Identity Anchor Credential:**

   - Introduction of a new credential to link digital identities with authorized registers (e.g., Australian business number).
   - Discussion on aligning with verifiable legal entity identifiers (VLEI) and ensuring compatibility with existing standards.

5. **Governance and Versioning of Standards:**

   - Presentation of a diagram to illustrate the governance and extension of digital product passports and related credentials.
   - Agreement to maintain long-term versions and ensure stability of standards and references.
   - Discussion on the inclusion of external vocabularies (e.g., schema.org) alongside UN-specific vocabularies.

6. **Issues and Actions:**
   - Several tickets and issues were reviewed, including automated policy execution and maintaining versions of standards.
   - Harley volunteered to present a demo on trust graphs and shackle rule validation in four weeks.

**Next Steps:**

- Address and finalize responses to public comments on Recommendation 49 by Monday.
- Update and publish the digital identity anchor credential after resolving outstanding issues.
- Continue discussions on governance and versioning, incorporating feedback from the broader standards community.
- Prepare for the next meeting, focusing on traceability events and further issues.

**Action Items:**

- Zach and Steve to create an integrated comments log for Recommendation 49.
- Steve to update the project page with relevant links and descriptions.
- Harley to prepare a demo on trust graphs for the meeting in four weeks.
- Team to review and provide feedback on the governance diagram and proposed standards extension approach.

This summary captures the main points and action items from the meeting. If any participant has additional comments or corrections, please share them before the next meeting.

## 2024-06-19 Meeting Summary

**Participants:**

- Speaker 1 (Chair)
- Speaker 2 (Patrick)
- Speaker 3 (Zach)
- Speaker 4 (Phil)
- Speaker 5 (Steve)
- Speaker 6 (Nis)
- Speaker 7 (Juliet)
- Speaker 8 (Dr. Wang)

**Key Points Discussed:**

1. **Implementation Tools and Reference Implementations:**

   - Discussed the distinction between implementation tools and reference implementations.
   - Emphasis on the need for a toolkit to help implementers test and ensure interoperability with UNTP.
   - Concerns about long-term funding for test suites and the potential for community contributions.

2. **Rendering Methods for Verifiable Credentials:**

   - Debate on whether to mandate a specific rendering method.
   - Agreement to use a “should” directive for rendering methods, specifying HTML as the primary method but allowing for additional methods.
   - Adjustments to the wording to reflect this approach.

3. **Conformity Credential Alignment:**

   - Discussion on aligning conformity credentials with the VCDM (Verifiable Credential Data Model).
   - Decision to manage status externally rather than within the credential to avoid reissuing credentials for status changes.
   - Agreement on using existing VCDM fields where applicable and not duplicating fields within the credential.

4. **Identity Resolver Naming:**

   - Phil suggested renaming “digital link resolver” to “identity resolver” to avoid confusion and potential trademark issues.
   - Agreement to adopt “identity resolver” as it better describes the function.

5. **Site Restructure and Business Case Promotion:**

   - Site restructuring to align with the five-pillar architecture model and updated component names.
   - Elevated the business case section to highlight the importance of commercial incentives and funding for sustainable supply chains.

6. **Versioning of Context Files:**

   - Discussion on the appropriate granularity for context files.
   - Consensus on having separate context files for each core data credential type to simplify management and maintainability.
   - Emphasis on aligning versioning of data models, schemas, and context files.

7. **Use of Jargon Tool for Model Generation:**
   - Overview of the Jargon tool used for generating schemas and context files.
   - Acknowledgment of the need for high-quality outputs and flexibility in tool usage.
   - Open to reassessing the tool’s use based on implementation feedback.

**Action Items:**

- **Patrick and Nis:** Update the conformity credential model to align with VCDM fields and manage status externally.
- **Zach:** Update the wording for rendering methods to reflect the new “should” directive.
- **Steve:** Finalize and merge the PR for identity resolver renaming and site restructuring.
- **Team:** Review and experiment with the Jargon tool to ensure it meets quality expectations for generating context files.

**Next Steps:**

- Finalize the updates to data models and context files before the next meeting.
- Prepare for discussions on the content of digital product passports and business content in upcoming calls.

## 2024-06-13 Meeting Summary

**Participants:**

- Steve (Speaker 1)
- Nis (Speaker 2)
- Zach (Speaker 6)
- Cliff (Speaker 2)
- Patrick (Speaker 3)
- Ksenia (Mentioned)
- John (Speaker 5)
- Suzanne (Speaker 3)

**Key Points Discussed:**

1. **Pull Requests Review:**

   - **Testing Architecture PR by Zach:**

     - Discussion on merging Zach's updated testing architecture, which simplifies the previous bullet-heavy document.
     - Consensus to merge despite it being in draft to move forward.

   - **Mill Test Report PR by Nis:**

     - Addressed issue 19 regarding steel mill test reports conforming to schema.
     - Decision to close and start fresh aligning with the layered architecture approach.

   - **Digital Livestock Passport:**

     - A practical extension example for the Australian digital livestock passport project.
     - Closed PR without merging, left a comment on the required alignment.

   - **Context and Schema Files by Nis:**

     - Added basic context and schema definitions to aid in linked data implementation.
     - Agreement on merging the PR despite the incomplete schema, with an action to improve alignment.

   - **Reference Implementations by Zach:**
     - Deferred merging Zach’s reference implementations pending more complete content.

2. **Architecture Overview Discussion:**

   - Presented a diagram outlining the components of the UNTP specifications.
   - Discussed sections including Digital Identity Anchor, Decentralized Access and Control (DAC), and semantic understanding of data.
   - Emphasis on practical guidance using existing technologies like GLEIF’s Verifiable Legal Entity Identifier and Trust Over IP’s Trust Registry Protocol.

3. **Methodology for Model and Schema:**

   - Addressed the collision of top-down (model-driven) and bottom-up (instance-driven) methodologies.
   - Decision to use Nis’s practical instances to guide model updates and schema generation for alignment.

4. **Additional Business:**
   - Agreement on renaming “trust graph” to “transparency graph” to avoid confusion.
   - Planned actions to update documentation, align naming conventions, and ensure completeness of the context and schema files.

**Action Items:**

- **Steve:** Update the jargon generator to produce schema and context files that align with Nis’s examples.
- **Nis:** Assist with reviewing and validating the updated model-generated artifacts.
- **Steve:** Merge the updated architecture overview and realign website content accordingly.
- **John and Suzanne:** Continue contributions to decentralized access control and digital identity anchor discussions.
- **Team:** Prepare for testing the digital product passport model in various industry contexts.

The next meeting is scheduled in two weeks for further technical reviews and business discussions on the practical implementation of the digital product passport.

## 2024-06-05 Meeting Summary

**Attendees:**

- Steve (Speaker 1)
- Virginia (Speaker 3)
- Jason (Speaker 5)
- Patrick (Speaker 2)
- Marcus (Speaker 4)
- Other unidentified speakers

**Key Points Discussed:**

1. **Meeting Organization and Participation:**

   - Steve acknowledged the need to increase participation in meetings through better marketing.
   - Reminded attendees that this is a UN meeting and contributions are considered UN IP.
   - Steve mentioned that meetings are recorded and transcriptions are published.

2. **Meeting Transcription and Summary Process:**

   - Steve shared updates on how meeting transcriptions and summaries are managed.
   - Introduced a table format for meeting summaries with video transcripts, text transcripts, GPT summaries, and one-sentence summaries for quick reference.

3. **Pull Requests and JSON Schema vs. JSON-LD Context:**

   - Discussion on handling pull requests and differences between JSON schema (structure) and JSON-LD context (meaning).
   - Steve shared a detailed explanation and a diagram to clarify these differences, using examples like a verifiable credential describing a traceability event for a bale of cotton.

4. **Challenges with JSON-LD Context and Semantic Interoperability:**

   - Steve highlighted the challenges in mapping complex, abstracted data models to meaningful terms in a consistent way.
   - Illustrated the difficulty with an example involving transport means and IMO numbers, emphasizing the problem with abstract structures in JSON-LD context files.

5. **Discussion on Governance and Granularity:**

   - Patrick and Marcus contributed to the discussion on how to manage the complexity and granularity of context files.
   - Marcus suggested using catalog entries to manage multiple schemas and context files, which could help in maintaining semantic integrity and version control.
   - The need for proper governance to ensure correct mappings and avoid wrong semantic interpretations was emphasized.

6. **Principles for Managing Context Files:**

   - Agreement on keeping context files small, semantically correct, and aligned with specific use cases.
   - Steve proposed focusing on manageable granularity for context files, suggesting one context file per credential schema to simplify governance and changes.

7. **Future Steps:**
   - Plan to open an issue for further discussion on mapping complexity and balance.
   - Aim to document guiding principles for UNTP governance and implementers.
   - Acknowledgment that more discussion and iteration are needed to refine the approach.

**Action Items:**

- Steve to draft guiding principles for context file management.
- Open an issue for further discussion on mapping complexity and balance.
- Follow-up discussions to refine the approach based on feedback and further exploration.

**Meeting Conclusion:**

- Steve thanked everyone for their participation and contributions.
- The meeting ended with an acknowledgment of the need for ongoing collaboration to address the challenges discussed.

## 2024-05-30 Meeting Summary

**Attendees:**

- Zachary
- Stefano
- Michael
- Joe
- Bill
- Peter
- Various team members

**Key Points Discussed:**

1. **Pull Requests:**

   - Zachary presented his closed pull request related to test architecture. He acknowledged the need to update it based on Steve's feedback and plans to do so by next week.
   - Discussion on merging half-baked pull requests to ensure progress and avoid stagnation.

2. **Issues:**

   - The team has 50 open issues, with a tendency to create more than they resolve.
   - **Selective Disclosure Use Cases and Requirements:** This issue is on hold, with a potential demo for the UN forum being considered.
   - **PDF Generator Issue:** Assigned to three people, none of whom were present. It was suggested to put a note for easy conversion of GitHub sites to PDF documents and possibly mark the issue as pending close.
   - **Right to Repair Regulations:** Stefano highlighted the importance of aligning with EU regulations on this matter to enhance document alignment. He volunteered to draft relevant verbiage.
   - **Depth of Product Information:** The team discussed the necessity of tracking both upstream and downstream information, debating the practical limits and methods for maintaining depth without overcomplicating the process.
   - **Discovery Mechanism:** Discussion on the challenge of linking product information if the physical identifier is lost. No immediate solution was found, and the issue might be closed without action or tagged for future consideration.

3. **Technical Discussions:**

   - The challenge of maintaining a dynamic and evolving digital product passport was discussed, with considerations on how to append information without altering the original document.
   - There was a consensus on the importance of linked product passports, with each tier in the supply chain responsible for creating and maintaining their own passports and linking them appropriately.
   - Verification and validation processes for credentials were discussed, with the need to detail steps for verifying issuers, data, schema, and status.
   - Discussion on certificates of conformity and the need for a practical way to refer to specific sections within a comprehensive conformity document.

4. **Future Actions:**
   - Explore solutions for appending information to digital product passports without compromising the original data.
   - Open new tickets to address specific downstream right-to-repair solutions.
   - Investigate the potential need for a central registry or blockchain solution to ensure the longevity and accessibility of digital product passports.
   - Ensure alignment with existing standards and leverage the work done by related bodies.

**Conclusion:**
The meeting covered a range of issues from pull requests to regulatory alignment and the technical challenges of digital product passports. The team agreed on the need for continued exploration and development in these areas, with specific action items identified for follow-up. The meeting ended with the decision to be more aggressive in closing unresolved issues to maintain a manageable list.

## 2024-05-23 Meeting Summary

**Participants:** Virginia, Steve, Patrick, Zach, Gerhard, Marcus, John, Virginia, Joe, Phil, Harley, Juliet, and others.

**Key Points Discussed:**

1. **Attendance and Meeting Logistics:**

   - Various participants joined from different locations, including Steve on a yacht in Corfu.
   - Technical difficulties were experienced by some participants with the meeting link.

2. **Meeting Overview:**

   - The meeting was recorded and contributions are governed by a UN project.
   - The agenda focused on pull requests, updates to tickets, and related discussions.

3. **Pull Requests and Sample File Updates:**

   - A pull request discussed was about updating a sample file for the digital product passport.
   - The sample file was initially populated with real data from a participant's wife's company, which was then genericized.
   - Agreement to merge the pull request after making it align better with the VC data model.

4. **Discussion on Naming and Structuring Digital Product Passports:**

   - Debate on the appropriate terminology for types of credentials and subjects within the digital product passport.
   - Suggestions included keeping terms like "product passport" consistent and aligned with the data model.
   - The group discussed the implications of using terms like "digital" in various contexts.

5. **Alignment with the VC Data Model:**

   - Agreement that the digital product passport should not compete with but rather use the VC data model.
   - Proposed changes include aligning the example data and the data model, and updating the website accordingly.

6. **Trust Graph vs. Transparency Graph:**

   - Extensive discussion on the terminology to describe the assessment of linked data within digital product passports.
   - Alternatives considered included "trust graph," "provenance graph," "evidence graph," and "transparency graph."
   - Consensus leaned towards using "transparency graph" to avoid confusion and to better align with the project's goals.

7. **Reference to W3C Provenance Model:**

   - Marcus suggested using the W3C Provo ontology as a framework for describing the evidence or transparency graph.
   - This approach would help in structuring and querying the data to provide a clear lineage and validation of the information.

8. **Action Items:**
   - Steve to make the discussed changes to the pull request and update the data model and website.
   - Participants to review the W3C Provenance Model and consider its integration into the project specifications.
   - Further refinement and alignment of terminology and models in future discussions.

**Next Steps:**

- Follow-up on the discussed changes and updates.
- Continued refinement of terminology and alignment with established data models.
- Ongoing review and merging of pull requests as per the consensus reached.

**Closing:**

- The meeting concluded with an acknowledgment of the productive discussion and the clarity gained on several topics. Participants were thanked for their contributions.

For more detailed information, the full meeting recording and notes are available for review.

## 2024-05-16 Meeting Summary

**Date:** May 16, 2024

**Participants:** Various speakers including Steve, Phil Archer, Nis, Suzanne, and others.

#### Key Points Discussed:

1. **Introduction and IP Reminder:**

   - Contributions to the project are under the UNIP framework.
   - Agenda includes discussing outstanding pull requests, ongoing tickets, and the relationship between schema, context files, and vocabularies.

2. **Pull Requests Review:**

   - **Minor Typo Fix:** A simple typo correction was merged without objections.
   - **Example Update:** An update to the example in the passport and conformity credential sections was discussed. Concerns about using a real company's product (buyacre.com) were raised, suggesting a switch to imaginary examples to avoid IP issues.

3. **Test Architecture Proposal:**

   - Introduction of a three-tier conformance testing model: technical interoperability, schema testing, and business workflow testing.
   - Emphasis on ensuring must/should requirements are testable.
   - Discussion on using existing W3C test suites for core elements and defining additional tests for extensions.

4. **Linked Data and JSON-LD Context Files:**

   - Importance of linked data for ensuring consistent meaning across multiple instances.
   - Strategy to keep JSON-LD context files light and map only necessary elements to avoid complexity and incorrect mappings.
   - Agreement to develop the data model first and then map to established vocabularies.

5. **Issues and Tickets:**

   - Several issues tagged as pending closure after aligning models with VCDM.
   - Ongoing discussions on specific issues, with updates and resolutions expected in future meetings.

6. **External Collaborations and Standards:**
   - Steve presented at the Surpass kickoff, discussing alignment with the European Commission's efforts on product passports.
   - Suzanne highlighted the need to align with JTC 24 standards, focusing on product passport issuance and upstream supply chain data integration.
   - Proposal to establish a formal liaison with JTC 24 through the UN.

#### Actions and Next Steps:

1. **Steve:**

   - Work with Nis to update example models with non-proprietary products.
   - Align data models with VCDM and prepare for pilot implementations.
   - Follow up on establishing a formal liaison with JTC 24 through the UN.

2. **Phil Archer:**

   - Review any references to secure QR codes and update the test suite as needed.
   - Monitor and update the alignment with JTC 24 standards.

3. **Suzanne:**

   - Provide guidance on establishing a liaison with JTC 24.
   - Monitor JTC 24 activities and report back on potential divergences or necessary alignments.

4. **All Participants:**
   - Review the updated data models and provide feedback in the next meeting.
   - Engage in discussions on trust graphs and interoperability in upcoming calls.

#### Closing Remarks:

- Meeting ended 15 minutes early, with participants appreciating the extra time. The next meeting will focus on updates to the data models and further discussions on trust graphs.

## 2024-05-09 Meeting Summary

**Attendees:**

- Speaker 1 (Steve)
- Speaker 2 (Patrick)
- Speaker 3 (Virginia)
- Speaker 4 (John)
- Speaker 5 (Marcus)
- Speaker 6 (Unidentified)
- Speaker 7 (Unidentified)

**Agenda:**

1. Review of Outstanding PRs
2. Discussion on Key Tickets
3. Assignment Updates

**Key Points:**

1. **General Updates:**

   - Steve is currently anchored in Hvar, Croatia.
   - Meeting participants are from various time zones, with some joining late at night.

2. **Recording and Contributions:**

   - Meeting is recorded and contributions are for UNIP.
   - Participants are reminded that if they do not wish to contribute to UNIP, they should refrain from sharing ideas.

3. **Review of PRs:**

   - Only one pull request was discussed, which focused on enriching the content for conformity credentials.
   - The PR aims to align with existing business requirement specifications and the logical model of digital product conformity certificates.
   - Discussion about aligning fields with the VC (Verifiable Credentials) data model, particularly the "issuer" field.

4. **Feedback on PRs:**

   - Nis provided feedback on the PR, suggesting alignment with the VC data model.
   - Discussion on avoiding duplication of information and using complex objects in the VC issuer field.
   - Decision to merge the current PR and address alignment in subsequent revisions.

5. **Trust Graphs:**

   - Discussion led by John on the concept of trust graphs and the complexity of defining absolute measures of trustworthiness.
   - Agreement that trust decisions should be subjective and context-dependent, rather than protocol-defined scores.

6. **Rendering Methods:**

   - Patrick discussed the use of OCA (Overlays Capture Architecture) for rendering credentials, supporting multiple languages and additional metadata.
   - Emphasis on separating rendering logic from the data integrity of credentials.

7. **Multilingual Support:**

   - Debate on whether multilingual support should be embedded within the credential or handled through external overlays.
   - Consensus on using governed presentation layers for multilingual support to keep credentials simple and maintainable.

8. **Action Items:**

   - Align digital product passport models with the VC data model.
   - Remove the scoring elements from the digital product passport to avoid complications and ensure clarity.
   - Write a ticket to formally propose the removal of scoring from the digital product passport (John).

9. **Other Discussions:**

   - Mention of the Australian Agriculture Traceability Protocol as a model for implementing similar initiatives.
   - Steve highlighted a new publication from the Australian Government on agricultural traceability, noting the influence of UNTP.

10. **Closing Remarks:**
    - Steve thanked participants and emphasized the importance of aligning with the VC data model.
    - Next steps include continuing work on assigned tickets and discussing progress in the next meeting.

**Next Meeting:**

- Participants will continue with their assigned tasks and discuss further progress in the following week.

This summary captures the main points and action items from the meeting, ensuring clarity on the next steps and ongoing discussions.

## 2024-04-25 Meeting Summary

**Meeting Start and Introductions:**

- The meeting was initiated by Speaker 1, who took over the role of Master of Ceremony due to Steve being on a flight.
- Attendance included a significant Australian contingent despite it being a public holiday in Australia.
- Steve is traveling to China to coordinate supply chain pilot projects in the battery and critical mineral manufacturing process.

**Agenda and Objectives:**

- Review and process of open pull requests.
- Assignment and movement of stale issues.
- Emphasis on facilitating broader collaboration within the group.
- Encouragement for discussions to be taken offline or into Slack channels unless mission-critical.

**Key Points Discussed:**

1. **Pull Requests:**

   - Three pull requests were reviewed.
   - Major update to the traceability event schema by Steve was discussed, aligning more closely with the GS1 EPCIS standard.
   - Gerhard suggested creating an issue to compare the current model with the existing data models used in other sectors like animal track and trace and textiles.
   - Another pull request involved adding a governance section to describe the collaboration process.
   - A minor but potentially controversial pull request to remove an "out of place header" was discussed. The group decided to create a ticket to further explore the verifiability of identifiers before merging the pull request.

2. **Issues:**
   - Several issues were discussed, including the addition of page listing referenced standards, digital product passport sample files, and UNTP extensions methodology.
   - Gerhard highlighted the importance of maintaining interoperability by having a concise data model applicable across different industries.
   - Marcus and Virginia emphasized the need for clear guidance on how extensions fit within the core data structures and the governance process for managing these extensions.

**Action Items:**

- Creation of issues for comparing data models and verifying identifiers.
- Assignment of tasks to specific individuals, including Zach taking on the task of providing a digital product passport sample file.
- Further discussion on trust graph validation and the relationship between extensions and the core UNTP specifications.

**Closing Remarks:**

- The meeting concluded with thanks to Zach for leading the session in Steve's absence.
- A reminder for continuous collaboration and the importance of adhering to the process for pull requests and issue discussions.

This summary captures the main points and action items from the meeting, providing a concise overview for those who were unable to attend.

## 2024-04-18 Meeting Summary

#### Participants:

- Speaker 1
- Nis (Master of Ceremonies)
- Phil
- Susanne
- Steve
- Zach
- Michael
- Gerhard

#### Key Points Discussed:

1. **Reminder on Contributions:**

   - Contributions made to the GitHub repository are contributions to United Nations Intellectual Property (UN IP).
   - External specifications like GS1 and W3C can be referred to, but unique content belongs to UN IP.

2. **Streamlining Specification Sections:**

   - Discussion on the need to streamline the specification sections due to too many headings.
   - Proposal to handle this later in the normal order of pull requests and issues.

3. **Pull Requests:**

   - **Pull Request 57 by Phil:**
     - Focused on identifying discoverability and the pervasiveness of scanners and software.
     - Positive feedback and agreement to build incrementally on the contributions.
   - **Pull Request 59 by Zach:**
     - Simplified goals based on previous discussions, addressing issue 53.
     - Merged with no objections.
   - **Pull Request by Steve:**
     - Added verifiable credentials section, discussing business requirements and existing technical specifications.
     - Emphasis on conservative issuance and flexible verification.
     - Merged with no objections.

4. **Issues Discussion:**

   - **Issue 9 (Verification and Trust Graphs):**
     - Proposal to use business-friendly examples and diagrams to explain trust graphs.
     - Three common patterns identified:
       1. Same identity across different credentials.
       2. Conformity credential linked to claim.
       3. Certifier accredited by a trusted third party.
     - Commitment to create a PR with these examples for further discussion.

5. **General Agreement:**
   - Need for more use cases to test the scenarios and specification.
   - Encouragement for more participants to lean in and help move forward with the tasks.
   - Importance of balancing detailed discussions with progress on issues.

#### Actions and Assignments:

- **Steve and Suzanne:** Collaborate on creating examples and diagrams for the trust graph patterns.
- **Phil:** To work on aligning terminologies (must, should, may) with IETF standards.
- **All participants:** Add comments on issues directly in GitHub for better tracking and follow-up.

#### Next Steps:

- Assign issues before discussions in the next meeting.
- Ensure more focused discussions to cover more issues efficiently.

#### Closing Remarks:

- Commitment to improving the pace of progress while bringing everyone along on the journey.
- Meeting adjourned with a plan to implement better structure in future meetings.

This summary captures the essence of the meeting, the key decisions made, and the next steps agreed upon. If you need any specific details from the transcript, please let me know!

## 2024-04-11 Meeting Summary

**Attendees:**

- Steve
- Patrick
- Susanna
- Virginia
- Susan
- Becky
- Nancy
- Zach
- Carolyn
- Joe
- Stephen
- Other Participants

**Main Discussion Points:**

1. **Introduction and Setup:**

   - Initial greetings and setting up systems.
   - Discussion on the global timing of the meeting to accommodate different time zones, primarily focusing on American and Canadian colleagues.

2. **Podcast Mention:**

   - Mention of a podcast with Darrell O'Donnell and the suggestion to share the link in the Slack channel.

3. **Meeting Formalities:**

   - Reminder that contributions are for U.N. IP and that the meeting is recorded.
   - Standard procedure involves reviewing open pull requests and discussing issues.

4. **Digital Product Passport (DPP) Development:**

   - Emphasis on the need to start looking at industry use cases.
   - Discussion on the GBA digital product battery passport and ISO standard for digital product circularity.
   - Agreement to merge changes related to the product passport data model.

5. **Use Cases and Industry Pilots:**

   - Discussion on industry-specific pilots for testing the feasibility and value of the DPP.
   - Mention of upcoming pilots in agriculture and critical raw materials.
   - Carolyn shared a slide explaining the value chain and the application of the UNTP framework.

6. **Trust and Credential Verification:**

   - Discussion on trust registries and methods for verifying the trustworthiness of credential issuers.
   - Different approaches were considered, including the use of DID (Decentralized Identifiers) and linked credentials.
   - Example of the Australian Business Register and how it could issue credentials to businesses.

7. **Verifiable Credentials and Exchange Models:**

   - Debate on the best practices for exchanging verifiable credentials, whether wallet-to-wallet or through a publish and discover model.
   - Reference to a project that involved publicly discoverable credentials and lessons that could be relevant for UNTP.

8. **Technical Infrastructure and DID Methods:**

   - Concerns about the infrastructure for DID web and potential lock-in with service providers.
   - Suggestion to develop recommendations for DID methods suitable for different use cases, such as small businesses and product identifiers.

9. **Upcoming Tasks and Assignments:**
   - Agreement to work on a prototype for linked credentials and identity verification.
   - Decision to use Slack more actively for offline discussions to expedite progress.

**Action Items:**

- Patrick to write a summary of lessons from the discussed project and how they might impact UNTP.
- Stephen Curran to work on a prototype for verifying linked credentials.
- Create a ticket for recommending DID methods for different use cases.
- More active use of Slack for ongoing discussions and resolving tickets.

**Next Meeting:**

- The next meeting will be held at a time more convenient for European participants.

**Additional Notes:**

- Suzanne from the World Economic Forum and the Global Battery Alliance participated for the first time.
- Stephen Curran introduced a new DID method called Trusted Web, which could be relevant for the project's needs.

This summary captures the key points and discussions from the meeting on April 10, 2024.

## 2024-04-04 Meeting Summary

**Attendees:**

- Steve (Speaker 1)
- Nisht (Speaker 2)
- SAC Representative (Speaker 8)
- Michael Shea (Speaker 9)
- Virginia (Speaker 5)
- Brett (Speaker 7)
- Gerhard (Speaker 3)
- Joe (Speaker 4)
- Ashley (Speaker 6)

**Key Points Discussed:**

1. **Recording and IP Contribution:**

   - **Steve** reminded everyone that contributions are voluntary, and IP is contributed to the UN.
   - A recording will be posted for those who couldn't attend.

2. **Digital Product Passport (DPP):**

   - **Steve** requested additional discussion time on DPP updates.
   - Issues with pull requests (PR) were discussed, particularly around supply chain depth clarification.
   - Agreement to merge a PR and address depth in a subsequent PR.

3. **Pull Requests and Issues:**

   - A PR from **SAC Representative** was discussed. It was agreed to merge it with follow-up clarifications.
   - Discussion on identifiers for entities and products, emphasizing the need for multiple identifiers (e.g., GLN, ABN, DID) and the ability to verify them.
   - Importance of having robust claims for product categories and items, considering changes over time.

4. **Granularity in Product Claims:**

   - **Virginia** and **Gerhard** led a detailed discussion on handling product claims at different levels (e.g., product class vs. individual items).
   - Emphasized the necessity of batch numbers and serialized identifiers for traceability and integrity.

5. **Verifiable Credentials and Technical Specifications:**

   - Debate on the approach for verifiable credentials and the need for implementation guidelines.
   - Discussion on interoperability, technical recommendations, and the balance between specificity and flexibility.
   - Agreement to draft business requirements to guide technical recommendations.

6. **Rendering Templates for Verifiable Credentials:**

   - **Ashley** presented on using rendering templates within credentials.
   - Discussion on embedding templates vs. linking to external sources, considering privacy, performance, and integrity.

7. **Next Steps and Actions:**
   - **Steve** to draft business requirements for verifiable credentials.
   - **Nis** and others to provide feedback and draft a pull request based on these requirements.
   - Further discussion on specific technical choices and their rationale.

**Action Items:**

- **Steve** to draft and post business requirements for verifiable credentials.
- **All relevant parties** to prepare and review pull requests related to DPP updates and verifiable credentials.
- Continue discussions on granularity of product claims and implementation guidelines.

**Conclusion:**
The meeting focused on refining the process for handling digital product passports and verifiable credentials, ensuring robust and interoperable solutions. The importance of clear business requirements to guide technical decisions was emphasized, and specific actions were assigned to move forward with these discussions.

## 2024-03-28 Meeting Summary

#### Attendees:

- **Stephen (Speaker 1)**
- **Kevin (Speaker 13)**
- **Nancy Norris (Speaker 5)**
- **Stephen Curran (Speaker 14)**
- **Jason (Speaker 7)**
- **Phil (Speaker 2)**
- **Virginia (Speaker 3)**
- **Christophe (Speaker 12)**
- **Michael (Speaker 10)**
- **Zach (Speaker 12)**
- **John (Speaker 9)**
- **Peter (Speaker 8)**

#### Key Points Discussed:

1. **Meeting Timing Adjustments:**

   - Adjusted to accommodate participants from different time zones, especially from Canada and the U.S.
   - Noted appreciation for the flexibility, despite it being late for some European participants.

2. **Welcome and Introductions:**

   - Introduction of new participants from North America.
   - Brief introductions by Nancy Norris and Stephen Curran highlighting their roles and work on verifiable credentials.

3. **Recording and Standards Development:**

   - Meeting is being recorded.
   - Emphasis on the focus on standards development rather than commercial products.
   - Contributions to the meeting are considered as contributions to the United Nations Intellectual Property Library.

4. **Digital Product Passport (DPP):**

   - Discussion on the importance of focusing on the DPP due to upcoming pilots in Australia and the EU.
   - Emphasis on business attention needed for the DPP structure.

5. **Claims and Evidence:**

   - Discussion on how to handle claims at the SKU, batch, and facility levels.
   - Recognition of the need to differentiate between product-level and batch-level claims.
   - Debate on the inclusion of benchmark values and references in the claims.
     - Some participants argued for the inclusion to provide context and comparability.
     - Others suggested it could be out of scope and should be handled by third-party verifiers.

6. **Granularity of Claims and Evidence:**

   - Addressed the challenge of reconciling claims at the shipment level with evidence at the facility level.
   - Discussed the potential for greenwashing if facility-level evidence is used to support product-level claims without proper verification.

7. **Product vs. Batch Passports:**

   - Consideration of whether to maintain separate passports for products and batches.
   - Discussed the possibility of inheriting claims from product to batch levels.
   - Agreed on the need for optional structures to support different use cases.

8. **Vocabulary and Ontology:**

   - Suggested a need for rigorous definition and management of the taxonomy and ontology of claims.
   - Potential overlap between the data model and the vocabulary of sustainability claims.

9. **Next Steps:**
   - Stephen to update the ticket with the consensus from the discussion.
   - Further review and testing of the data model with real use cases to ensure its implementability.

#### Action Items:

- Stephen to update the data model and ticket based on the discussion.
- Participants to review the updated model and provide feedback.
- Plan to test the model with sample certificates and real-world scenarios.

#### Closing:

- Meeting concluded with a reminder to stick to time limits for the benefit of all participants.

Please let me know if there are any specific details or additional information you would like to include in the summary.

## 2024-03-15 Meeting Summary

**Participants:**

- Steve
- Phil
- Nis
- Other unnamed speakers

**Key Points Discussed:**

1. **Policy Document Submission:**

   - The policy document was successfully submitted to the Secretariat and forwarded to the Bureau.
   - Approval from Bureau members is in progress, with public release anticipated soon.

2. **Meeting Frequency:**

   - Discussion on whether to hold meetings weekly or fortnightly.
   - Consensus leaned towards weekly half-hour meetings to ensure consistent progress and accountability.

3. **Tech Specifications and PRs:**

   - Focus to shift to tech specifications following the policy document submission.
   - Nis discussed several pull requests (PRs) for practice and refinement.
   - Agreed on a structured approach to reviewing and merging PRs.

4. **GS1 Standards and UNTP:**

   - Debate on the inclusion of GS1 standards and the relationship with UNTP.
   - Decision to potentially host information on GS1’s own page and link it from the UNTP site.

5. **Editing and Contributing via GitHub:**

   - Demonstration on how to edit pages, create issues, and make pull requests on GitHub.
   - Emphasis on using the "Edit this page" feature for ease of contribution.

6. **Action Items:**

   - Participants to self-assign tickets on GitHub and contribute to issues and pull requests.
   - Continuous monitoring and support via Slack for any technical issues.

7. **Miscellaneous:**
   - Acknowledgment of contributions to the policy document.
   - Future meetings to follow a structured process focusing on PRs and issues.

**Next Steps:**

- Weekly meetings to continue with a focus on technical specifications.
- Participants to actively engage in GitHub for issue tracking and pull requests.
- Continued collaboration and support to ensure progress on project goals.

## 2024-02-29 Meeting Summary

**Date:** February 29, 2024

**Participants:**

- Speaker 1 (Steve)
- Speaker 2 (Virginia)
- Speaker 3 (Christophe)
- Speaker 4 (Nes)
- Speaker 5 (Brett)
- Speaker 6 (Jerry)
- Speaker 7 (Rakesh)
- Speaker 8 (Peter)
- Speaker 9 (Unnamed participants)

---

**Key Points Discussed:**

1. **Introduction and Updates:**

   - Steve (Speaker 1) is still in Europe and provided an update on his encounters in Europe, including attending the GS1 Global Forum and OECD Textile and Leather Due Diligence Forum. He emphasized the alignment of GS1’s initiatives with the group’s goals and the opportunities for collaboration.

2. **European Meetings:**

   - GS1 Global Forum: Discussed their customers' challenges and the potential for cooperation in the use of resolvable identifiers and digital product passports.
   - OECD Forum: Major brands like Adidas are struggling with due diligence requirements and need a standard to push through their supply chain.
   - Surpass Program: EU’s initiative for pilot projects in various sectors, which is seen as complementary to UNDP.
   - DG Grow: European Commission's interest in complementary end-to-end pilots.

3. **Feedback on Europe Meetings:**

   - The feedback received from meetings in Europe was generally positive, indicating a good alignment with the group's objectives and a strong appetite for collaboration on digital product passports and related initiatives.

4. **Discussion on UNDP and EU DPP:**

   - Virginia highlighted the need to base the cross-border environmental passport on UNDP and mentioned that UNEP is interested in cooperating but prefers to base their work on UNDP.

5. **Recommendations Structure:**

   - The group discussed the structure of the recommendations in their document, deciding on having recommendations after the challenges section, aligning with standard UN document structures.
   - Emphasized the importance of making digital product passports resolvable and verifiable and the role of identifier schemes.

6. **Challenges Section:**

   - Agreement to shorten the challenges section to make the document more readable and concise, aiming for about two pages.

7. **Next Steps:**
   - Steve will rework Section 1 based on the feedback, shorten the challenges, and send out the updated version by Monday for final review before submission to the Secretariat by the end of the week.

**Action Items:**

- Steve to revise Section 1 and shorten the challenges section.
- Send the revised document to the team by Monday.
- Team to review and provide feedback before the next meeting on Thursday.
- Finalize the document for submission by Friday.

**Meeting Adjourned:**

- Meeting concluded with a plan to reconvene on Thursday for final review.

---

This summary captures the key points and actions from the meeting, ensuring that all participants are aligned on the next steps and responsibilities.

## 2024-02-15 Meeting Summary

**Participants:**

- Speaker 1 (Chair)
- Speaker 2 (Virginia)
- Speaker 3 (Gerhard)
- Speaker 4 (Rakesh)
- Speaker 5 (Stefano)
- Speaker 6
- Speaker 7 (Joe)
- Speaker 8
- Speaker 9
- Speaker 10

**Agenda:**

1. Review and focus on the policy document draft.
2. Discuss feedback and make necessary adjustments.
3. Prepare for final iteration of sections before the public review.

**Key Points Discussed:**

1. **Policy Document Review:**

   - The meeting primarily focused on the policy document draft instead of GitHub issues.
   - The urgency to finalize REC 49 for the UN plenary in July was emphasized. The document needs to complete a two-month public review starting early March.

2. **Feedback and Structural Changes:**

   - Feedback from UN Secretariat suggested separating recommendations to member states (Section 1) from those to industry actors (Section 2).
   - Virginia's recent edits include:
     - An introduction explaining the purpose of Recommendation 49.
     - A section detailing the UNTP and its challenges in a table format.
     - Clarification on roles and opportunities in Section 2.

3. **Content Adjustments:**

   - Speaker 2 pointed out the need for an explanatory section on UNTP.
   - Speaker 1 shared insights from discussions with WTO member state delegates, highlighting the importance of simplifying the document’s language and message.
   - Stakeholder mapping and visual aids were suggested to clarify the focus on different audiences.

4. **Technical and Terminological Clarifications:**

   - Debate on the term "protocol" concluded with keeping the term but clarifying its meaning in the context of the document.
   - Replace "ESG" with "sustainability" to avoid political connotations and ensure clarity.

5. **Strategic Alignment:**

   - Rakesh emphasized aligning the document with existing multilateral frameworks (G20, OECD) and strategic objectives of countries.
   - Highlighting benefits such as harmonization and reduction of industry burden to appeal to policymakers.

6. **Final Edits and Testing:**
   - The need for another draft incorporating feedback was agreed upon.
   - Testing the revised document on external policymakers for readability and impact before the final iteration.

**Action Items:**

- **Virginia** to integrate feedback and refine the document.
- **Rakesh** to draft paragraphs on aligning with global initiatives and specifying relevant government departments.
- **Joe and Gerhard** to provide additional input on technical simplifications and stakeholder visual aids.
- **Speaker 1** to circulate an updated draft by Monday for final review and feedback.

**Closing Remarks:**

- Appreciation for the hard work and contributions from all team members.
- Next steps include refining the document based on today’s discussions and preparing for final testing with policymakers.

**Next Meeting:**

- Date to be determined, expected early next week to review the updated document.

## 2024-02-01 Meeting Summary

**Date:** January 25, 2024

**Participants:**

- Speaker 1 (Steve)
- Virginia
- Peter
- John
- Zach
- Olivia
- Ash
- Kevin
- Nancy
- Brett
- Others

**Agenda:**

1. Welcome and Introduction
2. Review of Document and GitHub Issues
3. Discussion on Sustainability Pledge and Challenges
4. Collaboration and Coordination in Value Chains
5. Summary of Business Drivers and Technical Challenges
6. Overview of the UNTP Protocol and Design Principles
7. Stakeholder-Specific Challenges and Recommendations
8. Next Steps and Action Items

**Key Points:**

1. **Welcome and Introduction:**

   - Steve acknowledged participants and outlined the meeting's agenda.
   - Mention of ongoing work on the document and the need to populate it further.

2. **Review of Document and GitHub Issues:**

   - A walkthrough of the newly created website for technical information.
   - Encouragement to read specific sections of the website for better alignment with the policy document.
   - Discussion on the inclusion of contributing experts in the document.

3. **Discussion on Sustainability Pledge and Challenges:**

   - Debate on the name for the sustainability pledge to avoid confusion with the existing textiles and garments pledge.
   - Importance of making a pledge that is meaningful and not industry-specific.

4. **Collaboration and Coordination in Value Chains:**

   - Emphasis on the need for tier-one collaboration without imposing technical solutions.
   - Highlighting the importance of individual actor implementation for global traceability.

5. **Summary of Business Drivers and Technical Challenges:**

   - Simplification of business drivers to focus on fear of non-compliance and opportunities for market access and price uplift.
   - Technical challenges to be detailed in a section correlating with business challenges and confidentiality concerns.

6. **Overview of the UNTP Protocol and Design Principles:**

   - Discussion on the necessity of a new protocol and why existing solutions may not suffice.
   - Suggestion to keep technical diagrams and detailed protocol descriptions on the website, not in the policy document.

7. **Stakeholder-Specific Challenges and Recommendations:**

   - Identification of challenges specific to government, industry, and consumers.
   - Importance of highlighting regulatory challenges and benefits for governments to ensure relevance and adoption.

8. **Next Steps and Action Items:**
   - Steve and Virginia to act as master editors to streamline the document.
   - Focus on creating a draft ready for review and public consultation.
   - Continued contributions to the technical website for long-term improvements.

**Action Items:**

- Steve and Virginia to edit and refine the document based on the discussion.
- Participants to review and comment on the GitHub issues and website content.
- Schedule next meeting for further review and finalization of the draft document.

**Closing Remarks:**

- Agreement on a two-week period for Steve and Virginia to finalize the draft.
- Next meeting to review the draft and gather final feedback before public consultation.

## 2024-01-25 Meeting Summary

**Date:** January 25, 2024

**Participants:**

- Speaker 1 (Steve)
- Virginia
- Peter
- John
- Zach
- Olivia
- Ash
- Kevin
- Nancy
- Brett
- Others

**Agenda:**

1. Welcome and Introduction
2. Review of Document and GitHub Issues
3. Discussion on Sustainability Pledge and Challenges
4. Collaboration and Coordination in Value Chains
5. Summary of Business Drivers and Technical Challenges
6. Overview of the UNTP Protocol and Design Principles
7. Stakeholder-Specific Challenges and Recommendations
8. Next Steps and Action Items

**Key Points:**

1. **Welcome and Introduction:**

   - Steve acknowledged participants and outlined the meeting's agenda.
   - Mention of ongoing work on the document and the need to populate it further.

2. **Review of Document and GitHub Issues:**

   - A walkthrough of the newly created website for technical information.
   - Encouragement to read specific sections of the website for better alignment with the policy document.
   - Discussion on the inclusion of contributing experts in the document.

3. **Discussion on Sustainability Pledge and Challenges:**

   - Debate on the name for the sustainability pledge to avoid confusion with the existing textiles and garments pledge.
   - Importance of making a pledge that is meaningful and not industry-specific.

4. **Collaboration and Coordination in Value Chains:**

   - Emphasis on the need for tier-one collaboration without imposing technical solutions.
   - Highlighting the importance of individual actor implementation for global traceability.

5. **Summary of Business Drivers and Technical Challenges:**

   - Simplification of business drivers to focus on fear of non-compliance and opportunities for market access and price uplift.
   - Technical challenges to be detailed in a section correlating with business challenges and confidentiality concerns.

6. **Overview of the UNTP Protocol and Design Principles:**

   - Discussion on the necessity of a new protocol and why existing solutions may not suffice.
   - Suggestion to keep technical diagrams and detailed protocol descriptions on the website, not in the policy document.

7. **Stakeholder-Specific Challenges and Recommendations:**

   - Identification of challenges specific to government, industry, and consumers.
   - Importance of highlighting regulatory challenges and benefits for governments to ensure relevance and adoption.

8. **Next Steps and Action Items:**
   - Steve and Virginia to act as master editors to streamline the document.
   - Focus on creating a draft ready for review and public consultation.
   - Continued contributions to the technical website for long-term improvements.

**Action Items:**

- Steve and Virginia to edit and refine the document based on the discussion.
- Participants to review and comment on the GitHub issues and website content.
- Schedule next meeting for further review and finalization of the draft document.

**Closing Remarks:**

- Agreement on a two-week period for Steve and Virginia to finalize the draft.
- Next meeting to review the draft and gather final feedback before public consultation.

## 2024-01-18 Meeting Summary

**Date:** January 18, 2024

**Participants:**

- Speaker 1 (Steve)
- Virginia
- Nis
- Nancy
- Benjamin
- Dr. Wang
- Gregory
- Others

**Agenda:**

1. Welcome and Introduction
2. Review of GitHub Issues and Editorial Process
3. Verifier Experience and Trust Graph
4. Schema Context and Verifiable Documents
5. Vocabulary and Standards Mapping
6. Versioning and Implementation Profiles
7. Extension Methodology for UNTP
8. Next Steps and Action Items

**Key Points:**

1. **Welcome and Introduction:**

   - Participants greeted each other and the meeting was recorded.
   - Steve reminded everyone about the fortnightly meeting schedule alternating between technical and policy-focused sessions.

2. **Review of GitHub Issues and Editorial Process:**

   - The editorial process involves raising GitHub issues, discussing them, reaching conclusions, and submitting pull requests for review.
   - Nis has volunteered as an editor with maintained rights on the repository.

3. **Verifier Experience and Trust Graph:**

   - Nis demonstrated a verifier experience showcasing the traversal and validation of a trust graph.
   - Discussion on how to ensure the contextual validity of linked credentials and automating due diligence for various sectors.

4. **Schema Context and Verifiable Documents:**

   - Discussion on the need to align schema context for digital product passports and verifiable credentials.
   - Emphasis on pointing to existing interoperability profiles rather than reinventing them.

5. **Vocabulary and Standards Mapping:**

   - Steve proposed creating a sustainability vocabulary to categorize ESG claims in digital product passports.
   - Dr. Wang and Gregory highlighted existing work and offered contributions to the vocabulary design.

6. **Versioning and Implementation Profiles:**

   - Discussion on how to handle versioning of specifications and implementation profiles.
   - Proposal to group specifications into core and trust-related categories with implementation profiles reflecting different levels of conformity.

7. **Extension Methodology for UNTP:**

   - The principle of defining a simple common core for UNTP and allowing industry-specific or geographic extensions.
   - Need for a rule set to ensure non-breaking extensions.

8. **Next Steps and Action Items:**
   - Participants to use GitHub tickets for further discussions and provide feedback.
   - Steve to initiate discussions on specific issues and encourage the development of consensus on key points.

**Action Items:**

- Participants to review and comment on GitHub issues.
- Steve to publish a draft sustainability vocabulary.
- Nis to work on automated policy execution and verifier experiences.
- Follow-up discussions on extension methodologies and implementation profiles.

**Closing Remarks:**

- Agreement to use GitHub issues as discussion forums to reach consensus and develop content.
- Next meeting to focus on merging pull requests and further refining the specifications.

## 2024-01-11 Meeting Summary

**Date:** January 11, 2024

**Participants:**

- Steve
- Christian
- Peter
- Zach
- Kay
- Benjamin
- Nis
- Maria Teresa
- Kevin
- Brett
- Anil John
- Others

**Agenda:**

1. Welcome and Introduction
2. Review of Registration and Participation
3. Overview of GitHub Repository and Structure
4. Discussion on Key Sections and Specifications
5. Splitting into Technical and Policy Teams
6. Next Steps and Action Items

**Key Points:**

1. **Welcome and Introduction:**

   - Participants greeted each other and wished a Happy New Year.
   - The meeting was recorded for future reference.

2. **Review of Registration and Participation:**

   - Steve reviewed the list of participants who had registered and noted the status of their registration.
   - Participants were encouraged to complete their registration if not already done.

3. **Overview of GitHub Repository and Structure:**

   - Steve shared the structure of the GitHub repository for the technical specifications of Recommendation 49.
   - The repository includes sections on architecture, digital product passports, conformity credentials, traceability events, identifiers, vocabularies, verifiable credentials, data carriers, trust anchors, trust graphs, confidentiality, anti-counterfeiting, mass balance, ESG rules, GS1 usage, business cases, tools and support, extensions register, and implementation register.

4. **Discussion on Key Sections and Specifications:**

   - Emphasis on the need to align digital product passports with existing standards, including those from the EU.
   - Discussion on the importance of identifiers and the gap between current identifier systems and the needs of a digital trust architecture.
   - The role of vocabularies in ensuring consistent categorization and reporting of ESG criteria.
   - The significance of verifiable credentials and leveraging existing profiles from other initiatives.
   - The need for clear governance and best practices for confidentiality and anti-counterfeiting.

5. **Splitting into Technical and Policy Teams:**

   - Proposal to split the group into two teams: one focused on the technical specifications in the GitHub repository and the other on the policy recommendation document.
   - Meetings will be held weekly, alternating between technical and policy discussions.

6. **Next Steps and Action Items:**
   - Participants to review the GitHub repository and provide feedback via tickets.
   - Steve to send out invitations for separate technical and policy meetings.
   - Follow-up on registration for those who have not yet completed the process.

**Action Items:**

- Steve to set up a spreadsheet for tracking participant roles and contributions.
- Participants to raise issues and provide feedback on the GitHub repository.
- Schedule and conduct separate meetings for technical and policy teams.

**Closing Remarks:**

- Recognition of the interest and engagement from various stakeholders, including presentations to the OECD, GS1 Global Forum, and the European Commission.
- Encouragement for continued collaboration and contributions to ensure the success of Recommendation 49.

## 2023-12-14 Meeting Summary

**Date:** December 14, 2023

**Participants:**

- Steve
- Virginia Cram Martos
- Rakesh
- Franziska
- Mathieu
- Charles Arden-Clark
- Others

**Agenda:**

1. Introductions
2. Overview and Communication of Recommendation 49
3. Revised Document Structure
4. Call for Contributors and Next Steps

**Key Points:**

1. **Introductions:**

   - New participants, including Virginia, Rakesh, Franziska, Mathieu, and Charles, introduced themselves and shared their backgrounds and expertise.

2. **Overview and Communication:**

   - Steve shared a video explaining Recommendation 49 and its goals, emphasizing anti-greenwashing through supply chain transparency.
   - Participants were encouraged to watch and share the video for better understanding and feedback.

3. **Revised Document Structure:**

   - The document is divided into three sections: a high-level executive summary, detailed guidelines for implementation, and an annex for additional information.
   - The executive summary will cover the introduction, scope, target audience, purpose and benefits, challenges, recommendations, and an opportunity for implementers to make a pledge.
   - The guidelines section will detail business drivers, design principles, technical challenges, and the actual protocol, including costs, incentives, and implementation guidance.
   - A GitHub repository has been created for detailed technical information and specifications to support the policy document.

4. **Call for Contributors:**

   - Participants were invited to volunteer for writing different sections of the document.
   - Emphasis on involving both business-oriented and technical experts to ensure the document is comprehensive and implementable.
   - A spreadsheet will be set up to track potential stakeholders and contributors, distinguishing between observers and active contributors.

5. **Next Steps:**
   - Spreadsheet to track participant roles and contributions will be created and shared.
   - UNECE to confirm the revised structure of the document.
   - Separate technical meetings to be scheduled after Christmas to focus on detailed content development for the GitHub repository.

**Action Items:**

- Steve to create and share a spreadsheet for tracking participants and their roles.
- UNECE to review and confirm the revised document structure.
- Participants to indicate their interest in contributing to specific sections.
- Technical meetings to be scheduled for post-Christmas to progress GitHub content.

**Closing Remarks:**

- Agreement to skip the meeting scheduled for December 28 due to the holiday season.
- Next group meeting to be held in a month, with parallel technical meetings starting after Christmas.

## 2023-11-30 Meeting Summary

**Date:** November 30, 2023

**Participants:**

- Steve
- Brett
- Kevin
- Benjamin
- Corey
- Felix
- Xinyang
- Nis
- Maria Teresa
- Stefano

**Agenda:**

1. Communication Strategies and Updates
2. Refactoring Recommendation 49 Document

**Key Points:**

1. **Introduction and General Updates:**

   - Steve welcomed participants and highlighted the importance of communication.
   - A project in Australia on agricultural traceability has successfully demonstrated the concepts in Recommendation 49, showing quick vendor adoption and implementation.

2. **Communication Strategies:**

   - Emphasis on the importance of effectively communicating the project to various stakeholders.
   - Discussion on creating sector-specific versions of the communication video (e.g., for critical raw materials, textiles).
   - Participants encouraged to share the existing video and provide feedback.
   - Maria Teresa agreed to post the video on official UN channels once updates are made.

3. **Feedback on Communication:**

   - Participants agreed on the need for various media to reach different audiences.
   - Suggestions included creating a range of materials from short soundbites to longer, detailed videos.
   - Brett and others emphasized focusing on the flexibility and scalability of the protocol.

4. **Refactoring Recommendation 49 Document:**

   - Discussion on aligning the structure of Recommendation 49 with previous UN recommendations.
   - Agreement on including sections like scope, purpose, benefits, and a high-level summary.
   - Inclusion of a cost-benefit analysis and discussion on inclusivity (small businesses, developing economies).
   - Emphasis on providing a flexible yet implementable framework that can be adapted for different sectors.

5. **Implementation Guidance:**

   - Importance of providing clear, implementable guidelines and schemas.
   - Agreement on using projects like critical raw materials and agriculture as examples.
   - Discussion on maintaining flexibility while ensuring interoperability and testability.

6. **Next Steps:**
   - Steve to restructure the document based on the discussed framework.
   - Participants to review and provide feedback on the restructured document.
   - Plan to engage with policy makers for informal reviews before formal public review.

**Action Items:**

- Steve to complete the restructuring of the Recommendation 49 document within the next week.
- Participants to share the communication video and provide feedback.
- Maria Teresa to post the updated video on UN channels.
- Team to engage with policy makers for informal reviews of the draft document before the end of January.

**Closing Remarks:**

- Agreement on the next meeting to review the restructured document and continue content development.
- Maria Teresa emphasized the importance of involving policy makers early in the review process to ensure the document meets their needs and gains their support.

---

## Steering Group

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

## Terms of Reference

The establishment of the UNTP Steering Group marks the completion of the transition of UNTP’s technical work into distinct UNTP Working Groups. Its purpose is to guide, coordinate and support the work of the technical UNTP working groups. This is a closed group composed of the UN/CEFACT Bureau Chair, the UNTP Project Lead, a UN/CEFACT Secretariat representative, and the leads of the technical UNTP Working Groups. Additional UN/CEFACT experts may be invited on an ad hoc basis if their technical expertise is required.

## Meetings

Meetings are run by the UNECE secretariat and generally held fortnightly by invitation. The meeting participants include the UNECE secretariat, the UN/CEFACT bureau chair, the UNTP project lead, the working group leads, the extension group chair, and any other particpants by invitation.

## Previous Meetings

Meeting minutes are public and are published below (most recent first)

| Meeting | Summary |
| ------- | ------- |
|2025-08-28|The inaugural meeting of the UNTP Steering Group brought together the leads of the technical UNTP Working Groups to share updates, discuss inter-group coordination, and provide mutual guidance. Key discussion points included the mandate and Terms of Reference of the Steering Group, updates on recent activities from each working group, the framework for developing sector-specific extensions to the core UNTP, and the timeline for the development, consultation, and approval of future versions of the core UNTP.|

---

## Supply Chain Group

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

## Terms of Reference

### Objectives
* Maintain the following UNTP specification pages, learning from the experiences of real-world pilots and implementations.
  * Digital Product Passports (DPP)
  * Digital Facility Records (DFR)
  * Digital Traceability Events (DTE)
* Maintain the following UNTP Best practice guidance pages, learning from the experiences of real-world pilots and implementations.
  * Transparency Graphs
  * Chain of Custody
* Address all issues in the issues log related to the supply chain working group in a timely manner to support the UNTP overall release timeline
  * Version 0.7.0 (due early March 2026)
  * Version 1.0.0 (due early July after public review)
* Seek alignment wherever possible with relevant international standards and key government regulations.
* Communicate lessons learnt (+ve & -ve) and implementation tips to help lower UNTP implementation effort 
* Develop simple approaches to managing overlapping and parallel data disclosures using the UNTP 

### Purpose
* By maintaining high quality technical specifications, informed from real-world pilots and implementations, we will increase trust and confidence in the UNTP specification.
* Through applying the UNTP to real world and relevant disclosure schemes, we will be able to validate the efficacy of the UNTP solution across different types of supply chains. 
* Reducing the effort to implement the UNTP will support faster adoption, faster learning cycles and faster improvement of the protocol.  This in turn should help accelerate real world adoption. 
* By providing approaches to managing overlapping disclosure schemes we can demonstrate the strength of the UNTP as a unifying standard, as opposed to niche focused on one disclosure scheme 
* By demonstrating alignment with relevant standards and regulations (eg the EU DPP), we will reduce cost and risk for implementers who will be able to confidently build on UNTP for global markets. 
   

### Example of Supply Chain Questions being addressed by this working group
- Help address how confidentiality changes as data moves and transforms along the supply chain
- Consider how UNTP works when there are breaks in supply chain digitisation upstream, which is key to phased deployment of UNTP
- Help address how bulk commodity mass balancing (in it's different forms) interacts with UNTP along a supply chain 
- How to facilitate mapping and mutual recognition between disclosure schemes with similar intent so that audot fatigue can be reduced.

## Mailing List

A group mailing list is maintained and can be used by any list member to post messages to the group. The list also maintains an archive of all messages sent to the group.

- To [join the mailing list](https://gaggle.email/join/untp-supplychain@gaggle.email) - your request will be reviewed by a list administrator.

## Meetings

Group meetings are held Fortnightly in two timezones.

* The **[calendar link](https://www.addevent.com/event/dk0h31lws77v)** - every second tuesday at 2:00 pm CET, 8am ET, 10pm AEST
* The **[zoom link]( https://us06web.zoom.us/j/85476253850?pwd=xBVZajLN5QkV2bhEhklNHkEtZle2Jv.1)** for both meetings is the same.

## Previous Meeting Minutes

Click on the date to see the more detailed meeting summary. 

|Date|Summary|
|--|--|
|[23 Jun 2026](#23-06-2026-meeting)|The Supply Chain Working Group reviewed public feedback issues for UNTP 0.7, now in public review with 42 issues identified. Golda presented issue 66 on third-party identity resolvers to make community complaints and worker voice platform information discoverable alongside facility credentials. Albert questioned whether the "make, move, modify" traceability events are sufficient versus the established EPCIS standard, with Nick advocating a pragmatic "implement and see how it's used" approach. The group discussed supply chain transparency under geopolitical and commercial-sensitivity constraints, the role of trusted auditors in verifying undisclosed data, and a proposed new corporate digital record credential type.|
|[26 May 2026](#26-05-2026-meeting)|The Supply Chain Working Group focused on processing public review comments for UNTP 0.7 via UNICC GitLab, where feedback is converted into structured issues for discussion and resolution. Tobias presented feedback items on enhancing data security requirements (privacy, data governance, asymmetric power dynamics), illicit materials detection in mass balance, and DPP terminology differences between UNTP and EU frameworks. The group also discussed country of origin versus country of production terminology, potential multilingual support, and encouraged participants to register for UNICC GitLab and contribute to the public review discussions.|
|[28 Apr 2026 - EU](#28-04-2026-meeting-eu-timezone)|The meeting focused on the upcoming public review of UNTP 0.7, recent changes including a new supply chain resilience video, the "implementation tree" governance concept, alignment between UNTP and EU Digital Product Passports for textiles and batch-level requirements, seafood traceability digitization gaps, and OpenSupply Hub's registration as a UNTP identity resolver.|
|[31 Mar 2026 - EU](#31-03-2026-meeting-eu-timezone)|The meeting focused on the upcoming public review of UNTP 0.7, covering updates to specification pages, target audience for review (large producers, manufacturers, conformity scheme owners, software providers), SME adoption considerations, GS1/UNTP compatibility, GDST alignment, and the timeline to UNTP 1.0 release around July 2026.|
|[31 Mar 2026 - US](#31-03-2026-meeting-us-timezone)|The meeting covered the transition of UNTP 0.7 from technical development to public review and sectoral implementation, a new Argentina textile pilot announced by Mariano, proposed governance simplification for the post-1.0 phase, and the move from top-down specification to bottom-up sectoral collaboration.|
|[17 Mar 2026 - EU](#17-03-2026-meeting-eu-timezone)|The meeting reviewed UNTP 0.7 specifications before public review, covering vocabulary taxonomies, implementation guidance, architectural improvements, and practical adoption pathways for manufacturers and SMEs including the Fashion Producer Collective.|
|[17 Mar 2026 - US](#17-03-2026-meeting-us-timezone)|The meeting covered the 0.7 release approaching member state review, including core vocabulary and taxonomy updates, reference criteria optionality in claims, battery passport mapping, and the vision of continuous machine auditing of sustainability claims at scale.|
|[3 Mar 2026 - EU](#03-03-2026-meeting-eu-timezone)|The meeting focused on finalizing the UNTP 0.7 release candidate, covering data model consolidation, traceability event terminology debates (make/move/maintain), mass balance verification approaches, and conformity credential scheme endorsements with a proposed trust register model.|
|[3 Mar 2026 - US](#03-03-2026-meeting-us-timezone)|The meeting reviewed data model consolidation into a unified namespace, traceability event alignment with GS1 EPCIS, optional party role fields, transport emissions handling, and battery passport extension methodology including dynamic data via separate verifiable credentials.|
|17 Feb 2026 - EU| The meeting focused on simplifying UNTP party roles, improving packaging and facility reporting models, and replacing fixed performance measures with a flexible but controlled vocabulary of metrics to support more consistent, machine-readable product passport and sustainability reporting.|
|[17 Feb 2026 - US](#17-02-2026-meeting-us-timezone)|The meeting reviewed updates to the UNTP data model covering party roles, facility reporting, assessment periods, measurement tolerances, and the shift to controlled-vocabulary performance claims, with actions to align the model with regulatory requirements and clarify implementation details. |
|[3 Feb 2026 - EU](#03-01-2026-meeting-eu-timezone) |The Supply Chain Working Group reviewed progress toward UNTP v0.7, focusing on mass balance, product passports, and digital credentials for sustainability and carbon data, while agreeing on governance-driven issue closure and next steps to improve transparency, traceability, and SME-friendly implementation. |
|[3 Feb 2026 - US](#03-01-2026-meeting-us-timezone) |The working group reviewed administrative updates and refined the UNTP specification, focusing on how claims, conformity credentials, and product passports interrelate—particularly for sustainability and carbon data—while agreeing next steps to clarify link semantics, close pending issues, and prepare for the v0.7 release. |
|[20 Jan 2026 - EU](#20-01-2026-meeting-eu-timezone)|The UNTP Supply Chain Working Group reconvened under Steven Capell’s leadership to advance an industry-neutral, interoperable traceability standard, agree on priorities to resolve open technical issues, and progress toward releasing UNTP v0.7 within six weeks to enable broader consultation and early adoption|
|[20 Jan 2026 - US](#20-01-2026-meeting-us-timezone) |The UNTP Supply Chain Working Group reviewed progress toward UNTP as a digital interoperability standard, confirmed targets for v0.7 by mid-March and v1.0 by June, and agreed on next steps to resolve open GitLab issues and advance JSON schema and linked-data integration for interoperable implementations.|

---

## 23-06-2026 Meeting

### Quick recap

This meeting focused on reviewing public feedback issues for the UNTP (UN Digital Product Passport) standard, which is currently in its public review phase with 42 issues identified. Golda presented issue 66 regarding the need for third-party identity resolvers to allow community complaints and worker voice platform information to be discoverable alongside facility credentials, though concerns were raised about facilities' willingness to adopt such a system. Albert raised concerns about the digital traceability events framework, questioning whether the proposed "make, move, modify" events are sufficient for modeling supply chains compared to using the established EPCIS standard, while Nick suggested adopting a more pragmatic approach by implementing what works and seeing how it's actually used. The group discussed the challenges of supply chain transparency, particularly in light of geopolitical restrictions and commercial sensitivity, with Steven explaining how auditors and trusted third parties would play a crucial role in verifying information even when facilities don't share data directly. The conversation ended with discussion of a proposed new credential type - a corporate digital record - which would contain detailed information about companies including subsidiaries and performance metrics, with mixed support from participants about its addition to the standard.

---

### Next steps

**Albert**

* Document specific gaps or modeling issues in the "make, move, modify" event framework and propose improvements to ensure it can adequately describe supply chain reality.

**Golda**

* Research and propose a governance process for adding third-party/community resolvers to the UNTP list, including consultation with 60 Decibels and other respected organizations, and provide updated proposal to Steven.
* Follow up with 60 Decibels to explore their interest and possible role as a data source or governance participant for third-party/community resolvers.

**Steven**

* Review and comment on all public review issues raised on GitLab, ensuring each has a documented discussion and consensus before closure.
* Consider the proposal for a new "corporate record" credential type, review the feedback from the group, and determine next steps for its potential inclusion in UNTP.

**Collaboration**

* Golda and İrem: Discuss offline the technical and governance implications of allowing third-party claims about facilities, considering Open Supply Hub's experience, and report back on potential integration or separation of such claims from digital facility records.
* All participants: Create a GitLab account and provide comments or feedback on public review issues to support evidence-based consensus and closure of issues.

---

### Summary

#### Chinese Regulation Impact Discussion

Steven and Adrienna discussed Steven's recent travels, including meetings in Brussels and Beijing. They briefly touched on the topic of Chinese decree A34 and its potential impact on EU DPP regulation, with Steven noting that while EU DPP statements might be allowed, proving them under Chinese law would likely be prohibited due to national security concerns. The meeting was still in progress with additional attendees expected, including Albert and potentially Chris Papp.

---

#### Third-Party Identity Resolver Framework

The team discussed issues raised during the public review phase, with 42 issues identified from comments received. Golda presented issue 66, focusing on the need for a third-party identity resolver framework to allow communities and stakeholders to challenge compliance claims with specific counterclaims or third-party assertions, particularly regarding forced labor and mining conditions in regions like the DRC. Golda emphasized the importance of creating a mechanism for addressing local concerns about compliance statements that are currently difficult to verify or dispute.

---

#### Third-Party Auditor Identity Resolver

Golda proposed creating an identity resolver for third-party auditors to allow community complaints and information to be discoverable even when not authorized by the identifier owner. Steven clarified the concept, explaining how this would work alongside the existing UNTP architecture by allowing worker voice platforms to make statements about facilities or products without controlling the identifiers. The discussion focused on the need for a separate register that could use the same identifiers as signposts, though the specific mechanism for finding these registers was left open for further discussion.

---

#### Non-GS1 Resolver Implementation Discussion

Steven and Golda discussed the need for a non-GS1 resolver to handle worker voice platforms, which would allow downstream buyers to verify information against community perspectives during due diligence. Golda confirmed this would need to be added as a new category of resolver to the UNTP list, though questions remain about the governance process for approval and how to distinguish trustworthy resolvers from untrustworthy ones. Steven mentioned a potential IEEE standard for progressive trust in identity creation that could provide a framework for this approach.

---

#### Digital Resolver and Identifier Proposal

Golda agreed to take on homework to develop a proposal regarding resolvers and identifiers, with Steven suggesting the creation of a list of resolvers for registration. Golda proposed reaching out to 60 Decibels for potential collaboration on this issue. İrem raised concerns about facilities' consent regarding third-party credentials in digital facility records, to which Golda responded that the information could serve as an independent verification tool rather than being directly included in digital passports.

---

#### Open Supply Hub Facility Register

Steven discussed the potential for Open Supply Hub to serve as a register of facilities, including information from worker voice platforms, though he noted concerns about facility relationships and governance. İrem confirmed that Open Supply Lab already allows civil society organizations to share facility information publicly. The group agreed that İrem and Golda should discuss offline how Open Supply Hub could function as a data source for this initiative.

---

#### EPCIS vs UNTP Event Definitions

Albert discussed concerns about using EPCIS versus the make-move-modify events in UNTP work, questioning whether EPCIS might be sufficient without needing parallel event definitions. Steven acknowledged this as a strategic question and explained that early criticism about UNTP appearing too GS1-friendly led to the decision to allow both UNTP native events and EPCIS profiles as acceptable approaches.

---

#### EPCIS vs EPCAS Traceability Discussion

The team discussed using EPCIS versus EPCAS for traceability events, with Steven explaining that while EPCIS is built for GS1 identifiers, it could be abstracted to work with any identifier scheme. Nick suggested adopting EPCIS and seeing how it's actually used in practice, while Albert raised concerns about the complexity of EPCIS and questioned whether a parallel framework including make, move, and modify events would be necessary. The discussion highlighted that traceability events are crucial for linking products from source to downstream, particularly for verifying claims in product passports and facility records.

---

#### Supply Chain Transparency Challenges

The group discussed challenges in supply chain transparency, particularly around data sharing and verification of environmental claims. Steven highlighted that many supply chain actors are reluctant to share commercially sensitive information, and this reluctance is further constrained by laws like China's new regulations. The discussion centered on whether a trusted third party or auditor could serve as a bridge for verifying information when direct sharing between supply chain partners isn't possible. The participants agreed that while perfect transparency across the entire supply chain may not be achievable, a framework should be designed that allows for confidence in claims even when information is shared only with trusted auditors rather than directly with customers or other supply chain partners.

---

#### Auditor Trust Across Jurisdictions

Tara asked about addressing trust issues in auditing when auditors are located in different jurisdictions, particularly regarding Chinese entities. Steven suggested using algorithmic auditors with verifiable proof of execution as the most trustworthy and cost-effective solution, though he noted this would require high-integrity digital data from upstream sources. Nick clarified that while the group had discussed data quality assurance, they hadn't explicitly addressed auditor trust issues, and Steven indicated that while the Conformity Group considers auditor trustworthiness, UNDP currently doesn't specify how algorithmic assessments would work.

---

#### Corporate Record Credential Discussion

The team discussed adding a new corporate record credential type to UNTP, with mixed opinions. While Golda and others supported the idea, Nick and Adrienna expressed concerns about complexity and voluntary adoption. Steven noted that the request came from the Responsible Business Alliance on behalf of large corporations, and emphasized that UNTP remains a voluntary standard. The group also discussed the need for improved graph validation rules and credential verification processes. Steven requested participants to create GitLab accounts to provide feedback on public review issues to help reach consensus on proposed changes.

---

## 26-05-2026 Meeting

### Quick recap

The Supply Chain Working Group meeting focused on processing public review comments received for the UNTP specification. Steven explained the process for reviewing feedback items through UNICC GitLab, where comments are converted into structured issues for discussion and resolution. Tobias presented several feedback items he had submitted, including suggestions for enhancing data security requirements to address privacy, data governance, and asymmetric power dynamics in supply chains. He also raised concerns about mass balance calculations and the need to detect illicit materials in supply chains. The group discussed the Digital Product Passport (DPP) requirements and terminology differences between UNTP and EU regulatory frameworks. Additional topics covered included clarifying country of origin versus country of production terminology and the potential need for multilingual support in the specification. The conversation ended with encouragement for all participants to register for UNICC GitLab accounts and contribute to discussions on the public review issues.

---

### Next steps

**Steven**

* Ensure the registration link and instructions for UNICC GitLab and Slack are shared with all participants, and assist Rafael and others with accessing the correct Slack channels and tickets.
* Remove or merge duplicate feedback items as identified (e.g., mass balance comment in the wrong ticket), ensuring feedback is correctly categorized and addressed.
* Note and consider feedback on multilingual support, including the possible addition of a language code field in the data model, and invite further discussion in the relevant ticket/thread.
* Review and address the feedback regarding terminology ambiguity around "country of origin" and "country of production" to ensure clarity, possibly by updating terminology or providing explanatory notes.
* Encourage reporters of feedback from Canada, France, Netherlands, Germany, and others to join future calls and participate in GitLab discussions.
* Consider the feedback on "denomination of origin in Spain" and ensure it is noted for future discussion.

**Tobias Stäuble**

* Propose specific wording for new requirements on data privacy, data ownership, and data governance in the relevant ticket, and participate in GitLab discussion to reach consensus on the updated requirement.

**Collaboration**

* All ticket reporters (including Tobias Stäuble and others referenced in the transcript): Register for a UNICC GitLab account and participate in the ticket threads to discuss, elaborate, and help reach consensus on the feedback items they submitted.
* All working group members: Review and comment on public review tickets in GitLab to ensure each ticket has visible discussion and consensus before closure.
* All participants: Continue to monitor and contribute to the GitLab ticket discussions as new feedback and comments arise during the public review period.

---

### Summary

#### Public Review Comments Processing

The meeting focused on processing public review comments for version 0.7 of a technical specification, with approximately 20 comments received so far. Steven explained the public feedback process and how comments are converted into structured issues, which are available in a pinned chat on the Slack channel for the Supply Chain Working Group. The discussion included acknowledgment of both technical and business-focused feedback items that require review from different working groups.

---

#### Public Review Process Announcement

Steven announced the start of public review and reported that multiple feedback items have been received and converted into public tickets categorized by working groups. He explained that team members need to register on UNICC GitLab to comment on tickets and participate in the review process over the next few months. Steven expressed satisfaction with the quality of the feedback received, noting it was well-considered and detailed, and invited the group to discuss prioritization and categorization of the tickets.

---

#### GitLab Public Review Process

The meeting participants discussed the process for handling public review comments and tickets in GitLab. Steven explained that while the typical process would be to wait until the public review is complete before starting work on tickets, this is the first time using this approach at the UN, so they plan to have initial discussions about open tickets through regular meetings over the next period. Steven noted that unlike typical UN public reviews where everyone reviews a frozen version, they can maintain multiple live versions, allowing them to review and update comments in real-time and mark tickets as pending close.

---

#### UNTP Site Registration Issues

Rafael asked about registration issues on the UNTP site and Slack, specifically regarding access to governance categories and working group channels. Steven helped guide Rafael through the registration process and explained how to view and join public channels in Slack, including the working group supply chain channel. The discussion ended with Steven planning to send a note to the group about the registration process, and they prepared to review open issues before moving on to other topics.

---

#### Enhancing UNTP Data Governance Requirements

Tobias Stäuble and Kristian discussed enhancing the UNTP requirements to include broader data governance aspects beyond confidentiality, specifically focusing on privacy, data ownership, and addressing power dynamics in data sharing. They agreed that additional requirements should cover personal privacy rights, data sovereignty, and preventing unfair use of shared data. Steven requested that parties proposing ticket feedback include specific wording suggestions for the additional requirements in their tickets.

---

#### Illicit Materials Detection in Mass Balance

Tobias Stäuble explained the need to address illicit materials in mass balance calculations through UNTP, suggesting the use of volume reconciliation and conversion factors to detect unreported illegal inputs. Steven clarified the approach by providing an example of managing inputs from different sources and discussed the potential for implementing best practices to detect illicit content. The group agreed that this feedback was important and aligned with existing principles, though it primarily involved messaging and best practices rather than significant technical changes.

---

#### Digital Product Passport Specification Discussion

The team discussed feedback on the digital product passport (DPP) specification, focusing on terminology clarity and data modeling. Tobias raised concerns about distinguishing between country of production and country of origin, particularly in downstream products where materials come from different origins. Steven explained the current distinction between production (where the final product was made) and material provenance (where constituent materials originated), though acknowledged the terminology could be confusing for users from different regulatory contexts. The group also discussed multilingual support for product information, with suggestions to add language code fields to the specification and leverage the identity resolver for handling multiple language versions of product passports.

---

## 28-04-2026 Meeting EU timezone

### Quick recap

This meeting focused on the upcoming public review of UNTP (United Nations Traceability Protocol) version 0.7. Steven provided updates on recent changes, including a new video focusing on supply chain resilience rather than anti-greenwashing, and introduced a new governance concept called the "implementation tree" which visualizes how UNTP serves as a common trunk with sectoral forums as branches and specific implementations as leaves. The group discussed how UNTP aligns with EU Digital Product Passports (DPP), particularly regarding textiles and batch-level requirements, though specific regulatory details remain unclear. Participants also addressed the need for clearer digital and interoperability standards in seafood traceability, with Huw Thomas from Global Dialogue on Seafood Traceability expressing concerns about EU regulation gaps. The conversation ended with İrem confirming OpenSupply Hub's registration as a UNTP identity resolver and their participation in the UNECE Corporate Identifiers Working Group.

---

### Next steps

* **Technical Working Group**: Resolve the couple of outstanding technical bugs to enable the release of UNTP 0.7 for public review (implied to be in the next few days).
* **Steven/UN Team**: Send out announcement via email/Google Mail mailing list when 0.7 public review is open, including instructions and links for feedback.
* **Steven/UN Team**: During the 60-day public review, collect feedback, aggregate tickets/issues in GitLab, and send updates to the email list with links to feedback items for comment.
* **Steven and Huw Thomas**: Have an offline conversation in the next week or two about mapping GDST seafood traceability specifications to UNTP, especially regarding common core elements and alignment.
* **Steven**: Potentially discuss with the EU Commission about seafood traceability digitization and interoperability requirements while in Brussels in 3-4 weeks.
* **İrem/OpenSupply Hub Team**: Work on requirements analysis and technical improvements to align OpenSupply Hub platform with UNTP Identity Resolver specification following the release of 0.7.

---

### Summary

#### UNTP 0.7 Public Review Launch

The meeting focused on updates regarding the upcoming UNTP 0.7 public review launch, which is pending the resolution of a few technical bugs. Steven highlighted recent changes, including a new, more generic video on supply chain resilience and sustainability, and a simplified governance page introducing the concept of an "implementation tree" to better illustrate how UNTP can be applied across different sectors and geographies. The group discussed plans to launch sectoral fora for specific industries, with existing pilots and implementations serving as examples for adoption. No major questions or action items were raised during the meeting.

---

#### Transparency Protocol Implementation Discussion

The team discussed the implementation of the Transparency Protocol across different sectors, noting that while each sector presents unique challenges, the core UNTP framework requires minimal changes. Steven apologized for not sending meeting invitations and proposed suspending regular meetings for about a month while the public review process occurs. The group reviewed the public review process, which will be conducted through GitLab tickets accessible via email notifications, allowing stakeholders to provide feedback on the specification. Martin inquired about the relationship between the Transparency Protocol and Digital Product Passport (DPP), particularly in the context of Bangladesh.

---

#### UNTP-EU DPP Alignment Strategy

Steven and Matin discussed the alignment strategy between UNTP (upstream information for market entry DPP) and EU DPP regulatory requirements. They explored how UNTP could be used to meet due diligence requirements for products entering the European market, with a specific mention of a pilot project in Argentina testing automated mapping between UNTP and EUDPP requirements. The discussion touched on the varying levels of granularity needed for DPPs across different commodities, with Steven explaining that while batteries would likely require serialized item-level DPPs, textiles might only need product class-level information, depending on specific regulatory requirements around recycling and material composition.

---

#### Mixed Material Batch Recycling Challenges

Matin and Steven discussed challenges in identifying and regulating batches of mixed materials like cotton-polyester t-shirts, particularly regarding recycling windows and percentages. Matin explained that white cotton is easier to recycle, noting that about 25% of virgin cotton can produce similar threads. Steven confirmed that DPP systems will support batch-level information and outlined the dual purpose of EU regulations: providing sustainability information to consumers and driving circular economies.

---

#### Textile Circular Economy Implementation Challenges

Steven discussed the challenges of implementing circular economies in textiles, particularly regarding the recyclability of materials after extended use and the practicality of scanning labels in bulk recycling processes. He suggested issuing DPPs (textile passports) at a granularity level suitable for consumer choice and recycling purposes, while noting that initial EU regulations are likely to be lenient before gradually becoming more stringent. Matin inquired about the specific requirements for QR code information and decision-making thresholds, but Steven could not provide definitive answers about future EU regulations.

---

#### Seafood Traceability Regulations Discussion

Huw Thomas from Global Dialogue on Seafood Traceability discussed the European Union's fisheries control regulations regarding digitization of seafood supply chains, noting that the regulations fail to specify what "digital" or "interoperable" means. Steven acknowledged awareness of discussions with the commission about seafood but explained that these focus more on food safety and sustainability rather than digital product passports, which are primarily concerned with different issues like overfishing and illegal fishing.

---

#### GDST and UNTP Alignment Discussion

Steven and HuwThomas discussed the alignment of their respective standards and governance diagrams, particularly focusing on how to map GDST specifications to UNTP. They agreed to have a separate conversation offline about bringing their common cores together. HuwThomas mentioned frustration with the Commission's lack of action on regulating GDST and noted that they would only acknowledge it as best practice. İrem asked about the UNECE Stakeholder Forum for Text Data Interoperability and was informed that their role as an identity resolver aligns with GS1 Digital Link. Steven mentioned hopes to release version 0.7 in the coming days, with a target of reaching version 1.0 by mid-year.

---

## 31-03-2026 Meeting EU timezone

### Quick recap

The meeting focused on the upcoming public review of UNTP version 0.7, which is ready for formal review by nation-states and technical implementers. Steven presented the updates made to the specification pages, including upgrades to version 0.7 schema and samples, new implementation guidance sections, and refined best practices content. The group discussed the target audience for public review, with Steven clarifying that feedback would likely come from large producers, manufacturers, conformity scheme owners, and software providers rather than SMEs. Hilde raised questions about how the technical complexity might affect SME adoption, particularly in the fashion and textiles industry, and received reassurance that the specification was designed for technical implementers rather than end users. The timeline for public review was discussed, with Steven estimating a 60-day review period starting in late April, potential completion by June, and UNTP 1.0 release around July.

---

### Next steps

* **Steven**: Send out a note to the group announcing the suspension of regular meetings during the public review period and communicate that updates and feedback will be handled asynchronously via email.
* **Michael Shea**: Raise an issue regarding the organization of normative pages on the site (specifically, whether normative pages should be grouped together for clarity during public review).
* **All interested participants**: Test the new AI prompt/business case template on the site and provide feedback on its usefulness and accuracy.
* **All interested implementers**: Consider committing to pilot implementation of the 0.7 version of UNTP and inform Steven if interested in participating in pilots.
* **Steven**: Update the site's versioning and feedback instructions once 0.7 is released for public review (e.g., update disclaimer panels and version dropdown).
* **Steven**: Wait for and address feedback/issues raised during the 60-day public review period before finalizing 1.0 release.
* **Steven**: Reconstitute the working group meetings after the public review period to address feedback, once sufficient comments/issues have been received.
* **Vlasis (and others interested in agri-food sector)**: Examine the possibility of implementing UNTP 0.7 for pilot testing after the public review, and inform Steven of decision.

---

### Summary

#### UNTP Public Review Preparation

The team discussed the upcoming public review of UNTP, which is set to begin after the current meeting. Steven presented updates to the specification pages, including upgrades to version 0.7 schema and samples, new implementation guidance for each credential type, and refined content in the Best Practices and benefits sections. He proposed suspending regular meetings during the public review period and suggested experimentally using AI prompts to generate business cases for UNTP implementation. The group was invited to provide feedback on the current version before it goes into public review, and Steven asked for potential pre-production implementers, particularly from specific industry segments like textiles, agri-food, or critical minerals, to come forward.

---

#### UNTP-GDST Collaboration Discussion

Steven and Vlasis discussed the potential collaboration between UNTP and GDST (Global Digital Seafood Traceability) to create a comprehensive agri-food architecture. They noted that while GDST 1.2 is currently in use, there are plans for GDST 2.0 to extend beyond seafood to include livestock and leather products. Steven mentioned that they are working with GDST to apply lessons learned and create a scalable architecture for agri-food on top of UNTP, once the technical foundation of version 0.7 is established and enters public review. The discussion also touched on the need for more implementers to trial version 0.7, as there is some reluctance to invest in implementation before the final standard at 1.0 is released.

---

#### Normative Pages and UNTP Protocol

Michael raised a question about consolidating normative pages in one location to make them easier to find, which Steven acknowledged as reasonable but noted that keeping the site complete rather than having empty pages was a priority. Hilde, an academic researching supply chain transparency in fashion, joined the meeting to discuss concerns about the complexity of the UNTP protocol compared to GS1, questioning whether a simpler implementation might be developed for SMEs in fashion and textiles.

---

#### GS1 and UNTP Compatibility Discussion

Steven explained that the GS1 approach and UNTP are compatible, as both use link resolver ideas to find data about things, with UNTP being a generalized version of GS1's identity resolver. He clarified that these technical specifications are intended for implementers rather than SMEs, who typically use software that has already implemented these standards. Hilde asked about the difference in messaging between GS1's direct approach to SMEs versus the technical focus of UNTP, noting GS1's presence in webinars promoting simple subscription options.

---

#### UNTP Protocol Implementation Discussion

The group discussed the UNTP protocol and its implementation. Steven explained that while GS1 plays a role in both identifying products and implementing standards, it primarily focuses on the retail end rather than upstream supply chain activities. The discussion clarified that the public consultation on UNTP is primarily aimed at service providers and digital solution providers rather than SMEs, who will simply choose appropriate software systems without needing detailed technical knowledge. The timeline for UNTP 1.0 release was estimated for July 2026, following a 60-day public review period starting in late April.

---

## 31-03-2026 Meeting US timezone

### Quick recap

This meeting focused on the transition of the UNTP specification from technical development to public review and sectoral implementation. Steven provided updates on the 0.7 version of the specification, which is ready for public review, and discussed plans to simplify the governance structure after this phase. Mariano shared details about a new pilot project in Argentina aimed at implementing UNTP across the textile supply chain, with plans to test interoperability between different systems and potentially register data in the EU registry. The group discussed challenges around sector-specific implementations, particularly for textiles, and the need for better communication and coordination between different sectoral groups. Nick raised concerns about maintaining momentum and effective communication across sectoral groups as the focus shifts from technical specification to implementation. Steven explained the transition from top-down standard design to bottom-up sectoral collaboration, emphasizing the need to empower community-led implementations while maintaining core UNTP standards. The conversation ended with a review of recent updates to the UNTP specification website and guidance materials.

---

### Next steps

* **Steven**: Send an email after the call with contact information for the sector-specific (including textiles) working groups to relevant participants.
* **Steven**: Improve discoverability of sector-specific groups and implementation projects from the UNTP homepage within the next week or so.
* **Steven**: Work with the UN to define and communicate the new governance and participation structure for sectoral implementation and adoption, and seek group input on the proposed structure.
* **Mariano**: Register the Argentina textiles pilot project as a community implementation and share required information with Steven.
* **Steven**: Share a document with Mariano (and possibly the group) comparing UNTP and JTC24/EU DPP technical requirements and mapping approaches.
* **Mariano**: Share contact/email information with Steven for coordination on the Argentina textiles pilot.
* **All participants**: Review the updated 0.7 specification pages and provide any last-minute feedback before public review.
* **Steven**: Update the site with information on how to find, join, and influence sectoral implementation efforts, and how to register projects.
* **Steven**: Communicate to the group about the launch of public review and the new structure for moving to implementation and adoption.

---

### Summary

#### Impact Measurement Working Group Update

Ophelias introduced herself as someone working in impact measurement and product passports, explaining her background with the Zyed Sustainability Prize and a digital climate label she created in 2019. She clarified her confusion about the meeting structure, learning that the group had been divided into four working groups six to twelve months prior, with information meetings held monthly for casual observers. Steven explained that they are currently at a transition point, with version 0.7 being the candidate for public review and finalization.

---

#### Digital Product Passports Discussion

Ophelias discussed writing a position paper for the UK regarding digital product passports under existing product law, focusing on border entry documentation as a third country rather than part of the EU. Steven mentioned that version 0.7 is nearing completion and will undergo a 60-day review by member states before the final 1.0 release, which will likely revert to a simpler governance structure focused on sectoral adoption including textiles and critical minerals. The discussion touched on sector-specific work, with Ophelias inquiring about the textile paper's authorship and Steven noting that various sector-specific repositories are in development, including a pilot in the electronics sector led by the Responsible Business Alliance in the US.

---

#### UNTP Sector Forum Implementation Discussion

Steven discussed the UN's approach to creating sector-specific forums for implementing UNTP, including efforts in data centers, batteries, agriculture, and textiles. He explained that while there was earlier strategy to appoint sector representatives, the current approach focuses on bottom-up consensus and cross-sector interoperability. Mariano announced a pilot project in Argentina for textiles implementing UNTP, and requested feedback and contact information for the relevant sector group. Steven agreed to provide contact information and improve discoverability of sector-specific groups from the UNTP homepage.

---

#### UNTP Implementation Transition Planning

The meeting focused on the transition of UNTP from specification development to implementation and adoption. Steven announced that version 0.7 of the specification has been updated and will soon enter public review. The group discussed the need to restructure from technical working groups to sectoral implementation groups, with Mariano sharing details about his pilot project in Argentina that aims to implement DPPs for 20-30 companies and test interoperability with the EU registry. Nick raised concerns about communication clarity and the need for better visibility into sectoral implementation decisions. The group agreed to move toward a bottom-up approach where sector communities can collaborate independently while anchoring their work in UNTP core standards.

---

## 17-03-2026 Meeting EU timezone

### Quick recap

The Supply Chain Working Group meeting focused on reviewing UNTP version 0.7 specifications before entering public review. Steven presented updates to the specification pages, including new vocabulary taxonomies, implementation guidance, and architectural improvements. The group discussed how manufacturers and software providers can implement UNTP standards, with different approaches needed for large enterprises using systems like SAP versus small and medium-sized enterprises (SMEs) using simpler systems or spreadsheets. Anett from the Fashion Producer Collective raised questions about testing the specifications and how to connect internal systems with brand requirements. The discussion covered various implementation scenarios, including the role of software providers, the European Union's mandatory DPP requirements, and the need for collective action to influence software vendors. The conversation ended with agreement that version 0.7 is ready for public review, pending final naming conventions for certain sections.

---

### Next steps

* **Michael**: List suggestion for a better name for "implementation guidance" as an issue in GitLab, including any alternative naming suggestions.
* **Steven**: Clean up and merge updates to the specification pages, including addressing naming suggestions for "implementation guidance" and "best practices" (or "advanced concepts"), in preparation for the 0.7 release.
* **Steven**: Go through all open/closed issues in the supply chain group in the next day or two, point to the relevant specification pages that implement each issue, and close issues as appropriate.
* **All working group members**: Review the updated specification pages (especially product passport, facility record, and traceability event) and provide any urgent feedback or suggestions for changes before the 0.7 release.
* **Steven**: Update the test playground/documentation to indicate that it is not yet updated for 0.7 and will be updated in the coming weeks.
* **Anett (and Fashion Producer Collective)**: Identify which software systems are in use by member manufacturers, and engage relevant software vendors to request/add support for UNTP protocol (version 0.7) as appropriate.
* **Michael**: Set up a separate call with Anett to discuss daily practicalities and adoption details for the Fashion Producer Collective.
* **Steven**: Reach out to software providers listed in the Software Solutions Implementation Register after 0.7 release to confirm their intent and progress on UNTP implementation.
* **All**: Suggest better names for "best practices" (e.g., "advanced concepts") and provide feedback before the 0.7 release.
* **Anett**: Send email to Michael to schedule follow-up call on adoption/practical implementation for the Fashion Producer Collective.

---

### Summary

#### UNTP Specification Version 0.7 Update

The Supply Chain Working Group discussed the transition to version 0.7 of the UNTP specification, which will be released in the coming days and serve as the basis for formal public review. Steven presented updates to the specification pages, including changes to the digital product passport model, such as removing performance dashboards and replacing them with categorized claims, and adding concepts like labels based on gap analysis with European standards. The team also added implementation guidance to help users map their product requirements to the standard, addressing questions about how to adapt the specification for different industries and use cases.

---

#### UNTP Specifications Update Meeting

Steven presented updates on three specifications: product passport, facility record, and traceability events. Michael suggested changing the term "implementation guidance" to avoid confusion with existing navigation terms. Virginia proposed alternative names including "Guidance on the Use of UNTP" and "Guidance on the Use of UNTP Components." Steven explained the architecture of UNTP components, including core vocabulary, industry extensions, and conformity schemes. The team discussed performance metrics taxonomy and conformity topics to standardize numerical measurements across different passports. Steven announced that the specifications would move to version 0.7 for public review in the coming days, with a request for team members to review the documents and provide feedback on any needed changes.

---

#### Project Review Status Discussion

Steven and Michael discussed the status of a project that is ready for public review, with content checked in and awaiting final review before a Docusaurus version release. They reviewed the consistent structure across different pages including Brett's conformity credentials page and Harley's Digital Identity Anchor schema. Michael suggested renaming the "best practices" section as these topics are important and might be overlooked with that title.

---

#### UNTP Project Progress Update

Steven provided an update on the UNTP project's progress, highlighting 11 specifications targeting different implementer groups, over 680 community members, and successful pilots in Australian agriculture and electronics. He noted that while version 0.7 is not yet final, it is ready for public review, with significant external groups like GDST and Tech Against Trafficking seeking alignment. Anett inquired about testing opportunities for the Fashion Producer Collective, and Steven confirmed that version 0.7 would be suitable for pilots, though he noted that the test playground needs updating.

---

#### Product Passports Implementation Discussion

Steven discussed implementing product passports for the Fashion Collective, suggesting they could use open source tools or manufacturer resources to map garment properties like size and color to direct properties and characteristics. He referenced the Responsible Business Alliance's Responsible Minerals Assurance Scheme as an example of industry standards and explained how conformity criteria could be referenced in product passports. Steven highlighted the challenge of navigating the numerous industry standards (around 500 schemes globally) and their associated criteria, using standardsmap.org as an example of the extensive landscape of conformity standards in agriculture, textiles, and other sectors.

---

#### UNTP Specification Classification System

Steven explained the purpose of the UNTP specification, which is a classification scheme to organize and compare different conformity criteria across various industry schemes. He described how this system could help reduce audit fatigue for manufacturers by allowing brands to accept certificates from trusted schemes rather than requiring their own audits. Steven also mentioned previous pilot programs, including one in Australia focused on tracing Australian beef cattle to farms and ensuring non-deforested status through satellite surveys.

---

#### EUDR Requirements and Digital Passports

The team discussed ongoing work on EUDR requirements and digital product passports, with Steven explaining two completed pilots involving agriculture and data center components, while noting that textile-specific work is still in early preparation stages. Anett inquired about connections between this work and the UNECE stakeholder consultation group, which Michael confirmed is led by Christian and involves sector-specific teams including textiles. Steven suggested that larger manufacturers could begin reviewing the current implementation guidance and mapping principles, though he noted that textiles would likely have fewer mappings than battery products due to differences in product lifecycle.

---

#### UNTP Version 7 Testing Discussion

The team discussed the upcoming testing of UNTP version 7, focusing on interoperability and conformity claims layers. Steven emphasized the goal of enabling different manufacturers to produce digital textiles passports using their own internal systems without relying on specific platforms imposed by brands. Anett raised questions about the practical implementation and linkage between manufacturers' ERPs and brands' systems, which Michael offered to address in a separate offline discussion. The group also mentioned an online meeting scheduled for April 15 and Anett's involvement in various working groups.

---

#### UNTP Digital Product Passport Implementation

The discussion focused on implementing UNTP digital product passports as a standard for connecting manufacturers' production systems with brands' supply chain management systems. Steven and Michael explained that manufacturers don't need to log into a separate platform, but rather need software providers to implement the UNTP protocol in their existing systems. They clarified that while large organizations with IT departments might implement this directly, small and medium enterprises (SMEs) would need to work with their software providers to ensure compliance. The conversation highlighted that SMEs in the fashion industry would need to choose software solutions that support UNTP, whether through existing modules or new implementations, rather than having to use multiple brand-imposed systems.

---

#### UNTP Compliance for Fashion Manufacturers

The group discussed how small and medium-sized fashion manufacturers can implement UNTP compliance, with Steven and Michael explaining that rather than purchasing new software, manufacturers should use their existing systems. They clarified that the approach would depend on the manufacturer's size and technology usage, with options including working with common software providers, using spreadsheets with built-in mapping, or accessing a free ITC platform for Global South SMEs. Anett confirmed they would begin assessing these options through working groups in mid-April, though Michael suggested this timeline should be verified.

---

#### Digital Product Passport Implementation Discussion

The group discussed the implementation of digital product passports (DPP) and UNTP specifications, particularly focusing on European regulations and technical standards. Suna explained that European implementation would involve a central registry system where DPPs are registered rather than created, and noted that Microsoft has proposed an OpenDPP framework that could align with UNTP ecosystem needs. The discussion addressed how fashion producers could pilot version 7 specifications, with Steven clarifying that software providers would need to implement the standards, either through existing platforms like Yimpact or by developing new solutions. Michael and Anett discussed practical adoption challenges, including incentives for software providers to implement UNTP, with Michael explaining that EU-funded projects have been driving smaller providers' participation.

---

## 17-03-2026 Meeting US timezone

### Quick recap

The meeting focused on the upcoming 0.7 release of UNTP, which is approaching public review by member states. Steven presented the key changes including updated site pages, new core vocabulary and taxonomies for categorizing conformity claims, and performance metrics that enable corporate-level reporting aggregation. The discussion covered how different types of evidence and criteria can be linked in claims, with particular attention to whether reference criteria should be mandatory versus optional, ultimately deciding that at least one of reference criteria, regulation, or standard must be present. The team also reviewed how industry-specific mappings work, using battery passports as an example, and discussed the broader vision of UNTP enabling continuous machine auditing of sustainability claims at scale to address compliance challenges in global supply chains.

---

### Next steps

* **Steven**: Review and close all remaining open tickets with references to the spec pages in the next day or two.
* **All group members**: Review the updated 0.7 pages (including core vocabulary and core taxonomies) and provide feedback if anything important is missing before 0.7 is locked for member state review.
* **Christian**: Review the mapping of 88 properties in the product passport (especially for battery passport/DIN spec) and provide feedback on any inaccuracies found.
* **Steven**: Consider making "reference criteria" optional in the schema, and ensure that at least one of reference criteria, reference regulation, or reference standard is mandatory for claims.
* **Steven**: Make any necessary schema tweaks based on the discussion (e.g., reference criteria optionality, mandatory reference for claims, etc.).

---

### Summary

#### UNTP 0.7 Release Updates

Christian and Steven discussed updates to the UNTP 0.7 release, which is set for member state review. Steven presented the current work-in-progress version, explaining that it includes updated pages with version 0.7 schema and examples across various sections like Product Passport, Conformity Credential, and Traceability Events. He noted the addition of an "Implementation Guidance" section that helps map industry requirements to UNTP passports, using the battery passport as an example based on a published specification from DIN. The team agreed to review specific tickets regarding reference criteria changes, with Christian suggesting they should be made optional rather than mandatory.

---

#### DIN to UNTP Mapping Assessment

Steven and Christian discussed mapping requirements from the DIN specification to UNTP digital product passport. They identified three types of mappings: direct property mappings, product-specific characteristics stored in product characteristics, and performance claims assessed against external standards. The team discovered one missing element in their model - product labeling requirements - which they added after identifying it during the mapping exercise. Steven concluded that the mapping appears feasible based on their initial assessment, pending review from Kristen.

---

#### UNTP Ecosystem Version 0.7 Update

Steven presented updates on the UNTP ecosystem, highlighting new sections in the DPP and other credential types, including challenges and code snippets. He announced that version 0.7 is close to public review, introducing new pages on core vocabulary and taxonomies to help categorize and compare performance claims across different standards and schemes. Steven explained the purpose of the conformity topic and performance metrics classification schemes, emphasizing their role in making numerical claims consistent and easily rollable up to corporate disclosures. He requested feedback on these new pages and mentioned that future meetings would be paused during the public review process to address any comments.

---

#### Performance Metrics Classification System Overview

Steven explained the purpose of the classification scheme for performance metrics, comparing it to general ledger accounting in corporate finance. He demonstrated how metrics at the product passport level can be rolled up for corporate disclosures, using the example of emissions reporting. Steven also showed how external criteria from organizations like the Responsible Business Alliance can be linked to claims in the system, providing detailed descriptions and URLs for assessment criteria.

---

#### Sustainability Standards: Complexity and Challenges

Steven explained the complexity of sustainability and conformity standards, noting that over 500 schemes exist globally with approximately 15,000 criteria combined. He highlighted how these standards, including European Delegated Acts, follow a similar architectural approach despite varying in importance and origin. Steven used Amazon as an example to illustrate the challenge of consumer understanding, where a supplier's claim of ABNT Ecolabel compliance might not be meaningful to consumers.

---

#### UNTP Conformity Vocabulary Standardization

Steven explained the purpose of the UNTP conformity vocabulary catalog, which aims to help scheme owners like RBA break down their criteria into fine-grained components and classify them according to a standardized vocabulary. This allows for better comparability among different schemes and product passports. Christian asked if scheme owners could express general compliance without referencing specific criteria, and Steven confirmed this was possible through high-level claims, though detailed breakdowns are available for those who need them.

---

#### Automated Auditing for Value Chains

Steven explained the purpose of UNTP, which aims to replace manual paper-based auditing with continuous automated auditing of data and claims in value chains. He clarified for Ann how standard classification schemes and core taxonomies provide comparability between different schemes by using machine-readable URLs and classifications. The discussion ended with Christian asking about linking evidence attributes to conformity credentials, though the answer was cut off at the end of the transcript.

---

#### Digital Credentials and Identity Resolution

Steven and Christian discussed the implementation of digital credentials and identifiers, particularly focusing on how DIDs (Decentralized Identifiers) can be used to represent both physical things and credentials. They explored the challenges of handling different types of evidence, including paper certificates and satellite images, and how an identity resolver could be used to find relevant information. The conversation concluded with an explanation of how DIDs could be used to identify products or facilities and resolve to wallets or URLs containing multiple data items, rather than being directly tied to specific credentials.

---

#### Optional Reference Criteria in Claims

Christian and Steven discussed making reference criteria optional in the claim class, considering that not all references might need a specific criteria. Steven explained that while logically it might seem optional, the conformity topic is kept mandatory in the passport to help organize and categorize claims, especially as the system scales up with many claims. They clarified that there are two different conformity topics: one from the scheme owner and another from the product passport, which may sometimes be different but are necessary for proper classification and readability.

---

#### Product Passport Taxonomy Requirements

The team discussed requirements for product passport taxonomies and mandatory reference criteria. They agreed that at least one of reference criteria, regulation, or standard must be present for meaningful claims, with Steven clarifying that evidence is separate from these references. The discussion covered how industry-specific profiles could tighten mandatory field requirements while maintaining UNTP compliance. Steven explained the broader context of UNTP's goal to enable continuous machine auditing of sustainability claims at scale, addressing the challenge of detecting non-compliance when handling high volumes of data. The team was reminded that version 0.7 would be frozen for member state public review within a few days.

---

## 03-03-2026 Meeting EU timezone

### Quick recap

The Supply Chain Working Group meeting focused on finalizing the UNTP 0.7 release candidate, with Steven presenting progress on consolidating data models and addressing traceability event definitions. The group discussed and debated terminology for product lifecycle events, considering alternatives to "modify" and exploring concepts around circular economy language. Michael and Rafael contributed insights about mass balance verification and blockchain-like approaches to maintaining records without revealing sensitive supplier information. The conversation ended with a detailed explanation of how UNTP handles conformity credentials and scheme endorsements, with Bogharald suggesting a trust register model for scheme verification.

---

### Next steps

* **Steven**: Finalize the integration and simplification of all data models into one unified model and demonstrate how to extend it for industry-specific use cases (e.g., battery passport) by the next call.
* **Steven**: Check that the new packaging element meets all requirements of the referenced EU regulation before publishing with the 0.7 release.
* **Steven**: Confirm alignment between UNTP's "conformative vocabulary" and EU "rulebooks" to ensure interoperability and update documentation as needed.
* **Steven**: Update the traceability event model to integrate with the rest of the UNTP model, using the agreed event types (make, move, maintain/revise), and connect it to UNTP product and facility vocabularies.
* **All (via Slack)**: Vote on and decide the final terminology for the "modify" event (options: maintain, revise, etc.) and update the model accordingly before 0.7 release.
* **Steven**: Revisit and clarify in the model how to distinguish between product consumption and record retention periods, especially regarding decommissioning of DPPs and regulatory requirements.
* **Steven**: Prepare and (if possible) show a live example of a conformity catalog in an upcoming meeting.
* **Steven**: Update the vocabulary endpoint from test.uncfact.org to vocabulary.unc.org for the 0.7 release.

---

### Summary

#### Data Model 0.7 Release Progress

The meeting focused on the progress and upcoming release of the 0.7 candidate for public review. Steven discussed the consolidation of data models into one unified model to simplify the vocabulary and make it easier to extend for industry-specific applications. He also presented a revised model for digital traceability events, which aims to address concerns from organizations that have implemented GS1's EPCIS standard. The group discussed the potential for creating a profile that aligns with both UNTP and EPCIS standards, allowing for flexibility in implementation. Steven expressed confidence in the progress made and planned to demonstrate the ease of extending the unified model with a few examples before the release.

---

#### Event Definitions and Naming System

The team discussed the definitions of make, move, and modify events in their model, with Steven explaining that make events involve creating new products, move events involve transferring products between facilities, and modify events involve repairs or modifications to the same product. They agreed that the current naming system, while simple, might be misleading, particularly with the term "modify." The team also discussed the potential impact of changing these event names in future versions, as it could cause significant issues. Steven mentioned that from version 0.7 onwards, they would be publishing their vocabularies to the production endpoint, emphasizing the importance of getting the event names right.

---

#### EPC Terminology and DPP Decommissioning

The team discussed terminology around maintaining and modifying EPCs, with Virginia suggesting "revise" as an alternative to "modify" to avoid implying a different product. Adrienna raised questions about the decommissioning of DPPs, particularly in the context of recycled materials like shredded tires used in road construction, noting that while the original product may be consumed in the recycling process, the digital record might still need to be maintained. Steven explained that when materials like tires are recycled into new products, a new DPP may be created to track the origin of the recycled material, even though the original tires no longer exist.

---

#### Digital Product Passport Regulations

The group discussed regulatory requirements for digital product passports in the EU, where member states have different retention periods ranging from 6 months to 10 years. Steven noted the need to distinguish between product consumption and record retention periods, particularly regarding the availability of product passports after a business ceases to exist. Michael shared insights from Michelin's workshops with recyclers, highlighting how recyclers can now access detailed information about tire composition, though questions remain about the duration of this backward reference tracking.

---

#### Mass Balance in Recycling Processes

Steven and Michael discussed mass balance calculations in the context of tire recycling and battery production. They emphasized the importance of verifying mass balance claims with evidence from input materials to output products, without necessarily revealing commercially sensitive supplier information. Steven suggested using third-party auditors and potentially automating the process to reduce costs. They also highlighted the need to consider both quantities and qualities in mass balance assessments, using product passports to provide information on the carbon intensity of inputs.

---

#### Product Modification Terminology Discussion

The group discussed terminology for product modification events in a circular economy context, focusing on the distinction between make, move, modify, and maintain events. Steven presented a diagram showing how credentials can verify mass balance claims through automated auditing, which would be more cost-effective than human audits. The team agreed to change "modify" to "maintain" in their terminology, and Rafael suggested "enhanced" as an alternative, though Steven noted that "maintain" had the advantage of carrying a circularity connotation that would appeal to Adrienna.

---

#### Circular Economy Terminology Discussion

The team discussed terminology related to circular economy concepts, with Adrienna expressing concerns about the proposed terms "modify and maintain" not adequately conveying circularity. Steven and Michael agreed that while the terminology should be clear for programmers, they need to consider how it might be interpreted by a wider audience. Rafael suggested using a blockchain-like approach to maintain records without revealing sensitive supplier information, which Steven confirmed aligns with the UNTP framework's concept of auditable history and trusted governance regimes for mass balance verification.

---

#### Blockchain Implementation in UNTP Discussion

The discussion focused on blockchain technology and its application in UNTP, where Rafael suggested implementing blockchain-like mechanisms for data verification, but Steven clarified that while blockchain principles of tamper-proof records are valuable, specific blockchain technologies are not suitable due to lack of interoperability. The conversation also covered reporting periods for facilities, with Steven explaining that these are now associated with claims rather than facilities, allowing for various overlapping periods. Finally, they discussed the language of claims in UNTP, highlighting the challenge of representing compliance with various standards and regulations, and the need for algorithmic verification of performance claims to prevent fraud.

---

#### Digital Trade Verification Conformity Schemes

The discussion focused on UNTP's approach to digital trade verification and conformity schemes. Steven explained how algorithmic due diligence uses machine-readable credentials to verify claims in product passports, with a particular emphasis on the importance of digitally referenceable criteria from various conformity schemes. The group discussed how UNTP helps reduce complexity by creating a conformity catalog that allows schemes to publish their rules in a consistent, machine-readable format, even when those schemes are not owned by UNTP. Bogharald suggested that the middle box in their model could function as a trust register, which Steven confirmed was already part of UNTP's scheme endorsement system that categorizes schemes based on their level of external endorsement.

---

## 03-03-2026 Meeting US timezone

### Quick recap

This meeting focused on reviewing and addressing issues in the UNTP data model, with Steven leading the discussion and participants providing feedback. The main topics covered included updates to the data model structure, particularly consolidating vocabulary between core and DPP/DCC components into a single model, and changes to traceability events to better align with GS1 EPCIS standards while maintaining flexibility for non-EPCIS implementers. Key discussions centered around making party role fields optional rather than mandatory, handling transport emissions data in the mass balance framework, and addressing battery passport specific requirements including mandatory fields and date types. The team also discussed how to handle dynamic information in battery passports through separate verifiable credentials rather than modifying the core passport structure.

---

### Next steps

* **Steven**: Do an example (or two) of extending the unified data model for battery passport use case before the next meeting.
* **Susanne**: Connect (re-connect) Steven with the contact working on Chinese lifecycle event standard for review and comparison.
* **Steven**: Prepare and submit pull requests in the next day or two to update the model based on feedback (e.g., mandatory/optional fields, thresholds in measure, etc.).
* **Steven**: Make a note and update the model to make "party role" and "related party" (previously "object party role") optional in product and facility, and consider renaming for clarity.
* **Steven**: Add an optional "role" field to Credential issuer to distinguish issuer types (e.g., manufacturer, scheme, conformity assessment body) and make "related role" optional.
* **Steven**: Review and correct the spelling of "product quantity" label (add missing 'u' if needed).
* **Steven**: Raise a ticket (or ensure one exists) to address the need to handle transport/shipping emissions and transport as a product in the data model, and consider developing a guidance page for handling shipping/transport emissions.
* **Christian**: Raise a ticket to request that address be added as an optional field in Party.
* **Steven**: Discuss with Harley (and possibly the technical working group) a methodology for making certain fields mandatory in extensions (e.g., for battery passport) without redefining core semantics, and raise a ticket for this discussion.
* **Christian and Steven**: Collaborate on the battery passport extension to establish a repeatable methodology for extensions, ensuring the approach can be reused for other domains.
* **Steven**: Update the Slack channel link and post the new join link today.

---

### Summary

#### Follow-up Meeting on Technical Tools

The meeting began with technical discussions about recording and note-taking tools. Steven noted this was a follow-up meeting to one held 8 hours earlier, primarily targeting US time zones but also accommodating European participants. Susanne mentioned experiencing connection issues when trying to join what she believed was an earlier meeting at 11am, though Steven confirmed she could have joined this meeting instead. The meeting appeared to be getting underway with plans to review open issues and their closure pathways.

---

#### Supply Chain Data Model Consolidation

Steven reviewed supply chain issues and updated the data model based on feedback, consolidating the vocabulary from separate core and DPP/DCC models into a single model for better manageability. He explained that all components including vocabulary, context files, and credential schemas now come from a unified namespace, which will make it easier for extenders to create new features like battery passports. Steven also discussed changes to the traceability event model, noting that while the intent remained the same, it was realigned to better align with GS1 EPCIS standards rather than redefining them.

---

#### UNTP and EPCIS Integration Challenges

Steven discussed the challenges with the current UNTP approach, which represents an unhappy compromise between GS1 EPCIS and the rest of UNTP. He proposed creating a more aligned set of lifecycle events (make, move, and modify) that would integrate better with the core model and reference other UNTP semantic objects. Susanne raised questions about connecting EPCIS events to the data model and suggested making events more flexible to accommodate various types. Steven explained the difference between their focus on product provenance and EPCIS's focus on trackability, noting that traceability events would likely be more private than public credentials due to sensitive information they contain.

---

#### Credential Data Structure Updates

The team discussed updates to verifiable credentials and data structure requirements. Steven agreed to make party role fields optional in both credential issuer and product information sections, addressing concerns raised by Susanne about mandatory fields being impractical for many use cases. The team also discussed potential improvements to mass balancing processes, with Nick sharing insights about typical manual data ingestion and recalibration practices in commodities sectors.

---

#### Mass Balance Automation Challenges

Steven and Nick discussed the challenges and potential automation of mass balance assessments in commodity and manufacturing processes. They explored the importance of verifiable input data, audited systems, and the role of product passports in ensuring data accuracy and traceability. The conversation touched on separating quantities from calculated facts in mass balance specifications and the potential for automating certain aspects of the process in the future.

---

#### Integrating Transport Emissions in DPP

The group discussed how to handle transport emissions in the digital product passport (DPP) structure. Steven explained that emissions intensity data from mines should be separated from transport emissions data, as the current diagram only shows volume-based shipping information without transport emissions. Nick suggested allowing shipping suppliers to include transport carbon intensity data in a single digital entity, but Steven clarified that this would require additional guidance on handling shipping and transport emissions. The group agreed that transport emissions need to be incorporated into the overall product carbon footprint, though the specific implementation details require further discussion.

---

#### UNTP Battery Passport Extensions

The team discussed extending UNTP core functionality for battery passports, focusing on making certain fields mandatory without changing their semantic meaning. Steven advised against redefining existing terms and suggested creating a repeatable methodology for extensions, potentially using a constraint or rule system. They also addressed the need to distinguish between production and service dates, deciding to initially implement this in an extension with the possibility of adding it to core if widely needed. Finally, they discussed adding address fields to the Party structure, with Steven suggesting this could be implemented as optional fields in Party.

---

#### Battery Passport Dynamic Data Handling

The team discussed handling dynamic information in battery passports, with Steven suggesting using both static information (DPP) and dynamic information as verifiable credentials. Christian and Susanne raised concerns about implementing this approach, noting that it would require issuing additional credentials with issuer and subject information, which might be different from embedding the data directly in the battery passport. Steven acknowledged this as an ongoing debate not just in UNTP but also in Europe, and mentioned that the Surpass team is facing similar questions and reaching similar conclusions about lifecycle data handling.

---

#### Sensor-Monitored Data System Implementation

The team discussed implementing a sensor-monitored data system, with Susanne and Steven agreeing to proceed without mandating it, allowing the market to determine the best approach. Steven explained the connection between criteria and attestation in the rulebook system, demonstrating how schemes like the Responsible Minerals Assurance Program define profiles containing criteria that can be referenced in claims and assessments. The team confirmed that publishing the Global Battery Alliance rulebook is a lower priority after completing the battery passport and Dinspec 99100 work.

---

## 17-01-2026 Meeting EU timezone

### Quick recap

The meeting focused on reviewing and discussing updates to the UNTP (Universal Product Passport) data model, particularly around product parties, packaging information, and facility records.

The group agreed to simplify the party model by allowing multiple parties with defined roles, rather than using a large pre-defined list of roles.

They discussed how to handle packaging information, with Kit raising concerns about different types of packaging across the supply chain, and Adrienne suggesting alignment with the EU Packaging and Packaging Waste Directive.

The team also reviewed proposed changes to how performance metrics and emissions data would be reported, moving away from fixed circularity and emissions performance boxes toward a more flexible but controlled vocabulary of metrics.

Bogharald contributed insights about textile product passports and the importance of machine-readable credentials, while Adrienne emphasized the need for sector-specific metrics and criteria in different industries.

---

### Next steps

* **Steven**: Draft a controlled vocabulary of metrics (including emissions, circularity, water usage, etc.) for use in product and facility records, drawing from relevant standards/frameworks (e.g., ESRS, IFRS, GRI, Pathfinder), and seek subject matter expertise input before the next supply chain meeting in two weeks.
* **Adrian**: Share the updated UNTP Chain of Custody page with the Chemex COC team and provide feedback.
* **Steven**: Review the Packaging and Packaging Waste Directive (PPWR) and Extended Producer Responsibility regulations (as referenced by Adrian) to ensure the packaging information model in the product passport covers all required reporting elements.
* **Steven**: Monitor for the public release of JTC24’s suggested roles for economic operators/actors and update the UNTP party role list as appropriate.
* **Steven**: Develop sample examples showing how circularity and emissions performance claims can be reported using the new, more flexible and rigorous claims structure, to illustrate migration from the current “circularity performance” and “emissions performance” boxes.
* **Steven**: Prepare and demonstrate a working example of a real conformity vocabulary catalog issued by a particular scheme owner for the next meeting.

---

### Summary

#### EU Business Wallet Simplification Progress

Bogharald discussed the progress of business wallets in the EU, highlighting that simplification is now a top priority, with a focus on making public sector wallets mandatory and eliminating pre-certification requirements.

He mentioned that his company has already implemented this simplified system, allowing for direct wallet-to-wallet transactions.

Steven noted a discussion in the W3C Credentials Community Group about differences in wallet verification approaches between Europe and the US, but the conversation focused on the progress and benefits of the European business wallet system.

---

#### UNTP Supply Chain Roles Update

The supply chain group discussed issues and plans to publish version 0.7 of UNTP, focusing on supply chain components including Product Passport, Facility Record, Traceability, and Event.

Steven shared updates on the party model, proposing changes to include multiple party roles relevant to product passports and facility records, while prioritizing simplicity over using a vast standard role list.

The group agreed to review and provide feedback on suggested roles, with Steven expressing a preference for a smaller, focused set of roles.

---

#### ESPR Roles and Packaging Updates

The group discussed roles and responsibilities in the EU's ESPR and economic operator framework, with Adrienne and Michael noting that multiple roles need to be reported, including manufacturers and importers.

They agreed to follow ESPR Section 32 and subsequent guidance, along with JTC24 recommendations, to determine appropriate roles globally.

The team also addressed packaging information, with Steven proposing to add packaging as an optional property of the product in the data model, including dimensions and material composition.

---

#### Packaging and Product Passport Discussion

Kit raised questions about different types of packaging along the supply chain, and Steven explained how the UNTP system handles fabric and product passports separately.

Adrienne recommended reviewing the Packaging and Packaging Waste Directive (PPWR) and extended producer responsibility regulations, which Steven noted would need to be checked against the current data model.

Michael raised questions about handling nested packaging in the DPP system.

Steven explained that facility records require a defined reporting period to be meaningful, which could be monthly, quarterly, or annual.

---

#### Facility Reporting Period Flexibility Discussion

The team discussed facility reporting periods for sustainability assessments.

Adrienne explained that Together for Sustainability recommends:

* using facility IDs
* allowing one year of primary data, or
* up to three years of documented assumptions if primary data is unavailable

Steven proposed making the reporting period a mandatory attribute while allowing facilities to define their own reporting periods rather than restricting them to fixed timeframes.

The team agreed this was a reasonable approach.

---

#### Material Origin Reporting Requirements

Steven discussed requirements for facilities to report the origin of materials, similar to pilot work on critical mineral supply chains.

Facilities must report:

* material types
* mass fractions
* country of origin

Detailed supplier information is not required due to commercial sensitivity.

He also referenced the Responsible Business Alliance cascading spreadsheet framework used to trace materials to their source for Dodd-Frank conflict minerals compliance.

---

#### Mass Balance and Chain of Custody

The discussion focused on mass balance verification and chain of custody for materials in manufacturing facilities.

Steven and Michael noted that facility declarations about material sourcing are difficult to verify without detailed mass balance data, which is often commercially sensitive.

Adrienne described Chemex work on chain of custody guidelines and highlighted a significant update to the UNTP Chain of Custody page, including a new transparency diagram showing how facilities can provide traceability while protecting sensitive information.

---

#### Product Passport Performance Metrics Update

The team discussed replacing circularity and emissions performance claims with categorized claims in the Product Passport.

Steven proposed improving rigor and comparability through a controlled code list for reporting metrics, structured similarly to conformity topic lists and aligned with ESRS, IFRS, and GRI.

The group agreed to review the revised model and provide feedback.

---

#### Circular Metrics Recording Framework

Adrienne raised concerns about how companies such as Siemens would record circular performance metrics, especially for remanufacturing.

Steven explained that performance facts could be reported as claims against criteria using a controlled vocabulary covering activities such as:

* recycling
* repair
* remanufacturing

The group agreed to develop a flexible structure with a controlled vocabulary before the next supply chain meeting, drawing on frameworks such as the WBCSD Pathfinder.

---

#### Performance Tracking System Development

The group discussed development of a performance tracking system.

Michael highlighted limitations of arbitrary performance boxes and supported a flexible but controlled vocabulary.

Steven explained that the new UNTP data model would support multiple performance types, but emphasized the need for governance to prevent loss of meaning.

Bogharald shared insights from a German textile passport project, stressing the importance of machine-readable credentials and the potential for self-issued credentials from reputable organizations.

---

#### Product Passports and Compliance Standards

The meeting reviewed the role of product passports and facility records as manufacturer statements whose credibility depends on brand reputation.

Steven described the optional conformity component, signed by an independent assessor or machine, to support or challenge claims.

Adrienne shared insights from the chemicals sector, emphasizing the need for sector-specific metrics and metadata to generate key indicators and support compliance evaluation.

The group highlighted the importance of publishing schemes digitally to enable comparison of criteria across different conformity schemes.

---

## 17-02-2026 Meeting US timezone

### Quick recap

The meeting focused on reviewing and discussing updates to the UNTP data model, including changes to party roles, facility records, and performance metrics. The group debated the inclusion of multiple party roles in product passports and facility records, with Susanne questioning the necessity of certain roles for EU regulations.

They also discussed replacing circularity and emissions performance measures with categorized claims, with Steven proposing a new approach using controlled vocabularies for metrics.

The team addressed the need for tolerances in product measurements and considered whether to create separate extensions for copper-specific data or include it in a broader critical raw materials extension.

The conversation ended with a brief discussion on updating the definition of the ID property in the model.

---

### Next steps

* **Steven**: Check ESPR Section 32 and other relevant regulations/standards to determine the required party roles for product passports and facility records, and consider community input on whether multiple party roles are needed.
* **All interested parties (especially Susanne, Nick, Todd)**: Comment on the relevant ticket regarding the necessity and scope of party roles in the data model, particularly in the context of ESPR and other jurisdictions.
* **Steven**: Reconsider and potentially revise the requirement for a mandatory reporting period in the facility record, based on Nick's feedback about overlapping claim periods and implementation complexity; seek further input before finalizing.
* **Susanne (and others)**: Add comments to the new ticket regarding the need to capture assessment period (applicable period for which data was assessed) in credentials, and clarify language/requirements for assessment, audit, and validity periods.
* **Christian / Susanne**: Add upper and lower tolerance fields to the measure class in the core model (or raise/progress the ticket for this), to support tolerances for product dimensions/measures, and process the associated ticket.
* **Christian / Susanne**: Raise or update a ticket regarding the handling of corrosion and other attributes for copper and other critical raw materials, and document implementation in the copper extension for now, with a note for future harmonization if similar needs arise in other materials.
* **Susanne**: Update the definition of the ID property in the model to remove or clarify the reference to ISO 8975 and resolvable URLs, as per discussion.
* **Steven**: Assign the new ticket regarding assessment period to the appropriate group (Brett's group) for tracking.
* **All**: Provide feedback and comments on the proposed changes to claims, metrics, and performance measures, especially regarding the controlled vocabulary for metrics and the handling of “Other” metrics, via the relevant ticket.
* **Christian**: Raise a ticket (if not already done) regarding the need for tolerances on measures/dimensions, and ensure it is labeled appropriately (or follow up with Steven if unable to add labels).

---

### Summary

#### UNTP Data Model Party Roles Update

The team discussed updates to the data model for UNTP, focusing on changes to handle multiple party roles for products and facilities. They plan to use the party roles defined in ESPR Section 32 as guidance for encoding these roles in the model.

Steven mentioned addressing a backlog of issues before the next version release, and the team agreed to review the proposed changes to ensure they meet regulatory requirements.

---

#### Digital Product Passport Roles Discussion

The team discussed two main topics: party roles in digital product passports (DPPs) and facility records.

* **Party roles**:
  They debated whether to use the extensive UN/CEFACT code list of 300+ roles or create a more specific list. Nick suggested that for EU ESPR requirements, only the economic operator needs to issue product passports, with manufacturer and importer roles potentially needed in other jurisdictions.

* **Facility records**:
  Nick raised concerns about making the reporting period mandatory, as this could force multiple DFRs to align with different claim periods.

The team agreed to reconsider the mandatory reporting period requirement and to create a new ticket for addressing the assessment period in conformity credentials.

---

#### Assessment Period Clarification Discussion

The team discussed the concept of assessment periods in credentials and reports, clarifying that it refers to the period for which data is assessed, rather than the duration of on-site audits.

Susanne explained this using the Copper Mark credential as an example, distinguishing between:

* the assessment period
* the issuance date
* the validity period of the credential

Steven suggested using the term **“applicable period”** to better convey this meaning. The team agreed that clearer language is needed to avoid confusion.

---

#### Standardizing Assessment Date Reporting

The team discussed the need to clarify and standardize the reporting of assessment dates and periods, with Susanne highlighting discrepancies in the current system.

Steven explained the differences between:

* audit site dates
* assessment periods
* credential validity dates

A ticket has been created to address these issues.

The group also discussed replacing circularity and emissions performance metrics with categorized claims, with Steven proposing a more structured approach using a controlled vocabulary for metrics to ensure consistency and alignment with existing reporting standards.

---

#### Environmental Metrics Implementation Challenges

Nick and Steven discussed the challenges of implementing a system for measuring and disclosing various environmental metrics, such as carbon intensity and product carbon footprint.

Key ideas:

* Create a short list of metrics
* Categorize assessment criteria under each metric
* Separate the vocabulary for metrics and conformity topics from the UNTP core data model to allow easier updates
* Remove confusing performance boxes and replace them with a more user-friendly display

Susanne noted that 2–3 tickets had been issued before the meeting (details not discussed).

---

#### Product Passport Threshold Modeling Discussion

The team discussed modeling tolerances and thresholds in product passports and whether these belong in the core model or extensions.

Key distinctions:

* **Performance thresholds** → defined criteria
* **Claimed performance** → actual measured results

Nick suggested many measurements could be represented as claims with associated standards.

They also discussed:

* difference between product characteristics (e.g. color, size) and performance measures
* need for industry-specific decisions about which data points require verifiable assessments versus simple properties

---

#### Product Dimensions and Tolerance Standards

The team discussed handling dimensions and tolerances in product classes.

Decisions and considerations:

* Add tolerance information to the measure field for product dimensions
* Useful for implementations such as copper product descriptions
* Debate whether copper-specific attributes should be in a dedicated extension or a broader critical raw materials extension
* Steven recommended waiting to see if attributes are reused before moving them into industry-wide extensions

They also clarified the definition of the ID property, removing reference to ISO 8975 and allowing a more flexible approach to resolving URLs.

---

## 03-01-2026 Meeting EU timezone

### Quick recap

The Supply Chain Working Group discussed the process for reviewing and closing open issues in the UNTP specification, with Steven explaining the governance structure and contribution process through GitLab. The meeting focused on mass balance and product passports in supply chain management, including discussions about facility records, carbon footprints, and national regulations across different countries. The group explored digital credentials and transparency in supply chains, covering topics like UNTP architecture, digital product passports, and mass balance calculations for sustainable production, with particular attention to auditing challenges for SMEs in developing countries.

### Next steps

* steven: Close the mass balance ticket after a week if no further comments or concerns are raised on GitHub/Slack, otherwise keep it open for further discussion.
* All participants (especially those with GitHub accounts): Comment on the mass balance ticket on GitHub within the next week to provide consensus, concerns, or questions before the ticket is closed.
* steven: Look up and share the contact information of the person at ITC working on the DPP issuer tool for SMEs/developing countries with David.
Summary

### UNTP Specification Version 0.7 Review

The Supply Chain Working Group discussed the process for reviewing and closing open issues in the UNTP specification, with a focus on reaching version 0.7. Steven explained the governance structure and how participants can contribute through GitLab, including the registration process and commenting on existing tickets. The group reviewed the agenda, which included a quick review of last meeting's minutes, addressing issues towards version 0.7, and a Q&A session. David Jensen introduced himself as a new participant, interested in deploying UNTP in developing countries, and mentioned his background with the UN and GIZ.

### Supply Chain Mass Balance Discussion

The meeting focused on discussing mass balance and product passports in supply chain management. Steven explained how facilities handle mass balance by recording objecting opinions and progressing with majority decisions. He also described the concept of product passports for unique product classes, including how they apply to bulk commodities and changes in production methods. İrem raised questions about overlapping credentials and how the system distinguishes between facility records and product passports. Steven clarified that product passports are attached to specific shipments or batches, while facility records represent broader time-bound performance data.

### Carbon Footprint Mapping in Apparel

The discussion focused on the challenges of mapping fragmented facilities in the apparel industry and calculating product-specific carbon footprints (DPPs) across different countries. Matin raised concerns about how national regulations could affect DPP comparisons between countries, particularly Bangladesh and Australia. Steven explained that while different countries may use varying calculation methods and regulations, the protocol aims to record the calculation basis for each facility, ensuring transparency but not harmonizing national regulations.

### Sustainable Materials Chain Tracking Methods

The discussion focused on mass balance and chain of custody methods for tracking sustainable materials in supply chains. Steven explained that mass balance allows mixing of materials while ensuring totals match on both sides, enabling facilities to claim percentages of sustainable materials based on actual inputs and outputs. Virginia raised a question about conformity certificates and DPPs, which Steven confirmed are time-bound and can be evaluated based on the date of facility evaluation or batch. Jeremy inquired about protocols for transparency and signing of credentials, to which Steven emphasized the importance of digital standards for traceability and transparency, aiming to enable scalable algorithmic due diligence and maintain confidence in sustainability claims.

### Digital Certificate Traceability Solutions

The meeting focused on the transparency and traceability of digital certificates and credentials in supply chains. Jeremy emphasized the importance of public availability and traceability of audit processes to ensure credibility. Steven discussed the UNTP (Universal Numerical Traceability Protocol) architecture, highlighting its ability to create a digital twin of a value chain using interconnected credentials and allowing for verification of entire graphs rather than individual credentials. He also explained the concept of transformation events and the need for an architecture that balances traceability, transparency, and confidentiality, offering alternative means to build trust without compromising sensitive information.

### UNTP Digital Product Passport

The discussion focused on the UNTP digital product passport standard and its approach to traceability and accountability. Steven explained that the standard allows for the digital signing and hashing of evidence to ensure auditor credibility and prevent tampering, while also accommodating different levels of conformity assurance. Rafael inquired about the DPP's consideration of factors like gender and age in production, to which Steven responded that UNTP abstracts these details into a claim structure to accommodate various national regulations and schemes, with industry working groups able to specify relevant criteria at a more granular level.

### Mass Balance and Digital Credentials

The meeting focused on discussing mass balance and digital credentials for sustainable production. Steven explained how facilities handle inputs and outputs, including batch processes and the importance of transparency or auditing for carbon intensity claims. Matin raised questions about apportioning materials across multiple facilities in a value chain, which Steven addressed by emphasizing that facilities are responsible for their own mass balance calculations. David asked about potential bottlenecks in auditing for SMEs in developing countries, to which Steven responded that tools like the ITC issuer toolkit aim to make digital credentialing accessible and efficient for small producers. The conversation ended with Steven proposing to close the mass balance ticket, inviting participants to provide feedback on GitHub if they wished to keep it open.

---

## 03-01-2026 Meeting US timezone

### Quick recap

The supply chain working group meeting focused on administrative updates and discussions around the UNTP specification, including revised terms of reference and meeting minutes. The team explored various aspects of product passports and conformity credentials, discussing how claims and credentials are managed and linked within the UNTP system. The conversation ended with detailed discussions about carbon footprint calculations, data verification methods, and the handling of digital and paper-based credentials, along with identifying a bug in the specification documentation.

### Next steps

* steven: Send email to the main list with links to all issues marked "pending close" and seek consensus on their closure within 2-3 weeks
* steven: Publish this meeting's minutes by tomorrow
* Susanne/Christian: Select key questions from Slack discussion and create corresponding tickets in UNTP GitLab
* steven: Update the specification page with the correct links to the current latest logical model (addressing Christian's point about outdated model links)
* Todd: Raise a ticket about using hashing/zero knowledge proof for PDF certificate validation
* Nick/steven: Clarify in the main specification pages what "link" means in different contexts, particularly distinguishing between discovery links and content verification links
* steven: Update page with the right links to the current latest model (0.61) as identified by Christian
* All participants: Review the published meeting minutes and provide feedback or corrections if needed
* All participants: Review the list of "pending close" issues when email is sent and provide opinions/objections via GitLab or mailing list to establish consensus before closure
* All participants: Ensure they have (or request) access to GitLab for commenting on tickets and participating in consensus process

### Supply Chain Meeting: Mass Balance Focus

The supply chain fortnightly meeting began with a reminder that it is a UN meeting and contributions should be made freely available. The group discussed last week's meeting minutes and considered topics for the current meeting, with mass balance being a key focus from a previous 8-hour meeting. Susanne raised questions on Slack about mapping to EUDPP and data locations, which could be an interesting topic to address. The group also mentioned the need to close tickets and prepare for the 0.7 release in the coming weeks, ensuring any new concerns or unanswered questions are addressed.

### Supply Chain Working Group Updates

The meeting focused on administrative updates to the supply chain working group, including revised terms of reference and meeting minutes. Steven announced plans to close several pending issues and requested team feedback through an email survey, emphasizing the need for consensus on closure. The group discussed the handling of declarations and reporting against various regulatory frameworks, standards, and schemes, with Steven explaining that UNTP serves as a vehicle for claims and evidence against any standard or regulation.

### UNTP Claims and Conformity Discussion

The team discussed how to handle claims and conformity credentials in the UNTP specification, focusing on how these relate to products and companies. Steven explained that UNTP aims to automate auditing through digitalization, allowing for continuous verification of data. He emphasized that claims must be linked to formal methodologies or rulebooks, such as industry schemes or regulations, to have meaning. The team agreed to transfer relevant Slack questions to GitLab as permanent records, with Susanne creating a ticket to clarify the concept of claims and criteria in UNTP.

### Sustainability Claims and Credentials Discussion

Susanne and Steven discussed the challenges of managing multiple sustainability claims and credentials, such as coppermark certifications, in product passports. Susanne expressed concerns about the complexity of linking claims to credentials and the difficulty of updating them when credentials expire. Steven clarified the purpose of claims and conformity credentials, explaining that claims are self-declarations by facilities or companies, while conformity credentials are independent assessments. He emphasized that the passport allows for various performance declarations, which may or may not be substantiated by third-party evidence, while the conformity credential provides a certificate for third-party verified assessments.

### UNTP System Credentials Discussion

Susanne and Steven discussed the use of product passports and conformity credentials in the UNTP system. They clarified that credentials should not be hard-coded into product passports, as they might change or expire. Steven explained that the intent of UNTP is to automate due diligence, not just data exchange. They also discussed the identity resolver specification, which allows for resolving identifiers to lists of associated data, including conformity credentials. The conversation touched on the question of whether to break down conformity credentials into more detail, with Steven suggesting it might be useful for certain applications.

### Claims Management in Digital Passports

Nick explained the concept of claims in the context of digital product passports and facility records, emphasizing that claims can carry various types of data, including self-declared information, and can be verified through third-party audits. He highlighted the importance of managing claims, especially when dealing with thousands of them, and suggested that vendors should be evaluated based on their ability to manage claims effectively. Nick also discussed the granularity of credentials, noting that they can be wrapped up into single claims or broken down into more detailed ones, depending on their intended use.

### Claims vs Properties in Product Passports

The group discussed the distinction between claims and properties in product passports, with Steven emphasizing the importance of objective standards for assessing claims. Susanne proposed a flexible approach where facility identifiers could be discovered and linked to conformity credentials, rather than managing static claims. They also explored the challenges of granularity in emissions audits and the need for relevant information for different stakeholders.

### Product Passports and Carbon Credentials

Steven and Susanne discussed the use of product passports and carbon footprint credentials in supply chains. Steven emphasized the importance of including product-level carbon intensity information in passports, particularly for bulk materials and high-volume items, while Susanne focused on the Global Battery Alliance's approach of calculating carbon footprints at the product level. They agreed that while facility-level credentials are useful, product-level passports are essential for sharing relevant information with subsequent actors in the value chain.

### Battery Carbon Assessment Framework

The group discussed the carbon calculation rules for batteries and the distinction between self-claimed claims and independently assessed conformity credentials in digital product passports. Steven explained that while the Global Battery Alliance provides rules for carbon intensity assessment, mine site emissions are regulated by different frameworks, and product-level independent assessments may be necessary for high-value finished products. The discussion clarified how algorithms can verify the connection between claims in product passports and conformity credentials through shared criteria and identifiers, with Steven emphasizing that links between credentials are not based on URLs but on correct content references.

### UNTP Link Specification Clarification

The meeting focused on clarifying the concept of links in the UNTP (Uniform Networked Trade Product) specification, particularly distinguishing between signpost links for data discovery and actual data content links. Steven explained that while links are important for finding credentials, it's the data within the credentials that establishes valid connections between product identifiers and assessments. The group discussed practical considerations for handling both digital and paper-based credentials, with Todd suggesting the use of zero-knowledge proofs and hashing as a way to validate PDF certificates in the interim. The conversation ended with Christian pointing out a bug in the specification documentation regarding version 0.61, which Steven agreed to fix.

---

## 20-01-2026 Meeting EU timezone

### Quick recap

The UNTP Supply Chain Working Group reconvened under Steven Capell’s leadership to progress the development of interoperable traceability and transparency systems across value chains.  

The group’s primary objective is to finalize **UNTP version 0.7 before June**, enabling wider consultation and early adoption.  

New participants were welcomed, and use cases across seafood, diamonds/precious minerals, and textiles were discussed. Emphasis was placed on:

- Interoperability between existing traceability platforms  
- Adherence to UN rules regarding non‑commercial, public‑good standards  
- Practical alignment between business needs and technical design  

Outstanding technical issues will be addressed prior to the v0.7 release, targeted in approximately six weeks.

### Next steps

- **All participants**  
  Review open supply-chain-related issues/tickets in UN GitLab and provide comments, particularly comparing:  
  - Questions raised by previous groups  
  - Answers provided in the *Transparency Graph* and *Chain of Custody* pages.

- **All participants**  
  Read the *Transparency Graph* and *Chain of Custody* pages on the UNTP site and provide feedback where explanations are unclear or insufficient.

- **John Phillips (Global Trust Registry Project)**  
  Provide consolidated issues, pull requests, and feedback on digital identity anchor changes to the relevant working group within four weeks.

- **Steven Capell**  
  Circulate instructions on registering for UN GitLab to enable direct commenting on issues/tickets.

- **All interested participants**  
  Submit questions or concerns via the mailing list, Slack channel, or email in preparation for the v0.7 release.

### Leadership update

Steven Capell confirmed the resumption of leadership of the UNTP Supply Chain Working Group.  

The group reiterated its mandate to produce **industry‑neutral core standards with industry‑specific extensions**, and to publish outputs as open, common‑good specifications.

### New participants

New members introduced themselves, including:

- Vlasis  
- Denis  
- Xiaodi  
- Matthew  
- Rafael  
- Jennifermoriconi  
- Irene  
- Anett  
- Irem  
- Tobias  

Steven noted that:

- The **seafood sector (GDST)** is moving toward UNTP alignment.  
- UNTP is intended to enable cross‑sector interoperability rather than replace existing domain standards.  

Jennifermoriconi expressed interest in applying UNTP to diamond and precious minerals traceability.  
Participants were encouraged to connect with John Phillips regarding digital identity and the Global Trust Registry.

### UNTP in textiles and fashion

Discussion focused on how UNTP can interoperate with existing textile and fashion traceability platforms (e.g., Industry 4.0 and ChemX).

- Emma (Lectra) presented the **Techstat Genesis** platform for textiles and leather traceability and expressed interest in future pilots.  
- Nick emphasized framing technical discussions in business terms relevant to ESG managers and supply chain owners.  

Future pilots with multiple platforms are anticipated once v0.6 stabilisation and bug fixes are complete.

### UNTP as a supply chain interoperability standard

Steven provided an overview of UNTP as a digital interoperability protocol supporting:

- Digital Product Passports (DPPs)  
- Digital Facility Records (DFRs)  
- Conformity Credentials  
- Digital Traceability Events  

Key characteristics:

- Publish-and-discover architecture  
- Machine- and human-readable data  
- Support for automated due diligence  

Key open questions being addressed:

- Handling confidential and commercially sensitive data  
- Non-participating actors in supply chains  
- Bulk materials and mass-balance models  

These issues are targeted for resolution before the v0.7 release.

### Facility data integration in DPPs

Facility information is linked to Digital Product Passports through **shared identifiers**, rather than hard-coded links.

Nick raised questions regarding ESPR-aligned facility data structures in Europe.  
Steven demonstrated how facility data can be discovered via identifiers within the UNTP model.

Participants were encouraged to review recent updates to the *Transparency Graph* and *Chain of Custody* pages and assess whether they adequately explain:

- Business problem coverage  
- Data discovery patterns  
- Handling of different data types  

---

## 20-01-2026 Meeting US timezone

### Quick recap

The meeting focused on progress toward the development and implementation of UNTP as a digital interoperability standard for supply chain traceability and due diligence.  

Key objectives include publishing **version 0.7 by mid-March** for public review and progressing toward **version 1.0 by June**.  

Discussions covered UNTP architecture, data publication mechanisms, and the role of digital credentials in enabling verification and interoperability across platforms. Participants also explored challenges in transitioning from unstructured to structured data and ongoing work on JSON schemas and linked data ontologies.

### Next steps

- **Steven Capell**  
  - Send a reminder and calendar invite for the next meeting to Susanne and other participants as needed.  
  - Send an email to the working group with instructions for registering on GitLab and guidance on participation (raising tickets, merge requests, etc.).

- **Susanne**  
  - Align with Steven offline to schedule a separate conversation about Coppermark credential details.

- **Fins**  
  - Locate and share the link to the OGC Building Blocks project in the chat or relevant channel.

- **Juan**  
  - Join the Slack channel and mailing list.  
  - Consider raising the topic of a JSON Schema ↔ RDF bridge and potential collaboration with the JSON Schema community, including a possible blog post or promotion to raise UNTP awareness.

- **All interested technical participants**  
  - Review and help resolve open GitLab issues with the goal of reaching v0.7 within 4–6 weeks.

### UNTP version milestones and timeline

Steven outlined the following targets:

- Publish **v0.7** by mid-March for public review.  
- Conduct a **two-month public review** period.  
- Progress toward **v1.0 by June**.

Steven reminded participants of the UN meeting code of conduct:

- Commercial product promotion is not permitted.  
- Contributions to the UNTP website are considered UN Intellectual Property (UNIP).  

The meeting was recorded, and minutes will be published publicly on the website.

### UNTP as digital supply chain standards

Steven introduced UNTP as a collection of digital standards supporting:

- Digital Product Passports (DPPs)  
- Digital Facility Records (DFRs)  
- Conformity / sustainability credentials  
- Digital Traceability Events  

Architecture highlights:

- Verifiable credentials published and discovered via URLs.  
- Facilities and products described using facility records and product passports.  
- Data publication mechanisms are defined but **implementation-agnostic** (e.g., APIs, JSON files, or other approaches).

Adoption considerations discussed:

- Simplicity of implementation  
- Clear incentives for adopters  
- Interoperability across competing service providers

Susanne requested a deeper offline discussion on Coppermark credentials.

### UNTP standard development update

UNTP is being developed as a platform that software vendors can implement in a consistent, interoperable way.

Key points:

- A test playground is planned to help validate implementations.  
- UNTP aims to support **algorithmic due diligence** for sustainability and product quality claims.  
- Specifications must serve both technical implementers and business users.

Steven reiterated that the target for **version 1.0 is June**, with active work underway to resolve GitLab issues.

### Specification timeline and review process

- v0.7 expected in 4–6 weeks.  
- Followed by a formalized public review period (~2 months).  

Steven emphasized:

- The importance of incentives for implementation.  
- The value of a competitive ecosystem of service providers using the same standard.  
- The challenge of verifying data across heterogeneous platforms.

### JSON Schema and linked data integration

Technical discussion focused on balancing:

- Structured JSON schemas for developers  
- Compatibility with linked data / RDF graphs  

Juan expressed interest in collaborating on improving JSON schemas and promoting the UN/CEFACT JSON Schema ecosystem.

Marcus and Fins highlighted existing tooling such as **OGC Building Blocks** that supports conversion between JSON and RDF formats.

The group agreed to continue discussion via Slack and the mailing list, with the shared goal of reaching a level of maturity where implementers can have confidence in the specifications.

---

## Technical Group

import Disclaimer from '../../\_disclaimer.mdx';

<Disclaimer />

:::note Meetings Suspended
Technical Group meetings are currently suspended while the UNTP is in public review. Meetings will be scheduled to resume after the 10th of July, 2026.
:::

## Terms of Reference

### Background

The Technical Working Group (TWG) operates under the United Nations Transparency Protocol governance framework. The group ensures the development, validation, and maintenance of core technical components underpinning UNTP, including identity resolution, decentralised access control, verifiable credentials, and verifiable graphs.
The TWG works in close alignment with other UNTP groups (Adoption, Supply Chain, Conformity) to ensure technical solutions are interoperable, verifiable, and ready for adoption at global scale to meet stakeholder needs.

### Purpose

The TWG is responsible for defining, maintaining, and delivering the technical standards and reference implementations that enable transparency across supply chains. Its purpose is to:

- Maintain and advance the design of the Identity Resolver (IDR), Decentralised Access Control (DAC), Verifiable Credentials Profile (VCP), and other related protocols.
- Provide a forum for technical contributors to review, test, and approve specifications.
- Support development of reference sites, implementations, and libraries that demonstrate concepts at production quality.
- Support formalisation of verification rules for trust graphs.

### Scope & Objectives

The TWG scope covers specification design, open-source reference development, and verification frameworks. Specific objectives include:

- Identity Resolver (IDR):
  - Maintain a resolver framework that supports multiple identity schemas and carriers.
  - Ensure the resolver can handle both decentralised identifiers and other widely used identity schemes in supply chains.
- Decentralised Access Control (DAC):
  - Explore and evaluate methods for decentralised, policy-based, and credential-based access control.
  - Assess relevant approaches and emerging standards without presupposing a single technical pathway.
  - Provide recommendations to guide the evolution of DAC within UNTP.
- Verifiable Credentials Profile (VCP):
  - Explore approaches for representing, exchanging, and presenting verifiable data.
  - Ensure alignment with relevant global standards bodies while keeping technology choices open.
  - Define requirements for rendering, presentation, and interoperability.
- Verification Rules:
  - Formalise rules for validating UNTP datasets in a discovered trust graph.
  - Explore creation of a shared library of verification rules.
- Reference Implementation:
  - Support the delivery of a functioning reference site and open-source tooling.
  - Achieve sufficient quality and stability to support the UNTP version 1.0 release.

### Membership

Membership is open to technical experts, implementors, and representatives from standards bodies or organizations building solutions on top of UNTP.
Potential implementors (solution providers, digital wallet developers, verifiable credential platforms, supply chain IT providers) are encouraged to participate actively.

### Roles and Responsibilities

- Technical Working Group Lead (Chair):
  - Oversees group activities and progress.
  - Chairs fortnightly meetings.
  - Ensures issues are created, addressed, and closed.
  - Coordinates reference implementation delivery.
  - Guides the group toward achieving quality suitable for UNTP 1.0.
- Group Members:
  - Contribute specifications, code, and technical feedback.
  - Participate in reviews and testing.
  - Propose and maintain verification rules.
- Observers:
  - Attend meetings, access documentation, and provide feedback.
  - Must become registered experts to contribute formally.

### Working Methods

- Meetings: Held fortnightly to review GitLab issues, approve merge requests, and track progress.
- Collaboration: All work is conducted openly via GitLab repositories and mailing lists, with decisions made by consensus where possible.
- Quality Targets: Drafts and contributions should progress toward production-grade reference implementations, capable of real-world adoption.

### Deliverables

- Maintained specifications for IDR, DAC, and VCP.
- Open-source reference implementations (including a reference site).
- Test suites and validation frameworks.
- A library of formalised verification rules.
- Guidance and documentation to support implementors.

### Governance & Reporting

The TWG reports into the UNTP Steering Group and collaborates closely with other working groups to ensure alignment. Decisions are made by consensus where possible, or by majority vote when consensus cannot be achieved.

### Review

This ToR will be reviewed annually, or earlier if significant scope or responsibility changes occur.

## Mailing List

A group mailing list is maintained and can be used by any list member to post messages to the group. The list also maintains an archive of all messages sent to the group.

- To [join the mailing list](https://gaggle.email/join/untp-technical@gaggle.email) - your request will be reviewed by a list administrator.

## Meetings

:::warning Meetings Postponed
**Technical Group meetings are currently postponed** while the UNTP is in public review.

Meetings are expected to resume after **10 July 2026**. A new schedule will be published here once confirmed. In the meantime, please follow updates via the [mailing list](#mailing-list).
:::

<!-- Previously fortnightly Thursday 9am UTC meetings. Details retained for reference once meetings resume:
- **Thursday 9am UTC meetings**. Every 2 weeks.
  - [ICS Calendar File](/meetings/technical-working-group/option-b.ics). Download and double click to add the meetings to your calendar.
  - [Join the meeting](https://meet.google.com/hur-sobw-dmq). Click to join the meeting without a calendar entry.
-->

Each meeting will generally work through open [issues](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/?sort=created_date&state=opened&label_name%5B%5D=WG-Technical) and [merge requests](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/merge_requests).

Previous meeting dates, recordings, transcripts, and minutes are summarised below with the most recent meeting at the top.

## Previous Meetings

| Meeting    | Summary                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 2026-06-04 | [The UNTP Technical WG discussed the current state of testing for solution providers, including point-in-time validation during development and approaches to continuously monitor conformance.](/meetings/technical-working-group/2026-06-04-testing-discussion.pdf)                                                                                                                                                                           |
| 2026-04-16 | [The working group closed several pending and outdated issues — including topics around eIDAS/VCDM alignment, product identifier persistence, and DPP data variants.](/meetings/technical-working-group/2026-04-16.pdf)                                                                                                                                                                                                                           |
| 2026-03-20 | [The UNTP Technical WG discussed linked data graph verification, and preventing user tracking in credential render methods.](/meetings/technical-working-group/2026-03-20.pdf)                                                                                                                                                                                                                                                                    |
| 2026-03-05 | [Covered progress on IANA link relation type registrations, W3C Verifiable Credentials Working Group charter updates, and several GitLab issues related to the product class data model. Key decisions included making the `registeredID` attribute optional, handling industry-specific mandatory attributes via sector-published profiles, and clarifying redundancies in the `claim` class.](/meetings/technical-working-group/2026-03-05.pdf) |
| 2026-02-19 | [The UNTP Technical WG discussed various open issues and merge requests around data carriers, link types, and more.](/meetings/technical-working-group/2026-02-19.pdf)                                                                                                                                                                                                                                                                            |
| 2026-02-10 | [The UNTP Technical WG discussed post-sale data addition, DPP variants, and other needs for data discoverability.](/meetings/technical-working-group/2026-02-10.pdf)                                                                                                                                                                                                                                                                              |
| 2026-01-22 | [The UNTP Technical WG discussed methods of adding product information (like a battery repair event) post sale after the initial Digital Product Passport has been created.](/meetings/technical-working-group/2026-01-22.pdf)                                                                                                                                                                                                                    |
| 2026-01-08 | [The UNTP Technical WG discussed methods of selective disclosure to meet Supply Chain working group use cases.](/meetings/technical-working-group/2026-01-08.pdf)                                                                                                                                                                                                                                                                                 |
| 2025-12-11 | [The UNTP Technical WG discussed challenging requirements needed for DAC to meet Supply Chain working group use cases.](/meetings/technical-working-group/2025-12-11.pdf)                                                                                                                                                                                                                                                                         |
| 2025-11-27 | [The UNTP Technical WG discussed open Merge Requests and discussed Decentralized Access Control, and how to meet the needs of other working groups.](/meetings/technical-working-group/2025-11-27.pdf)                                                                                                                                                                                                                                            |
| 2025-11-18 | [The UNTP Technical WG discussed errors in the Identity Resolver page. Discussion of VC standards.](/meetings/technical-working-group/2025-11-18.pdf)                                                                                                                                                                                                                                                                                             |
| 2025-10-30 | [The UNTP Technical WG discussed the Identity Resolver page restructure, focusing on harmonization with various DID methods. Review of the proposed DID Methods page.](/meetings/technical-working-group/2025-10-30.pdf)                                                                                                                                                                                                                          |
| 2025-10-02 | [The UNTP Technical WG discussed the role of Identity Resolver in making data discoverable across a supply chain, what it's role is, and other ways of discovering link data via Digital Product Passport.](/meetings/technical-working-group/2025-10-02.pdf)                                                                                                                                                                                     |
| 2025-09-18 | [The UNTP Technical WG discussed assignment of open tickets to working group members, outreach to additional individuals to join the working group, and the need for better component diagrams.](/meetings/technical-working-group/2025-09-18.pdf)                                                                                                                                                                                                |
| 2025-09-05 | [The UNTP Technical WG discussed UNTP and AATP implementation, tackling decentralized access control, standard alignment, and user onboarding, aiming for a version 7 spec by year-end.](/meetings/technical-working-group/2025-09-04.pdf)                                                                                                                                                                                                        |

---

## Sectoral Collaboration Fora

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

This page describes how UNTP enables top-down collaboration between communities that implement UNTP extensions. Where [implementation governance](implementation-governance.md) is fundamentally a bottom-up process — individual implementations earn registration by passing tests and providing evidence — sectoral collaboration is the complementary top-down process focused on **harmonisation, re-use, and the sharing of lessons** across multiple communities working in the same sector or jurisdiction.

## Why Sectoral Collaboration

UNTP's interoperability tests guarantee that any registered implementation can technically exchange data with any other. But technical interoperability is necessary, not sufficient. A copper miner in Zambia, a refinery in Japan, and a battery manufacturer in Germany may all implement UNTP correctly and still find their credentials hard to compare if each follows a different national or industry extension that defines its own carbon footprint metric, its own facility classification, or its own conformity scheme reference.

The risk is fragmentation: every regulator and every industry community independently developing its own UNTP extension, each technically conformant but semantically divergent. The cost of this fragmentation falls on the actors that operate across multiple jurisdictions and sectors — typically the smaller suppliers and producers that can least afford it.

Sectoral collaboration addresses this risk by creating venues where extension developers and implementers within a sector can:

* **Discover** existing extensions and registered implementations in their sector before starting new work.
* **Re-use** schemas, vocabularies, criteria, and test cases from prior work rather than reinventing them.
* **Harmonise** sector-specific terms, metrics, and conformity references so that credentials from different communities mean the same thing.
* **Share** lessons, best practices, and pilot results from real-world deployments.
* **Coordinate** with regulators, standards bodies, and industry associations operating in the same domain.

The fundamental premise is that **interoperability is achieved at the technical layer through testing, but harmonisation is achieved at the semantic and organisational layers through collaboration**. Both are necessary for UNTP to scale.

## How Sectoral Fora Work

All sectoral fora are run by the UN under the same governance framework as UNTP itself, ensuring neutrality, openness, and consistent process across sectors. There are currently two active fora — Critical Minerals, Energy Transition (CMET) and Textiles — with a third forum for Agri-food coming soon. Additional fora (for example construction) will be established as evidence of demand emerges from industry communities.

Each forum is open to any organisation working on UNTP extensions or implementations within that sector — including extension owners (registered in the EXT register), conformity scheme owners (CVC register), software providers (SWI register), identifier scheme operators (IDR register), regulators, and producers.

A mature sectoral forum will typically:

* Maintain a public website that aggregates information about registered extensions, implementations, and related initiatives in the sector.
* Publish a sector-specific harmonisation roadmap identifying priority areas for re-use and convergence.
* Curate a library of shared vocabularies, schemas, and criterion definitions that are common across multiple extensions in the sector.
* Run regular workshops and meetings where extension developers and implementers can share progress and lessons.
* Liaise with the [UNTP Technical Working Group](meetings/technicalGroup.md) to feed back sector-specific lessons that should influence UNTP core.
* Coordinate with international standards bodies and regulators active in the sector.

Registered extension owners are encouraged to nominate at least one member as a participant in the relevant sectoral forum, and at least one member as a participant in the UNTP [Technical Working Group](meetings/technicalGroup.md). This two-way flow ensures that lessons from a specific sector inform UNTP core, and that UNTP core changes reach the sectoral communities.

## Active Sectoral Fora

 Forum | Status |
|---|---|
| [Critical Minerals & Energy Transition ](https://un.opensource.unicc.org/unece/uncefact/spec-uncrmtp/) | Active |
| [Textiles and Leather](https://un.opensource.unicc.org/unece/uncefact/spec-unttp/) | Active |
| Agriculture & Food | Coming soon |
| Other sectors (e.g. construction) | To be established when industry demand emerges |

**Note on current state:** these fora are presently focused on developing their own UN UNTP extension specifications — that is, each forum is itself the host of a single specification rather than a collaboration platform across many. They will transition over time into broader collaboration platforms that coordinate between multiple extension specification owners within each sector — for example, aligning the various national and regional critical minerals traceability initiatives that each maintain their own UNTP extension.

This transition reflects the natural evolution of standards communities: an initial phase where a small group develops a foundational specification, followed by a maturity phase where the focus shifts to coordinating an ecosystem of derived and parallel implementations.

## Relationship to Implementation Governance

Sectoral collaboration and implementation governance are complementary rather than competing processes:

| Dimension | [Implementation Governance](implementation-governance.md) | Sectoral Collaboration |
|---|---|---|
| **Direction** | Bottom-up | Top-down |
| **Focus** | Interoperability and conformance | Harmonisation and re-use |
| **Mechanism** | Testing, evidence, registration | Discovery, sharing, coordination |
| **Audience** | Individual implementers (software, scheme owners, CABs, registers, extensions) | Communities of implementers within a sector |
| **Output** | Registered, tested, conformant implementations | Shared vocabularies, harmonisation roadmaps, sector lessons |
| **Authority** | UNTP registrar agent applies objective tests on every observation cycle | Sectoral fora drive consensus by influence and reputation |

A community extension developer therefore has two responsibilities. The first is bottom-up: publish a DID, issue a registration VC, and let the EXT registrar agent verify the extension's schema, context, and vocabulary on each observation cycle (see the [Extensions register](../implementations/ext/) and [registration guide](../implementations/ext/registration-guide.md)). The second is top-down: engage with the relevant sectoral forum to discover prior work, harmonise where possible, and contribute lessons back to the community.

## Getting Involved

If you are developing or implementing a UNTP extension and would like to participate in sectoral collaboration:

1. Identify the relevant sectoral forum from the [active fora list](#active-sectoral-fora).
2. Contact the forum lead via the linked website or the [UNTP general updates meeting](meetings/generalUpdates.md).
3. Share your extension or implementation plans with the forum so others can discover them.
4. Look for opportunities to re-use existing work and to contribute your own work for re-use.
5. Nominate a representative to the UNTP [Technical Working Group](meetings/technicalGroup.md) to feed lessons back into UNTP core.

If your sector does not yet have an active forum, contact the UNTP steering group via the [general updates meeting](meetings/generalUpdates.md) to discuss establishing one.

---

## UNTP Core Specification

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

This page describes how the UNTP specification is developed, maintained, and versioned as a UN standard.

## UN/CEFACT Framework

[UN/CEFACT](https://unece.org/trade/uncefact) is the United Nations Centre for Trade Facilitation and Electronic Business, established as an intergovernmental body in 1996 with a mandate to develop standards and recommendations for the facilitation of digitalised and sustainable trade. Although UN/CEFACT is a global body, secretariat functions are provided by the United Nations Economic Commission for Europe [(UNECE)](https://unece.org/). The UN/CEFACT mandate, terms of reference, program of work, and related governance documentation is available from the UN/CEFACT [policies and procedures](https://unece.org/trade/uncefact/policiesprocedures-and-termsreference). The governance documents are approved by member states at the UN/CEFACT annual plenary.

Standards such as this United Nations Transparency Protocol (UNTP) and recommendations such as Recommendation 49 "Transparency at scale" are developed under the UN/CEFACT Open Development Process [(ODP)](https://unece.org/trade/documents/2023/12/session-documents/open-development-process). UN/CEFACT maintains formal liaison arrangements with other UN organisations as well as other global standards bodies such as ISO, ITU, and IEC following a [memorandum of understanding](https://digitallibrary.un.org/record/465895?ln=en&v=pdf).

Like all UN/CEFACT standards, the UNTP is a voluntary standard that is not mandated by any regulatory framework. Uptake and implementation will be the result of perceived business value. For this reason, UNTP includes business case templates for [industry](../business-case/BusinessCaseIndustry.md) and [government](../business-case/BusinessCaseGovernment.md) to assist implementers with their cost/benefit assessments, and an [Impact Assessment Framework](../business-case/ImpactAssessmentFramework.md) that will collect performance metrics from implementers to track UNTP impact on UN Sustainable Development Goals.

## Working Groups

UNTP development and maintenance work is coordinated through a steering group, four specialist working groups, and a general update series. See the [meetings page](meetings/index.md) for terms of reference, schedules, and meeting notes for each group.

| Group | Scope |
|---|---|
| [Steering Group](meetings/steeringGroup.md) | Overall coordination, consistency across groups, liaison with other DPP initiatives |
| [Adoption Working Group](meetings/adoptionGroup.md) | Business case, implementation guidance, promotion of new implementation commitments |
| [Supply Chain Working Group](meetings/supplyChainGroup.md) | DPP, DFR, and DTE specifications |
| [Conformity Working Group](meetings/conformityGroup.md) | DCC and CVC specifications |
| [Technical Working Group](meetings/technicalGroup.md) | VCP, DAC, and IDR specifications, reference implementations, test suites. The conformance tests authored by this group are the source of truth for the checks the UNTP registrar agent runs continuously against the four [implementation registers](implementation-governance.md). |
| [General Updates](meetings/generalUpdates.md) | Monthly open meetings for observers and the broader community |

In addition to these working groups, **register operations** is a UNECE secretariat function (not a working group) responsible for running the UNTP registrar agent (`did:web:registrar.uncefact.org`), maintaining the four [implementation registers](implementation-governance.md), issuing Digital Identity Anchor credentials about registered implementers, and mediating disputes about conformance observations.

## Participation

Participation in UNTP is open to all. There are two levels of participation.

* **Observers** — anyone interested to be kept informed and to ask questions may simply subscribe to the UNTP mailing list and slack channel and may join the monthly update meetings.
* **Contributors** — anyone interested to volunteer their time and knowledge to improve the UNTP specifications. All contributing participants in UN/CEFACT working groups must [register as UN experts](https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration) with the approval of their country head of delegation. All contributing participants must waive their intellectual property rights (IPR) to any contributions under the [IPR policy](https://unece.org/trade/documents/2010/12/session-documents/intellectual-property-rights-policy) so that UN/CEFACT can continue to publish freely usable standards and recommendations.

All meetings are open and minutes are public. All issues and changes are public and auditable. All work-in-progress and versioned outputs are public and can be freely re-used without limitation.

## Change Management

UNTP follows a consensus-driven change management process hosted on the UN GitLab instance. The process is designed for maximum transparency and auditability.

1. **Issue** — a contributing member [raises an issue](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues) describing a proposed change, correction, or new feature. Any member can comment and discuss.
2. **Merge request** — once sufficient discussion has occurred, the contributor lodges a formal merge request with the proposed changes. All merge requests require at least one reviewer to approve.
3. **Working group review** — approved merge requests are discussed at the relevant working group's fortnightly meeting. Changes are merged if there are no objections.
4. **Consensus or vote** — if objections cannot be resolved by consensus, the meeting chair holds a vote. A simple majority is required.
5. **Publication** — merged changes are automatically published to the UNTP website via GitLab Pages.

All [issues](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues) and [merge requests](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/merge_requests?scope=all&state=all) remain publicly visible for scrutiny. For detailed guidance on using the GitLab tools, see [Using GitLab](usingGitlab.md).

## Version Management

All UNTP artefacts are rigorously versioned following [semver](https://semver.org/) best practices.

* Version numbers are indicated as a dot-separated triple `{major}.{minor}.{patch}`. For example version 2.3.4.
* `{patch}` version number increments indicate non-breaking bug fixes that do not add new capabilities or features. For example, implementers should see no difference between version 1.4.5 and version 1.4.6.
* `{minor}` version number increments indicate non-breaking enhancements. For example, implementations of version 1.4.5 are still compatible with version 1.5.0 but may not take advantage of new features.
* `{major}` version number increments indicate significant and breaking releases. For example implementations of version 1.5.0 will be incompatible with version 2.0.0 and may fail in unpredictable ways.

Note that 0.x.y versions do not strictly follow semver and may include breaking changes in minor versions. However all versions after 1.0.0 first formal release will strictly observe this versioning process.

All versioned artefacts are accessible from the relevant [specification](../specification/index.md) page.

---

## Using GitLab

import Disclaimer from '../\_disclaimer.mdx';
import YouTube from '@site/components/YouTube';

<Disclaimer />

## UNTP Consensus Driven Development Process

UNTP development follows an agile and iterative approach with maximum public visibility and seeks consensus for each change. We use a UN hosted GitLab instance as our main platform for hosting and collaborating on the UNTP Specification. GitLab is powered by Git, a version control system that tracks changes to files (like specifications) over time, allowing multiple people to work together. 

- Anyone can participate as an observer simply by watching development on this UNTP website and by joining the informal chat channel.
- Anyone can formally join the UNTP working group as a contributing member once they have completed the UN/CEFACT [expert registration process](https://uncefact.unece.org/display/uncefactpublic/UNCEFACT+Expert+Registration) which includes formal acceptance of [IPR policy](https://unece.org/trade/documents/2010/12/session-documents/intellectual-property-rights-policy).
- Contributing members who wish to propose changes to existing content or contribute new content should [raise a new issue](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues) using the GitHub issue workflow - that describes the change. Any other contributing member can comment on the issue. In this way, the issue can be used as a permanent record of working group discussion around the specific issue. Some issues like this one on [identifiers](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/137) can be long running whilst others like this one on [context file versions](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues/149) can be short and quick to resolve.
- Once the creator of the issue is confident that there has been sufficient exposure and discussion, then a formal request to change content should be lodged - using the GitHub pull request workflow. All pull requests require at least one reviewer to approve the proposed changes and all approved pull requests are discussed at fortnightly meetings. If there are no objections then the changes are merged into the main website. All merge requests [remain visible](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/merge_requests?scope=all&state=all) for public scrutiny.
- If there are objections then they are discussed and, hopefully, resolved with full consensus. In the rare case of objections that cannot be resolved by consensus then meeting chair will hold a vote. A simple majority is required to accept the change.
- All meetings are recorded, transcribed, summarised, and published to the [UNTP meetings](meetings/steeringGroup.md) page.
- A google group mailing list is also maintained and can be used by any observer or contributing member. All group emails are archived and searchable.

For participants less familiar with GitHub tools and processes, there is a "using GitHub" guidance page in this section that describes how to write content and how to request changes via the pull request workflow.

## Gitlab Workflow

This setup ensures a collaborative workflow: 

```mermaid
flowchart LR
    A[Raise Issue] --> B[Edit Files]
    B --> C[Create Merge Request]
    C --> D[Review & Approval]
    D --> E[Merge to Main]
    E --> F[Website Updates Automatically]
```

### Issues
Issues (tickets) are raised to discuss ideas, collaboration and consensus are achieved through comments and discussions.

### Merge Requests
Peer review occurs via merge requests (MRs), and approved changes are incorporated into the specification before going live on the UNTP website. 

No advanced technical knowledge is needed to make contribution to the specification, we'll guide you through the web-based tools.

## Registration Process
If you don't have a UN GitLab account yet, self-service registration is available.

1. **Register**: Go to the registration page [here](https://opensource.unicc.org/users/sign_up) and create an account.

2. **Approval**: [UNICC](https://www.unicc.org/) will review and approve your registration. Allow at least **three business days**.

3. **Activate**: You'll receive an email with an activation link. Click it promptly (links expire). If it expires, enter your email on the activation page and click "Resend" to get a new one.

4. **Two-Factor Authentication (2FA)**: Once activated, set up 2FA [here](https://opensource.unicc.org/-/profile/account) (it's mandatory).

5. **Access the Repository**: Navigate to the **spec-untp** repository [here](https://opensource.unicc.org/un/unece/uncefact/spec-untp). Your initial GitLab role lets you raise issues, comment on issues and merge requests, but not edit files directly.

**To Contribute Edits**: We encourage active contributions to the specification! Contact the appropriate Working Group (WG) lead to request edit access. Please only request edit access if you plan to contribute regularly.

:::info
- If no approval after three days, email UNICC support at email.example.com (TODO: Add support email).
- All contributions (comments, issues, or edits) become UN intellectual property as outlined in the Intellectual Property Rights (IPR) Agreement (TODO: Add link to agreement when available).
- For other issues, use the UNTP Slack channel [here](https://join.slack.com/t/uncefact/shared_invite/zt-43hn3irv4-jIynpESUeYaF9zIgqB~djA) or mailing list [here](https://gaggle.email/join/untp@gaggle.email).
:::

## Markdown
All content on the UNTP website is written [using the Markdown notation](https://handbook.gitlab.com/docs/markdown-guide/). If unfamiliar with markdown, we suggest you experiment with it on a [markdown playground](https://kip2.github.io/MarkdownToHTML/) so that you understand how to create headings, bulleted lists, tables, and so on.

## Getting Started
The following instructions assume you have access to the UN's GitLab instance and are logged in. If you need help logging in or permissions, reachout to the appropriate working group lead.

## How to find the repository

<YouTube id="GcuZz1yYO0Q" />

1. Go to your GitLab homepage (the main dashboard after [signing in](https://opensource.unicc.org/users/sign_in)).

2. Click on "Projects" in the left menu.

3. Click "Explore projects" on the top right of the screen.

4. Click the "All" tab.

5. Search for "spec-untp" or browse the [groups/projects](https://opensource.unicc.org/explore/projects).

6. Click on UNCEFACT's **spec-untp** repository to open it.

## How to Raise an Issue
Issues are like tickets for discussing problems, ideas, or tasks related to the specification. Use them to raise issues or collaborate on ideas before making changes.

<YouTube id="tUBFTqnMT1s" />

1. In the [spec-untp repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), click on "Issues" in the left menu. Note that you may need to open the menu on mobile devices by clicking the menu icon on the top left of the page.

2. Click the blue "New issue" button at the top right.

3. Add a short, clear title (e.g., "Update section on user requirements").

4. Select the **General_Issue** template from the dropdown below the **Description** section (it auto-fills a basic structure).

5. Fill in the description:
   - **Impacted Sections**: List the sections of the specification webiste that is impacted (e.g. https://untp.unece.org/docs/specification/DigitalProductPassport).
   - **Description**: Explain the details. Use markdown, simple text, or add images if needed (click the paperclip icon to attach files).
   - **Assignee** (optional): Pick someone to handle it.
   - **Labels** (required): Add **one** appropriate WG label based on the topic: 
     - **WG-Adoption** for adoption/implementation
     - **WG-Conformity** for conformity/compliance
     - **WG-Steering** for steering/high-level
     - **WG-SupplyChain** for supply chain
     - **WG-Technical** for technical details

6. Click "Create issue" at the bottom.

Your issue is now live, and others can see it in the [Issues list](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/issues).

## How to Comment on an Issue
Comments let you discuss or add more info to an existing issue.

<YouTube id="z28tPtGAuQs" />

1. In the [spec-untp repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), click on "Issues" in the left menu. Note that you may need to open the menu on mobile devices by clicking the menu icon on the top left of the page.

2. Find the issue in the list (use search if needed) and click on it to open.

3. Scroll to the bottom of the page.

4. In the comment box, type your message. Use markdown, simple text, or add images if needed (click the paperclip icon to attach files).

5. Click "Comment" to post it.

Everyone participating in the issue will get notified.

## How to Make Changes Within the Repository
**Overall Flow for Making Changes**:
1. (Optional but recommended) Raise an issue first to discuss your idea and get feedback.

2. Edit the file(s) using the tools below. This creates a copy of your changes in a "branch" (like a draft).

3. Raise a merge request (MR) to propose your changes for review.

4. The community reviews, approves, and merges. Changes go live on the website.

**Important Tip**: When making changes, keep them focused on **one concept or topic** (e.g., updating a specific section or fixing related typos). Don't lump multiple unrelated changes into a single merge request. Create separate ones for easier review and collaboration.

For non-tech users, use GitLab's built-in tools to edit files directly in your browser. This doesn't require downloading anything.

### Simple Single File Edits
Use this for quick changes to one file, like fixing a typo or updating a section.

<YouTube id="7OHIhunjWXU" />

1. In the [spec-untp repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), click on "Repository" in the left menu to see the file list. Note that you may need to open the menu on mobile devices by clicking the menu icon on the top left of the page.

2. Navigate to the file you want to change (the specification files live in the [website/docs directory](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/tree/main/website/docs)).

3. Click on the file name to view it.

4. Click the blue "Edit" button at the top right and then click the "Edit single file" option.

5. Make your changes in the editor:
   - It's like editing a document. Type or paste text.
   - Use Markdown where it makes sense like # for headings or - for bullets.

6. Click the "Preview" button on the top left of the page to review your changes. Click the "Write" button on the top left of the page to make additional changes.

7. At the bottom:
   - Add a short "Commit message" describing the change (e.g., "Fixed typo in section 2").
   - **Must select**: "Start a new merge request with these changes" (this proposes your edit for review).

8. Click "Commit changes."

This will automatically create a draft merge request. Follow the [How to Raise a Merge Request](#how-to-raise-a-merge-request) section to finalise it.

### Multiple File Edits (via Web IDE)
Use this for changes across several files, like updating related sections in different files. The Web Integrated Development Environment (IDE) is a online code editor.

<YouTube id="7Hu7Xi-uNr8" />

1. In the [spec-untp repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), click the **Edit** button on the top right and select **Web IDE**. This opens GitLab’s Web IDE.

2. In the Web IDE:

   * Use the **left-hand file tree** to navigate to the specification files, which are located in the `website/docs` directory.
   * Expand folders by clicking the folders name.

3. Open and edit the files you need:

   * Click a file to open it in the editor panel.
   * Make your changes directly in the editor (type or paste).
   * Use Markdown formatting if needed (`#` for headings, `-` for bullets, etc.).

4. When you are done editing:

   * Click the **Source Control** icon in the left panel.
   * Review your changes in the list.
   * In the **Commit message** box, write a short description of the overall change (e.g., *“Updated supply chain examples across docs”*).
   * Click the dropdown arrow next to the **Commit and push to 'main'** and select **Create a new branch and commit**, and enter a simple branch name (e.g., `update-supply-chain`).
   * Press the 'return' or 'enter' key on your keyboard. This saves your work on the new branch.

5. After committing:

   * A popup will appear — click **Create MR** directly from there.
   * Alternatively, you can return to the repository page and GitLab will prompt you to open a merge request from your new branch.

6. Follow the [How to Raise a Merge Request](#how-to-raise-a-merge-request) instructions to finish creating and submitting the MR for review.

:::caution
You must commit your changes for them to be saved in the web-based IDE. You will lose your work if you don't commit the changes and close the window. A warning will be displayed if you attempt to close the window with uncommitted changes.
:::

:::info
If uploading and commiting large files it may take some time for the popup to appear. Please be patient.
:::

## How to Raise a Merge Request
A merge request (MR) is like proposing changes for review before they're added to the UNTP Specification Website. It's required for all changes.

<YouTube id="1Y6zftzmUbg" />

1. In the [spec-untp repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), click on "Merge requests" in the left menu. Note that you may need to open the menu on mobile devices by clicking the menu icon on the top left of the page.

2. Click the blue "New merge request" button.

3. Select the source branch (the branch you've committed your changes to) and target branch (**should be "main"**).

4. Click "Compare branches and continue."

5. Fill in the form:
   - **Title**: Short description (e.g., "Add new feature spec").
   - **Description**: Explain what you changed and why. Mention related issues if any (e.g., Closes #123). Attach files or link to issues if needed.
   - **Assignee** (optional): Pick someone to review it.
   - **Labels** (required): Add **one** appropriate WG label based on the topic:
      - **Labels** (required): Add **one** appropriate WG label based on the topic: 
      - **WG-Adoption** for adoption/implementation
      - **WG-Conformity** for conformity/compliance
      - **WG-Steering** for steering/high-level
      - **WG-SupplyChain** for supply chain
      - **WG-Technical** for technical details

6. Click the "Changes" tab at the bottom of the page to review the changes made.

7. Click "Create merge request."

Your merge request is now live, and others can see it in the [Merge Requests list](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/merge_requests).

:::info
After Creating the MR:
- The pipeline automatically runs to check if the website builds correctly.
- A WG lead must approve the MR before it can be merged.
- Once approved, anyone with permission can merge it.
- Another pipeline will automatically publish the updates to the spec-untp website via GitLab Pages.
:::

## How to Comment on a Merge Request
Comments help discuss proposed changes.

### General Comment

<YouTube id="2tq8OKYhuSs" />

1. In the [spec-untp repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), click on **Merge requests** in the left menu. On mobile devices, you may need to open the menu by clicking the menu icon in the top left corner.

2. Find the merge request in the list (use search or filters if needed) and click to open it.

3. Scroll to the bottom of the page and use the comment box. Type your feedback, then click **Comment**.

### Comment on a Specific Line

<YouTube id="6AhJtVR9LRM" />

1. Open the merge request and go to the **Changes** tab.

2. Hover over the line of changed text you want to comment on.

3. Click the **speech bubble icon** that appears.

4. Type your feedback, then click **Add comment now**.

## More Complex Changes

For more advanced workflows like running the website locally or making extensive changes, you'll need to clone the repository to your local machine using Git. This requires:

1. Installing Git on your computer
2. Cloning the spec-untp repository
3. Making changes locally and pushing them back to GitLab

This is recommended for contributors who need to:
- Test changes locally before submitting
- Work with multiple files extensively
- Run the documentation website on their own machine

## Running a local UNTP website

The UNTP website is built using [Docusaurus 3](https://docusaurus.io/), a modern static website generator.

> _Note: You can copy code snippets below and paste them to your terminal_

To run it locally:

1. if you don't already have node.js and NPM installed then install them using the [Node Installer](https://nodejs.org/en/download/prebuilt-installer) - select the "prebuilt installer" and chose the right options for your mac or pc.
2. Open your command line / terminal window. On Mac you'll find it in `Applications`->`Utilities`->`Terminal`.
3. Find the GitHub folder that has the cloned UNTP repository you created as described in the [more complex changes](#more-complex-changes) section. Hint `ls` command will list the files in the current folder and `cd someFolder` will move you to that folder. `cd ..` will move you back up a folder level. Use `ls` and `cd` till you are in the `website` folder of the UNTP repository.

```
cd ~/GitHub/spec-untp/website/
```

4. If you don't already have Yarn installed then type `npm install --global yarn`. Yarn is a dependency manager that will keep all your local bits and pieces of website software up to date.

```
npm install --global yarn
```

5. Type `yarn install --frozen-lockfile` to install the dependencies needed for the website (which includes docusaurus).

```
yarn install --frozen-lockfile
```

6. Type `yarn start`. This will launch the website and open it in a browser window on your local machine at `http://localhost:3000`. Whenever you make changes to UNTP Markdown files, you'll see the change on your local website.

```
yarn start
```

7. To stop the website, enter "Ctrl+C" in the terminal window. You can start it again anytime by navigating to the `website` folder as described above and typing `yarn start`. You don't need to re-install node or yarn or docusaurus.

---

## Registry Governance

# UNTP Conformity Vocabulary Catalogue Register — Governance

This document describes how the UNTP Conformity Vocabulary Catalogue (CVC) Register is governed: its purpose, how the registrar agent maintains it, the trust model, retention and dispute policy, and how the register relates to the other UNTP registers.

If you are a **conformity scheme owner** looking for step-by-step instructions to register your scheme, see the [Registration Guide](./registration-guide.md).

If you are an **implementer or verifier** looking up registered schemes, see the [register itself](./).

## Purpose

The CVC Register is the **single global entry point for the federation of conformity schemes** that publish UNTP-conformant vocabularies. It answers two questions:

1. **For an implementer or CAB:** "Which conformity schemes can I reference in my UNTP credentials, and where is each scheme's machine-readable vocabulary?"
2. **For a verifier or regulator:** "Given a profile URI in a DCC's `attestation.assessmentScheme`, what scheme is this, who owns it, what topics does the profile cover, and which regulations or standards is it aligned with?"

The register does not duplicate scheme content — every scheme keeps its canonical vocabulary on its own infrastructure. The register catalogues *the existence* of registered schemes, the URL of each scheme's published vocabulary, and (after agent crawl) per-profile summary metadata: topic classifications, standard/regulatory alignments, validity dates, and criterion counts.

## How authority is shared

Authority over the register comes from two parties working together:

- **Scheme owners** publish a CVC vocabulary at a stable URL on a domain they control, and sign a registration Verifiable Credential committing to maintain it.
- **UNECE** (the registrar) periodically crawls each scheme's vocabulary, validates it against the UNTP CVC schema, hashes the published documents, indexes the per-profile metadata, and writes signed observations back to the register.

Neither party can act unilaterally. Owners publish; the registrar indexes. The register is a record of what scheme owners have published *and* what an independent agent has been able to confirm.

This federated, pull-based design is deliberate. It gives drift detection (hashing what we fetched lets verifiers detect silent post-registration changes), cryptographic trust (entries derive from owner-signed VCs that anyone can independently verify), and avoids bottlenecks (owners publish on their own schedule).

## Roles

| Role | Identity | Responsibilities |
|---|---|---|
| **Registrar** | UNECE | Owns the register; defines policy; seeds scheme entries; operates the registrar agent; mediates disputes. |
| **Registrar Agent** | `did:webvh:untp.unece.org` | Fetches each scheme's registration VC, verifies its signature, crawls the registered `vocabularyURL`, validates each profile and version against the UNTP CVC schema, hashes the published documents, extracts per-version metadata (topics, alignments, validity, criterion count), and signs observations. |
| **Scheme Owner** | Owner DID (e.g. `did:web:owner.example`) | Publishes and maintains the scheme. See the [Registration Guide](./registration-guide.md) for the full owner-facing process. |
| **Endorsing Authority** | (e.g. an accreditation body, a regulator, an intergovernmental body) | Optionally provides external endorsement of a scheme that the owner references in their registration VC. The registrar does not verify endorsements directly, but records them for verifier inspection. |
| **Conformity Assessment Body (CAB)** | CAB DID | Issues UNTP Digital Conformity Credentials that reference registered `profileVersionId` URIs. Not part of CVC governance. |
| **Implementer / Verifier / Regulator** | n/a | Consumes registered scheme metadata to interpret claims and assessments in DPPs, DFRs, and DCCs. |

## What the agent verifies

These are the checks the registrar agent runs on every crawl cycle. The full scheme-owner-facing perspective on these checks (and how to satisfy them) is in the [Registration Guide](./registration-guide.md#what-gets-verified). This table is the technical reference for the registry system.

| Check | What it verifies |
|---|---|
| **Registration VC signature valid** | The registration VC verifies against the owner DID's current verification methods. |
| **vocabularyURL resolves** | The URL returns content. |
| **CVC schema conformant** | The published vocabulary validates against `ConformityScheme.json` v0.7.0. |
| **Schema hash recorded** | The fetched vocabulary's content hash is captured for drift detection. |
| **Profile URIs stable and dereferenceable** | Each profile's URI returns content; same for each profile version. |
| **Versioned URIs are immutable** | The hash of a previously-seen profile version URI hasn't changed. |
| **Topic URIs resolve** | Every topic referenced by a profile or criterion resolves into the published `vocabulary.uncefact.org/conformity-topics/` SKOS scheme. |
| **Standard / regulation references resolve** | Where declared, the URIs in `standardAlignments` and `regulatoryAlignments` are reachable. |
| **Endorsement evidence resolves** | Where declared, endorsement evidence URLs are reachable. |

A small failure (e.g. one broken evidence link) yields `partially-conformant`. A fatal failure (signature, schema, profile URI not resolving) yields `non-conformant`. The agent always records *which* checks failed.

## Identity, Document, and Credential Relationships

```mermaid
flowchart LR
  subgraph Owner["Scheme Owner"]
    OwnerDID["Owner DIDdid:web:owner.example"]
    OwnerKey[("OwnerSigning Key")]
    RegVC["Registration VCcredentialSubject = ConformityVocabularyCatalogueEntry"]
    SchemeDoc["Scheme Vocabularyat vocabularyURL"]
    Profile1["Profileexample-profile"]
    ProfileV1["Profile Versionvap-full/8.0.2"]
    Criterion["Criteria (versioned)"]
  end

  subgraph Topics["UNTP Conformity Topics(borrowed)"]
    TopicScheme["vocabulary.uncefact.org/conformity-topics/(SKOS scheme)"]
    TopicConcept["topics:human-equity-and-welfaretopics:health-and-safety..."]
  end

  subgraph External["External References"]
    Standard["OECD Guidelines(voluntary standard)"]
    Regulation["EU Battery Reg(national/intl. regulation)"]
    Endorsement["Endorsing Authority(e.g. OECD, accreditation body)"]
  end

  subgraph Registrar["UNECE Registrar"]
    AgentDID["Registrar Agent DIDdid:webvh:untp.unece.org"]
    AgentKey[("AgentSigning Key")]
    Observation["Conformance Observation VC"]
    CvcRegister[("CVC Registerregister.json")]
  end

  subgraph Consumers["Downstream Consumers"]
    DCC["Digital Conformity Credentialattestation.assessmentScheme= profileVersionId"]
    DPP["DPP / DFRclaim.conformityScheme= profileVersionId"]
  end

  OwnerKey -. controls .-> OwnerDID
  AgentKey -. controls .-> AgentDID

  OwnerDID -- signs --> RegVC
  RegVC -- references --> SchemeDoc
  SchemeDoc -- contains --> Profile1
  Profile1 -- composes versioned --> ProfileV1
  ProfileV1 -- composes versioned --> Criterion

  ProfileV1 -- classifies via --> TopicConcept
  Criterion -- classifies via --> TopicConcept
  TopicConcept -- in scheme --> TopicScheme

  ProfileV1 -- aligns to --> Standard
  ProfileV1 -- aligns to --> Regulation
  RegVC -- declares --> Endorsement

  AgentDID -- fetches --> RegVC
  AgentDID -- crawls + hashes --> SchemeDoc
  AgentDID -- validates topic refs --> TopicScheme
  AgentDID -- checks reachability --> Standard
  AgentDID -- checks reachability --> Regulation
  AgentDID -- signs --> Observation
  Observation -- recorded in --> CvcRegister

  DCC -- references --> ProfileV1
  DPP -- references --> ProfileV1
```

**How to read the diagram:**

- **Solid arrows** are runtime data references or signatures.
- **Dotted arrows** are key-control (which private key controls which DID).
- **Topics are borrowed, not redefined.** Every topic reference in a scheme vocabulary points at a concept in the published `conformity-topics` SKOS scheme. Cross-scheme comparability is achieved through shared topic identity.
- **The agent does not modify scheme artefacts.** It only reads, hashes, and writes its own observation VCs.
- **Downstream consumers reference profile versions, not scheme entries.** A DCC's `attestation.assessmentScheme` is a `profileVersionId` URI on the owner's domain. The CVC register is the discovery layer that lets a verifier go from that URI back to the full scheme metadata.

## Trust boundaries and failure modes

| Threat | Mitigation |
|---|---|
| Owner publishes a registration VC that points to a vocabulary they cannot themselves validate. | Agent runs all conformance checks on every cycle; the entry's status reflects what the agent can confirm, not what the owner asserts. |
| Owner silently modifies a published profile version after registration. | Hash mismatch on next crawl → version flagged → entry status degraded. CABs and verifiers using the registered hash detect drift independently. |
| Owner key compromise. | Owner rotates the DID Document's verification methods. Agent re-verifies the registration VC on every crawl; observations using the old key fail signature validation until the VC is re-signed under the new key. |
| Hosting goes offline (`vocabularyURL` 404s). | Agent records the fetch failure as a check failure. |
| Profile version URI returns different content over time. | Same as silent modification — hash drift detected and flagged. |
| Topic URI references go stale (topic concept removed from `conformity-topics` scheme). | The conformity-topics scheme is itself append-only; concepts are deprecated, not deleted. Reference stability is maintained by the topics scheme's own governance. |
| Endorsement evidence link rots. | Recorded as a partial-conformance failure. |
| Owner declares an alignment to a standard the scheme doesn't actually meet. | The agent doesn't audit alignment claims (it has no semantic model of the standards themselves). Verifiers should treat alignment claims as owner assertions, not as registrar attestations. Disputes about alignment correctness go through the standard owner, not UNECE. |
| Registrar agent compromise. | Each observation is a signed VC; UNECE can re-run validation independently and amend or retract specific observations. Retractions are recorded, not silently deleted. |

## Disputes

The registry's dispute-handling process:

1. Each `ConformanceObservation` includes a `registrarAttestation` pointing to the signed VC the agent issued. The owner can fetch it and the underlying check details.
2. If the owner believes the check was incorrect, they file a dispute with UNECE.
3. UNECE re-runs the relevant validation independently. If the dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. If the dispute concerns *interpretation* of a CVC schema rule (rather than the data), the change-control process applies (see below).

The owner-facing perspective (what to do if you disagree with an observation about your scheme) is in the [Registration Guide](./registration-guide.md#disputes).

## Cadence and retention

- **Crawl cycle:** the registrar agent runs at least daily for active schemes; pilot and dormant schemes may be sampled less frequently.
- **Retention:** observations are append-only and retained indefinitely. Retracted observations are marked, not deleted.
- **Dormant trigger:** 12 months without a new profile version or detected DCC activity referencing any of the scheme's profileVersionIds.
- **Register publication:** `register.json` is regenerated on every crawl cycle and published at `https://registers.uncefact.org/untp/cvc/register.json`. Per-entry URIs (e.g. `https://registers.uncefact.org/untp/cvc/rba-vap`) are content-negotiated to return HTML, JSON-LD, or Turtle depending on the request `Accept` header.

## Relationship to other registers

- **[Software Implementers Register (SWI)](../swi/governance.md)** — when a SWI-listed software issues a DCC referencing a `profileVersionId` from a CVC entry, the SWI agent's observation includes a check that verifies the profileVersionId resolves into a registered CVC scheme. CVC and SWI cross-check each other.
- **[Credential Extensions Register (EXT)](../ext/governance.md)** — if an extension defines a credential type whose subjects reference scheme criteria (e.g. a TextilePassport that asserts conformity claims), those criteria should be registered in CVC. Extensions own credential structure; CVC owns assessment criteria.
- **GRID** — out of scope. CVC is for community-published assurance schemes. Schemes operated under formal national or treaty-based authority (e.g. national accreditation bodies operating under ISO/IEC 17011) may eventually have a separate authoritative register at `grid.unece.org`.
- **Identifier Scheme Register (IDR)** — independent. CVC catalogues conformity vocabularies; IDR catalogues identifier schemes (product, facility, organisation identifiers).

## Change control

Changes to this governance document, the CVC register schema, or the conformance check rules are managed under the UN/CEFACT Open Development Process and announced on the UNTP specification site at least 30 days before taking effect. Material changes that would invalidate currently-conformant scheme entries are subject to a longer notice window (typically 90 days) and a migration guide.

Changes to the underlying [UNTP CVC schema](https://untp.unece.org/docs/specification/ConformityVocabularyCatalog) — the schema scheme owners' published vocabularies conform to — follow the standard UNTP versioning process. Existing scheme vocabularies remain conformant against the schema version they were published under; new schema versions are opt-in.

Feedback on the rules or ambiguities should be filed as an issue on the UNTP specification repository or sent to UNECE through the usual channels.

---

## Conformity Schemes

# UNTP Conformity Scheme Register

This page provides a summary of conformity schemes that have committed to publish their scheme as a digital vocabulary that can be referenced by Product Passports, Facility Records, and Conformity Credentials. As described in the UNTP [Conformity Vocabulary](../../specification/ConformityVocabularyCatalog.md) specification, this is a key activity for scheme owners that want to empower their customers to automate their compliance and due-diligence assessments. 

## This Register

THis register is maintained as a structured data set that can be read by machines or by humans.

| Field | Value |
| --- | --- |
| Register ID | `https://registers.unece.org/untp/cvc` |
| Register Data | [JSON-LD register file](/registers/cvc/register.json), [JSON Schema](/registers/cvc/register-schema.json). Note — to be published as a linked-data vocabulary at registers.unece.org before UNTP v1.0 release. |
| Registrar | United Nations Economic Commission for Europe (UNECE) (`https://unece.org`) |
| Registrar DID | `did:webvh:untp.unece.org` |

## Summary of Registered Schemes

| Scheme | Owner | Industry | Geography | Endorsement | Status | Profiles |
| --- | --- | --- | --- | --- | --- | ---: |
| [RBA Validated Assessment Program](#rba-validated-assessment-program) | Responsible Business Alliance | Manufacture of computer, electronic, optical, and electrical equipment | Worldwide | `Self` | 🔵 Pilot | 1 |
| [Responsible Minerals Assurance Process](#responsible-minerals-assurance-process) | Responsible Business Alliance | Mining of metal ores; manufacture of basic metals | Worldwide | `Benchmarked` | 🔵 Pilot | 5 |
| [GBA Battery Passport Rulebook](#gba-battery-passport-rulebook) | Global Battery Alliance | Manufacture of electrical equipment; manufacture of motor vehicles, trailers and semi-trailers | Worldwide | `Benchmarked` | 🔵 Pilot | 0 |
| [The Copper Mark](#the-copper-mark) | The Copper Mark Company | Mining of metal ores; manufacture of basic metals | Worldwide | `Benchmarked` | 🔵 Pilot | 0 |

## Scheme Entries

## RBA Validated Assessment Program

**Status:** 🔵 Pilot  •  **Short name:** VAP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/cvc/rba-vap` |
| Owner | Responsible Business Alliance (`did:web:placeholder-domain.com:untp:cvc:rba`) |
| Owner website | https://www.responsiblebusiness.org |
| Vocabulary URL | https://vocab.deploy2cloud.com.au/vap |
| Documentation | https://www.responsiblebusiness.org/vap/about-vap/ |
| Industry | Manufacture of computer, electronic, optical, and electrical equipment |
| ISIC codes | `26`, `27` |
| Geography | Worldwide |
| Endorsement level | `Self` |
| License type | `ProprietaryDocument` |
| Established | 2017-01-01 |

**Statement**

> The Responsible Business Alliance Validated Assessment Program (VAP) is an industry-standard audit protocol for assessing labor, health and safety, environmental, ethics, and management systems performance in electronics and related supply chains. VAP assessments are conducted by RBA-recognised audit firms and result in a facility-level recognition status.

_Registration VC not yet issued by scheme owner._

### Profiles

#### Full VAP Assessment

- **Profile ID:** `https://vocab.deploy2cloud.com.au/vap/vap-full`
- **Description:** Full facility-level assessment covering labor, health and safety, environment, ethics, and management systems.

  **Version `8.0.2`** (`https://vocab.deploy2cloud.com.au/vap/vap-full/8.0.2`)

  - Validity: 2025-04-01 → present
  - Criteria: 33
  - Topics: `human-equity-and-welfare`, `health-and-safety`, `ecological-resilience`, `ethical-governance`, `systemic-sustainability`

---

## Responsible Minerals Assurance Process

**Status:** 🔵 Pilot  •  **Short name:** RMAP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/cvc/rmap` |
| Owner | Responsible Business Alliance (`did:web:placeholder-domain.com:untp:cvc:rba`) |
| Owner website | https://www.responsiblebusiness.org |
| Vocabulary URL | https://vocab.deploy2cloud.com.au/rmap |
| Documentation | https://www.responsiblemineralsinitiative.org/responsible-minerals-assurance-process/ |
| Industry | Mining of metal ores; manufacture of basic metals |
| ISIC codes | `07`, `24` |
| Geography | Worldwide |
| Endorsement level | `Benchmarked` |
| License type | `ProprietaryDocument` |
| Established | 2010-01-01 |

**Statement**

> The Responsible Minerals Assurance Process (RMAP) is an independent third-party assessment of smelter and refiner management systems and sourcing practices. RMAP assessments determine whether a smelter or refiner has systems in place consistent with relevant responsible sourcing standards for conflict-affected and high-risk minerals including tin, tantalum, tungsten, gold, and cobalt.

**Endorsement**

- RMAP alignment with OECD Due Diligence Guidance for Responsible Supply Chains of Minerals from Conflict-Affected and High-Risk Areas.
- Issuing authority: Organisation for Economic Co-operation and Development (OECD) (`https://www.oecd.org`)
- Evidence: [OECD Minerals Due Diligence Guidance](https://www.oecd.org/en/topics/sub-issues/due-diligence-in-the-minerals-supply-chain.html)

_Registration VC not yet issued by scheme owner._

### Profiles

#### RMAP Gold Refiner Standard

- **Profile ID:** `https://vocab.deploy2cloud.com.au/rmap/rmap-gold`
- **Description:** Independent third-party assessment of gold refiners (RMAP-AU). Aligned with the OECD Due Diligence Guidance five-step framework, with additional financial controls (KYC, AML/CFT, sanctions screening) appropriate to gold supply chains.

  **Version `1.0.0`** (`https://vocab.deploy2cloud.com.au/rmap/rmap-gold/1.0.0`)

  - Validity: 2024-01-01 → present
  - Criteria: 0
  - Topics: `forced-labor-elimination`, `legal-compliance`, `open-reporting`, `anti-corruption-measures`, `origin-tracking`
  - Standard alignments:
    - OECD Due Diligence Guidance for Responsible Supply Chains of Minerals from Conflict-Affected and High-Risk Areas (meets)

#### RMAP Tin and Tantalum Standard

- **Profile ID:** `https://vocab.deploy2cloud.com.au/rmap/rmap-tin-tantalum`
- **Description:** Independent third-party assessment of tin smelters and tantalum processors (RMAP-SN-TA). Aligned with the OECD Due Diligence Guidance five-step framework, with mineral-specific risk controls for the upstream pinch point of 3T metals.

  **Version `1.0.0`** (`https://vocab.deploy2cloud.com.au/rmap/rmap-tin-tantalum/1.0.0`)

  - Validity: 2024-01-01 → present
  - Criteria: 0
  - Topics: `forced-labor-elimination`, `legal-compliance`, `open-reporting`, `anti-corruption-measures`, `origin-tracking`
  - Standard alignments:
    - OECD Due Diligence Guidance for Responsible Supply Chains of Minerals from Conflict-Affected and High-Risk Areas (meets)

#### RMAP Tungsten Smelter Standard

- **Profile ID:** `https://vocab.deploy2cloud.com.au/rmap/rmap-tungsten`
- **Description:** Independent third-party assessment of tungsten smelters and APT processors (RMAP-W). Aligned with the OECD Due Diligence Guidance five-step framework, with tungsten-specific controls.

  **Version `1.0.0`** (`https://vocab.deploy2cloud.com.au/rmap/rmap-tungsten/1.0.0`)

  - Validity: 2024-01-01 → present
  - Criteria: 0
  - Topics: `forced-labor-elimination`, `legal-compliance`, `open-reporting`, `anti-corruption-measures`, `origin-tracking`
  - Standard alignments:
    - OECD Due Diligence Guidance for Responsible Supply Chains of Minerals from Conflict-Affected and High-Risk Areas (meets)

#### RMAP Global Responsible Sourcing Due Diligence Standard

- **Profile ID:** `https://vocab.deploy2cloud.com.au/rmap/rmap-all-minerals`
- **Description:** Combined assessment standard for facilities processing more than one of the 3TG metals (RMAP-ALL). Superset of the four mineral-specific profiles' controls.

  **Version `1.0.0`** (`https://vocab.deploy2cloud.com.au/rmap/rmap-all-minerals/1.0.0`)

  - Validity: 2024-01-01 → present
  - Criteria: 0
  - Topics: `forced-labor-elimination`, `legal-compliance`, `open-reporting`, `anti-corruption-measures`, `origin-tracking`
  - Standard alignments:
    - OECD Due Diligence Guidance for Responsible Supply Chains of Minerals from Conflict-Affected and High-Risk Areas (meets)

#### RMAP Supply Chain Due Diligence Module Plus

- **Profile ID:** `https://vocab.deploy2cloud.com.au/rmap/rmap-supply-chain`
- **Description:** Downstream supply-chain due diligence module that complements the upstream mineral profiles (RMAP+). Adds environmental, labour, community, occupational health and safety, and governance topics. Incorporates OECD MNE Guidelines, OECD RBC Due Diligence Guidance, OECD Environmental Due Diligence Handbook for Mineral Supply Chains, and UN Guiding Principles on Business and Human Rights.

  **Version `1.0.0`** (`https://vocab.deploy2cloud.com.au/rmap/rmap-supply-chain/1.0.0`)

  - Validity: 2024-01-01 → present
  - Criteria: 0
  - Topics: `forced-labor-elimination`, `decent-work-conditions`, `community-empowerment`, `anti-corruption-measures`, `legal-compliance`, `origin-tracking`, `greenhouse-gas-emissions`, `water-conservation`, `waste-minimization`, `ecosystem-preservation`, `workplace-safety`
  - Standard alignments:
    - OECD Due Diligence Guidance for Responsible Supply Chains of Minerals from Conflict-Affected and High-Risk Areas (meets)
    - OECD Guidelines for Multinational Enterprises on Responsible Business Conduct (meets)
    - OECD Due Diligence Guidance for Responsible Business Conduct (meets)
    - OECD Handbook on Environmental Due Diligence in Mineral Supply Chains (meets)
    - UN Guiding Principles on Business and Human Rights (meets)

---

## GBA Battery Passport Rulebook

**Status:** 🔵 Pilot  •  **Short name:** GBA-BPR

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/cvc/gba-battery-passport` |
| Owner | Global Battery Alliance (`did:web:placeholder-domain.com:untp:cvc:gba`) |
| Owner website | https://www.globalbattery.org |
| Vocabulary URL | https://vocab.deploy2cloud.com.au/gba |
| Documentation | https://www.globalbattery.org/battery-passport/ |
| Industry | Manufacture of electrical equipment; manufacture of motor vehicles, trailers and semi-trailers |
| ISIC codes | `27`, `29` |
| Geography | Worldwide |
| Endorsement level | `Benchmarked` |
| License type | `CreativeCommons` |
| Established | 2023-06-01 |

**Statement**

> The GBA Battery Passport Rulebook defines the data and assessment requirements for the GBA Battery Passport, supporting transparency, sustainability, and EU regulatory reporting across the battery supply chain.

**Endorsement**

- GBA Battery Passport alignment with EU Battery Regulation (EU) 2023/1542 requirements for battery passports and due diligence.
- Issuing authority: European Commission (`https://commission.europa.eu`)
- Evidence: [EU Battery Regulation (EU) 2023/1542](https://eur-lex.europa.eu/eli/reg/2023/1542/oj)

_Registration VC not yet issued by scheme owner._

### Profiles

_No profiles discovered yet (registrar agent has not crawled `vocabularyURL`)._

---

## The Copper Mark

**Status:** 🔵 Pilot  •  **Short name:** CopperMark

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/cvc/coppermark` |
| Owner | The Copper Mark Company (`did:web:placeholder-domain.com:untp:cvc:coppermark`) |
| Owner website | https://coppermark.org |
| Vocabulary URL | https://vocab.deploy2cloud.com.au/coppermark |
| Documentation | https://coppermark.org/standards/criteria/ |
| Industry | Mining of metal ores; manufacture of basic metals |
| ISIC codes | `07`, `24` |
| Geography | Worldwide |
| Endorsement level | `Benchmarked` |
| License type | `Public` |
| Established | 2019-12-01 |

**Statement**

> The Copper Mark is a credible assurance framework for the copper, molybdenum, nickel, and zinc value chains. It uses independent third-party assessments against the Joint Due Diligence Standard and 32 ESG criteria aligned with the UN Sustainable Development Goals. Sites that meet all criteria receive The Copper Mark, demonstrating responsible production practices.

**Endorsement**

- The Copper Mark is recognised by the International Copper Association and benchmarked against the OECD Due Diligence Guidance for Responsible Business Conduct.
- Issuing authority: Organisation for Economic Co-operation and Development (OECD) (`https://www.oecd.org`)
- Evidence: [OECD Due Diligence Guidance for Responsible Business Conduct](https://mneguidelines.oecd.org/duediligence/)

_Registration VC not yet issued by scheme owner._

### Profiles

_No profiles discovered yet (registrar agent has not crawled `vocabularyURL`)._

---

<sub>Generated 2026-05-04T05:39:29.140Z from `registers/cvc/register.json`.</sub>

---

## How to Register

# How to Register a Conformity Scheme

This guide walks conformity scheme owners through the steps required to get a scheme listed in the UNTP Conformity Vocabulary Catalogue (CVC) Register.

If you want to understand how the registry itself is governed (registrar role, agent operation, dispute and retention policy), see the [Governance](./governance.md) document. If you simply want to browse already-registered schemes, see the [register itself](./).

## Who should register

You are a candidate scheme owner if your organisation operates an audit, assessment, certification, or attestation programme whose criteria are referenced by Verifiable Credentials in transparent supply chains. Typical scheme owners include:

- Standards bodies
- Industry associations
- Certification programmes
- Accreditation bodies
- Intergovernmental bodies
- Regulators (where the regulator publishes machine-readable conformity criteria)

## What you'll get when you're done

- An entry in the CVC Register at `https://registers.uncefact.org/untp/cvc/{your-scheme-slug}`.
- A UNECE-issued Digital Identity Anchor (DIA) credential about your scheme owner DID, hosted on your register entry.
- Continuous, automated conformity observation by the UNTP registrar agent — your register status reflects observed reality without requiring you to re-submit anything.
- Discoverability for Conformity Assessment Bodies (CABs), implementers, verifiers, and regulators looking for trusted assurance frameworks to reference.

## Quick summary

The full process boils down to three things:

1. **Publish a DID** at a domain you control (typically `did:web:yourdomain.org`).
2. **Publish a UNTP-conformant CVC vocabulary** at a stable URL (the `vocabularyURL`) — your scheme, profiles, and criteria as machine-readable linked data.
3. **Issue a registration Verifiable Credential** signed by your DID, pointing at the vocabularyURL, and notify UNECE.

The registrar agent does the rest: crawls your vocabulary, validates it, indexes per-profile metadata (topics, alignments, validity, criterion counts), and writes signed observations against your entry.

## Prerequisites

Before you start, you'll need:

| Item | Notes |
|---|---|
| A web domain you control | Required for `did:web` and for hosting your vocabulary. |
| Ability to host static or dynamically-served linked data documents | JSON-LD, Turtle, or content-negotiated. |
| An understanding of the [UNTP CVC specification](https://untp.unece.org/docs/specification/ConformityVocabularyCatalog) | This is the schema your published vocabulary must conform to. |
| The UNTP [conformity topics](https://vocabulary.uncefact.org/conformity-topics/) SKOS scheme | You'll classify your criteria against these topics. |
| A representative who can liaise with UNECE | For initial onboarding and any future disputes. |

You do **not** need:

- Bespoke software to manage the vocabulary (static files on a CDN are fine).
- Pre-existing UNTP credentials of your own — only the published vocabulary itself.
- A test deployment certified before production — the agent observes your live vocabulary.

## Step-by-step

### Step 1 — Get in touch with UNECE

Tell UNECE you intend to publish a UNTP-conformant scheme vocabulary. UNECE will create a `proposed` register entry as a placeholder while you set up your DID and vocabulary. There is no review or approval gate at this stage — proposals are accepted on intent.

You'll receive a placeholder DID and a slug for your scheme entry; both will be replaced once you publish your real DID and registration VC.

### Step 2 — Publish your owner DID

Stand up `did:web:yourdomain.org` (or another DID method you prefer). Your DID Document must include at least one `assertionMethod` verification method usable to sign Verifiable Credentials.

Notify UNECE of your DID URL. UNECE will replace the placeholder DID on your entry, and shortly after will issue a UNECE-signed DIA credential about your DID — this is the trust anchor that downstream verifiers use to confirm your scheme is duly registered. The DIA is hosted on your register entry.

### Step 3 — Develop your CVC vocabulary

Author your scheme as machine-readable linked data, conformant with the [UNTP CVC schema](https://untp.unece.org/docs/specification/ConformityVocabularyCatalog). The vocabulary roots a hierarchy of:

- **One scheme** — top-level metadata: owner, endorsement, scoring framework, scope.
- **One or more profiles** — versioned subsets of the scheme; each profile composes one or more versioned criteria.
- **Versioned criteria** — the auditable requirements with topic classifications and (optionally) performance thresholds.

For every scheme version, profile, profile version, and criterion, mint a **stable, version-embedded URI** on your domain (e.g. `https://vocab.yourdomain.org/yourscheme/profile-name/1.0.0`). Once a versioned URI is published, never edit its content — mint a new version instead.

### Step 4 — Choose your maturity level

The CVC specification supports three maturity levels. Your register status reflects the level you've reached:

| Level | Description | Register status when achieved |
|---|---|---|
| **Level 1 — Scheme only** | Stable URIs per scheme version + top-level metadata (owner, endorsement, assessment level). | `pilot` once the agent successfully crawls your scheme. |
| **Level 2 — Scheme + criteria** | Versioned schemes + versioned criteria as permanent URLs; each criterion classified by topic code. | `active` once topic classifications populate. |
| **Level 3 — Full vocabulary** | Schemes + criteria + standard/regulatory alignments + performance thresholds. | `conformant` once all alignments and thresholds resolve. |

You can publish at Level 1 and advance later. Most owners find Level 2 hits the cost/value sweet spot.

### Step 5 — Classify your criteria against UNTP topics

Every criterion (and ideally every profile) should carry one or more topic URIs from the UNTP conformity topics SKOS scheme at `https://vocabulary.uncefact.org/conformity-topics/`. Topic classifications are what make claims and assessments comparable across schemes — without them, your scheme is registered but not cross-comparable.

Pick the most specific applicable topic when one exists; fall back to a top-level topic when not.

### Step 6 — Declare your alignments (optional but recommended)

For each profile, declare the voluntary standards and national regulations the profile is designed to align with, and at what level (`partial`, `meets`, or `exceeds`). For example, a supply-chain due diligence profile might declare alignment with the OECD Due Diligence Guidance and the UN Guiding Principles on Business and Human Rights — each with its own alignment level.

These declarations are owner assertions, not registrar attestations. They help verifiers compute regulatory sufficiency programmatically; they don't constitute registry endorsement of the alignment claim itself.

### Step 7 — Issue your registration VC

Sign a Verifiable Credential whose `credentialSubject` matches the `ConformityVocabularyCatalogueEntry` shape (per [`register-schema.json`](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/cvc/register-schema.json)) including:

- Your scheme name, statement, industry sector, geographic scope.
- Your `vocabularyURL` (the root of the published vocabulary from step 3).
- Endorsement metadata (where applicable).
- License type, established date, trust mark URL.

Host the VC at a stable URI you control (e.g. `https://yourdomain.org/.well-known/untp/cvc/registration-vc.json`). Notify UNECE of the URI.

### Step 8 — First crawl

The registrar agent fetches your registration VC, verifies the signature, fetches your `vocabularyURL`, runs the validation checks below, indexes profiles and per-version metadata. If everything passes, status moves to `pilot` (or higher depending on your maturity level).

You can ask UNECE for a faster-than-cyclical first observation; otherwise it runs at the next scheduled cycle (typically within 24 hours).

## What gets verified

These are the conformance checks the agent runs on every cycle. Pass these and your status holds.

| Check | What you need to do to pass |
|---|---|
| Registration VC signature valid | Keep your DID Document's verification methods current; re-sign and re-publish your VC after any key rotation. |
| `vocabularyURL` resolves | Use stable hosting; consider a CDN or content-addressed mirror for resilience. |
| CVC schema conformant | Validate your vocabulary locally against `ConformityScheme.json` v0.7.0 before publishing. |
| Schema hash drift detection | Treat published vocabulary documents as immutable. Edits = new versions, never overwrites. |
| Profile URIs stable | Every profile and profile-version URI must dereference to content. 404 = check failure. |
| Versioned URIs immutable | Once a profile-version URI is published, its content hash must not change. |
| Topic URIs resolve | Reference real concepts in `vocabulary.uncefact.org/conformity-topics/`. Don't invent topics. |
| Standard / regulation references resolve | If you declare an alignment, the standard/regulation URL must be reachable. |
| Endorsement evidence resolves | If you declare an endorsement, the evidence URL must be reachable. |

A small failure (e.g. one broken evidence link) yields `partially-conformant`. A fatal failure (signature, schema, profile URI not resolving) yields `non-conformant`. The agent always records exactly which checks failed, so you can fix exactly the broken ones.

## After registration: the lifecycle

```mermaid
stateDiagram-v2
  [*] --> proposed
  proposed --> development
  development --> pilot
  pilot --> active
  pilot --> conformant
  active --> conformant
  active --> dormant
  conformant --> dormant
  dormant --> active
  active --> withdrawn
  conformant --> withdrawn
  dormant --> withdrawn
  withdrawn --> [*]
```

After your initial registration:

- The agent crawls daily for active schemes and writes signed observations on every cycle.
- Drift in your published documents (changes to a versioned URI's content, broken topic references, etc.) is detected automatically and surfaces as observation failures.
- Your status reflects the latest observation — no human review or re-submission is required.

## Maintaining your registration

### Publishing a new profile version

1. Mint a new `versionLabel` using SemVer (e.g. `8.1.0`).
2. Mint a new stable `profileVersionId` URI that embeds the version (e.g. `…/yourscheme/yourprofile/8.1.0`). **Do not edit the previous version's URI content** — CABs and verifiers must continue to resolve old hashes for historical assessments.
3. Update the criterion list and topic classifications as needed.
4. Publish the new version at the new URI.
5. Optionally update standard/regulatory alignments if relevant.
6. Notify UNECE if you want a faster-than-cyclical update; otherwise the next crawl picks it up.

The agent treats each profile version independently — an old version remaining `conformant` does not depend on the new version passing.

### Rotating keys

If you need to rotate the signing key your DID controls:

1. Update your DID Document's verification methods.
2. Re-sign your registration VC with the new key.
3. Re-publish the VC at the same URI.

The agent re-verifies the registration VC on every cycle. There is a brief window where an in-flight observation may fail signature validation; the next cycle will succeed.

### Withdrawing

You may exit at any time. Tell UNECE; your entry is marked `withdrawn`. Historical observations are retained for audit. Your published vocabulary URIs should remain reachable for a reasonable transition period to avoid breaking historical DCCs that reference your profile-version URIs.

## Disputes

If you disagree with an observation about your scheme:

1. Fetch the `registrarAttestation` linked from the observation. It points to a signed VC the agent issued, with all check details.
2. If you can demonstrate the check was incorrect (e.g. transient fetch failure, clock-skew issue, misinterpretation of the CVC schema), file a dispute with UNECE.
3. UNECE re-runs the relevant validation independently. If your dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. If the disagreement concerns *interpretation* of a CVC schema rule (rather than the data), the change goes through the formal change-control process described in the [Governance](./governance.md#change-control) document.

## Common questions

**Do I need to start at Level 3?**
No. Level 1 is enough to be listed as `pilot`. Most schemes start at Level 1 and advance to Level 2 within a few months.

**Do I need a DID for every profile?**
No. Your DID identifies the scheme owner (you). Profiles and criteria are URIs, not DIDs.

**What if my scheme has multiple owners (e.g. a joint initiative)?**
One owner DID is the registration signer. Co-owners can be referenced in the registration VC as contributors but don't sign. If governance is genuinely shared, consider standing up a joint-venture DID at a domain controlled by both parties.

**My scheme references criteria from another organisation's standards. Do I need their permission?**
Aligning to (referencing) an external standard does not require permission — your declaration is a public claim about your scheme. Republishing or copying the external standard's content does require permission per that standard's licensing terms.

**Can two schemes use the same criterion URI?**
No. Each criterion URI is owned by exactly one scheme. If two schemes share substantively identical criteria, each publishes its own URI and the cross-reference is documented in metadata (e.g. via `skos:exactMatch` in your vocabulary).

**What happens if my hosting goes down?**
The next agent crawl records the failure as an observation; your status drops to `non-conformant` for the duration. Restoring hosting and waiting for the next crawl restores your status. Persistent outages (multiple cycles) trigger a contact from UNECE.

**Is there a fee?**
There is likely to be a minimal registration fee that is used to maintain register integrity on a non-for-profit basis. The actual fee structure will be determined before UNTP version 1.0 release.

## Where to get help

- **The CVC specification itself:** [https://untp.unece.org/docs/specification/ConformityVocabularyCatalog](https://untp.unece.org/docs/specification/ConformityVocabularyCatalog)
- **Sample registered schemes:** see the [register itself](./).
- **The conformity topics taxonomy:** [https://vocabulary.uncefact.org/conformity-topics/](https://vocabulary.uncefact.org/conformity-topics/)
- **Direct contact:** raise an issue on the [UNTP specification repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), or reach out via the UNTP mailing list or UNTP slack channel (join via the links on the home page).

---

## Registry Governance(Ext)

# UNTP Credential Extensions Register — Governance

This document describes how the UNTP Credential Extensions (EXT) Register is governed: its purpose, how the registrar agent maintains it, the trust model, retention and dispute policy, and how the register relates to the other UNTP registers.

If you are an **extension owner** (an industry association, standards body, intergovernmental body, consortium, or research centre publishing a UNTP extension) looking for step-by-step instructions to register your extension, see the [Registration Guide](./registration-guide.md).

If you are an **implementer or verifier** looking up registered extensions, see the [register itself](./).

## Purpose

The register answers two questions:

1. **For an implementer:** "Is this extension a real, governed, UNTP-conformant extension I can build against?"
2. **For a verifier:** "When I encounter a credential of an extension type, where do I find the authoritative schema and vocabulary, and can I be sure they haven't drifted since registration?"

## How authority is shared

Authority over the register comes from two parties working together:

- **Extension owners** sign Verifiable Credentials that declare their extension's metadata, schema location, context, vocabulary, and sample instances.
- **UNECE** (the registrar) periodically fetches that VC and the documents it points to, hashes them, runs UNTP extension-conformance checks, and writes signed observations back to the register.

Neither party can act unilaterally. Owners publish; the registrar validates. The register is a record of what owners have published *and* what an independent agent has been able to verify.

This federated, pull-based design is deliberate. It gives drift detection (hashing what we fetched lets verifiers detect silent post-registration changes), cryptographic trust (entries derive from owner-signed VCs that anyone can independently verify), and avoids bottlenecks (owners publish on their own schedule).

## Roles

| Role | Identity | Responsibilities |
|---|---|---|
| **Registrar** | UNECE | Owns the register; defines the schema and conformance rules; operates the registrar agent; mediates disputes. |
| **Registrar Agent** | `did:webvh:untp.unece.org` | Fetches each owner's registration VC, verifies its signature, fetches and hashes the referenced schema/context/vocabulary documents, runs the UNTP extension-conformance checks, validates samples, signs and publishes conformance observations. |
| **Extension Owner** | Owner DID (e.g. `did:web:owner.example`) | Publishes and maintains an extension. See the [Registration Guide](./registration-guide.md) for the full owner-facing process. |
| **Extension Implementer** | Customer/deployer DID | Builds software that issues and/or verifies credentials of the extension type. Not part of governance, but the audience the registration serves. |
| **UNTP Core Maintainer** | UN/CEFACT | Maintains the UNTP core specification, context, and vocabulary that extensions extend. Coordinates breaking changes through the standard UN/CEFACT process. |

Extension ownership is restricted to **member organisations** that represent the shared interests of multiple constituent organisations (industry associations, standards bodies, intergovernmental bodies, consortia, research centres). Single companies are not eligible owners — extensions exist to serve communities, not individual vendors.

## What the agent verifies

These are the conformance checks the registrar agent runs on every observation cycle. The owner-facing perspective on these checks (and how to satisfy them) is in the [Registration Guide](./registration-guide.md#what-gets-verified).

| Rule | What it checks |
|---|---|
| **Registration VC signature valid** | The registration VC verifies against the owner DID's current verification methods. |
| **Schema hash match** | The fetched schema document hashes to the same value the agent recorded last cycle. |
| **Context hash match** | Same, for the context document. |
| **Vocabulary hash match** | Same, for the vocabulary document. |
| **UNTP context required** | The extension context imports the UNTP context at the version declared in `extendsUntpVersion`. |
| **Extension context defined** | The extension publishes its own context document (i.e. doesn't only re-use the UNTP context). |
| **All terms resolved** | Every property in the extension schema can be resolved either via the extension context/vocabulary or via the UNTP context/vocabulary. |
| **No UNTP redefinitions** | The extension context does not redefine any IRI, alias, or container that is already defined in the imported UNTP context. |
| **`@vocab` catch-all scope** | If the extension context declares `@vocab`, that catch-all only matches terms that are *not* defined in either the extension vocabulary or the UNTP vocabulary. |
| **Samples validate** | Every `isExpectedPass: true` sample validates against the schema; every `isExpectedPass: false` sample fails as declared. |

A small failure (e.g. one sample validation issue) yields `partially-conformant`. A fatal failure (signature, hash, redefinition, term resolution) yields `non-conformant`.

## Identity, Document, and Credential Relationships

```mermaid
flowchart LR
  subgraph Owner["Extension Owner"]
    OwnerDID["Owner DIDdid:web:owner.example"]
    OwnerKey[("OwnerSigning Key")]
    RegVC["Registration VCcredentialSubject = ExtensionEntry"]
    Schema["Extension SchemaFoo.schema.json"]
    Context["Extension Contextfoo-context.jsonld"]
    Vocab["Extension Vocabularyfoo-vocabulary.ttl"]
    Sample1["Sample VC #1"]
    Sample2["Sample VC #2"]
  end

  subgraph UNTP["UNTP Core"]
    CoreContext["UNTP Contextat extendsUntpVersion"]
    CoreVocab["UNTP Core Vocabulary"]
  end

  subgraph Registrar["UNECE Registrar"]
    AgentDID["Registrar Agent DIDdid:webvh:untp.unece.org"]
    AgentKey[("AgentSigning Key")]
    Observation["Conformance Observation VC(per cycle, per version)"]
    ExtRegister[("Extensions Registerregister.json")]
  end

  OwnerKey -. controls .-> OwnerDID
  AgentKey -. controls .-> AgentDID

  OwnerDID -- signs --> RegVC
  RegVC -- references --> Schema
  RegVC -- references --> Context
  RegVC -- references --> Vocab
  RegVC -- references --> Sample1
  RegVC -- references --> Sample2

  Context -- imports at exact version --> CoreContext
  Schema -- terms defined in --> Context
  Schema -- terms defined in --> CoreContext
  Vocab -- defines extension terms --> Context
  CoreVocab -- defines core terms --> CoreContext
  Sample1 -- validates against --> Schema
  Sample2 -- validates against --> Schema

  AgentDID -- fetches --> RegVC
  AgentDID -- fetches + hashes --> Schema
  AgentDID -- fetches + hashes --> Context
  AgentDID -- fetches + hashes --> Vocab
  AgentDID -- fetches + validates --> Sample1
  AgentDID -- fetches + validates --> Sample2
  AgentDID -- signs --> Observation
  Observation -- recorded in --> ExtRegister
```

**How to read the diagram:**

- **Solid arrows** are runtime data references or signatures.
- **Dotted arrows** are key-control (which private key controls which DID).
- **The owner signs the registration VC.** Everything in their half of the diagram — DID, VC, schema, context, vocabulary, samples — lives on infrastructure they control.
- **The agent does not modify owner artefacts.** It only reads, hashes, and writes its own observation VCs.
- **The extension context bridges extension terms to the UNTP context.** Every credential of the extension type carries both contexts; verifiers resolve every property through one or the other.

## Trust boundaries and failure modes

| Threat | Mitigation |
|---|---|
| Owner publishes a registration VC that points to a schema they cannot themselves validate. | Agent runs all conformance checks on every cycle; the entry's status reflects what the agent can confirm, not what the owner asserts. |
| Owner silently modifies the schema after registration. | Hash mismatch on next cycle → `schemaHashMatch: false` → `non-conformant`. Implementers using the registered hash detect drift independently. |
| Owner key compromise. | Owner rotates the DID Document's verification methods. The agent re-verifies the registration VC on every cycle; observations using the old key fail signature validation and the entry moves to `non-conformant` until the VC is re-signed under the new key. |
| Hosting goes offline (schema URI 404s). | Agent records the fetch failure as a check failure. |
| Two extensions register the same `credentialType` name. | Disambiguation is by extension context URI, not by `credentialType` alone. The register permits the collision; verifiers must resolve types via the credential's `@context` array. |
| Owner withdraws but credentials of the extension are still in circulation. | Historical entry remains in the register marked `withdrawn`; verifiers can still resolve the schema and verify credentials issued during the active period. |
| Registrar agent compromise. | Each observation is a signed VC; UNECE can re-run validation independently and amend or retract specific observations. Retractions are recorded, not silently deleted. |

## Disputes

The registry's dispute-handling process:

1. Each `ConformanceObservation` includes a `registrarAttestation` pointing to the signed VC the agent issued.
2. The owner files a dispute with UNECE.
3. UNECE re-runs validation independently. If the dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. Disputes about *interpretation* of a conformance rule (rather than the data) follow the change-control process below.

The owner-facing perspective (what to do if you disagree with an observation) is in the [Registration Guide](./registration-guide.md#disputes).

## Cadence and retention

- **Observation cycle:** the registrar agent runs at least weekly; high-activity extensions may be observed more frequently.
- **Retention:** observations are append-only and retained indefinitely. Retracted observations are marked, not deleted.
- **Dormant trigger:** 12 months without owner-initiated updates or any observation passing.
- **Register publication:** `register.json` is regenerated on every observation cycle and published at `https://registers.uncefact.org/untp/ext/register.json`. Per-entry URIs are content-negotiated to return HTML, JSON-LD, or Turtle depending on the request `Accept` header.

## Relationship to other registers

- **[Software Implementers Register (SWI)](../swi/governance.md)** — when an implementer's software issues a credential of an extension type, the SWI registrar agent looks up the extension here to find the schema and vocabulary against which to validate that credential. The extension's `pilot`/`active` status determines whether SWI observations record extension-validation results.
- **[Identifier Scheme Register (IDR)](../idr/governance.md)** — extensions may rely on registered identifier schemes for product/facility/party IDs.
- **[Conformity Vocabulary Catalogue Register (CVC)](../cvc/governance.md)** — if an extension references certification schemes (DCC subjects), they should be registered in CVC.

If an extension relies on resources in any of these registers, the relationships are referenced by URI in the entry's documentation. The agents do not currently auto-resolve cross-register dependencies, but they may in future cycles.

## Change control

Changes to this governance document, the extension register schema, or the conformance rules are managed under the UN/CEFACT Open Development Process and announced on the UNTP specification site at least 30 days before taking effect. Material changes that would invalidate currently-conformant extensions are subject to a longer notice window (typically 90 days) and a migration guide.

Feedback on the rules or ambiguities should be filed as an issue on the UNTP specification repository or sent to UNECE through the usual channels.

---

## Credential Extensions

# UNTP Credential Extension Register

This page provides a summary of community organisations that have committed to publish credential extensions to the UNTP core specification. As described in the UNTP [Extensions Methodology](../../tools-and-support/ExtensionsMethodology.md), this is a key activity for industry associations and standards bodies that want to deliver sector-specific UNTP credentials to their members while maintaining interoperability with UNTP core.

## This Register

This register is maintained as a structured data set that can be read by machines or by humans.

| Field | Value |
| --- | --- |
| Register ID | `https://registers.unece.org/untp/ext` |
| Register Data | [JSON-LD register file](/registers/ext/register.json), [JSON Schema](/registers/ext/register-schema.json). Note — to be published as a linked-data vocabulary at registers.unece.org before UNTP v1.0 release. |
| Registrar | United Nations Economic Commission for Europe (UNECE) (`https://unece.org`) |
| Registrar DID | `did:webvh:untp.unece.org` |

## Summary of Registered Extensions

| Extension | Owner | Industry | Geography | Status | Credentials |
| --- | --- | --- | --- | --- | ---: |
| [Responsible Business Transparency Protocol](#responsible-business-transparency-protocol) | Responsible Business Alliance | Electrical, electronic and automotive parts | Global | 🔵 Pilot | 5 |
| [Universal Data Protocol for the Global Built Environment](#universal-data-protocol-for-the-global-built-environment) | Standards Australia | Built Environment (construction) | Global | 🟡 In Development | 2 |
| [Australian Agriculture Traceability Protocol](#australian-agriculture-traceability-protocol) | Food Agility CRC | Agriculture | Australia | 🔵 Pilot | 3 |
| [Global Battery Alliance Transparency Protocol](#global-battery-alliance-transparency-protocol) | Global Battery Alliance | Batteries and accumulators | Global | 🟡 In Development | 8 |
| [International Copper Association Transparency Protocol](#international-copper-association-transparency-protocol) | International Copper Association | Copper mining and processing | Global | 🟡 In Development | 2 |

## Extension Entries

## Responsible Business Transparency Protocol

**Status:** 🔵 Pilot  •  **Short name:** RBTP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/ext/rbtp` |
| Industry | Electrical, electronic and automotive parts |
| Geography | Global |
| Extension website | https://www.responsiblebusiness.org/ |

**Overview**

> The Responsible Business Alliance (RBA) is a coalition of companies driving sustainable value for workers, the environment and business throughout the global supply chain. Building upon the foundational capabilities provided by UNTP, the RBA delivers a suite of interoperability standards for the electrical and electronic goods and automotive parts industries.

- **Owner:** Responsible Business Alliance
  - DID: `did:web:placeholder-domain.com:untp:ext:rba`
  - Website: https://www.responsiblebusiness.org/
  - Type: industry-association

_Registration VC not yet issued by extension owner._

### Credentials Defined

| Credential | Extends | Purpose |
| --- | --- | --- |
| [RMAPConformityCredential](#rmapconformitycredential) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests responsible sourcing of minerals. |
| [VAPConformityCredential](#vapconformitycredential) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests supplier facility meets RBA Code. |
| [ElectricalGoodsPassport](#electricalgoodspassport-egp) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | ESG data for electrical and electronic products. |
| [DigitalBatteryPassport](#digitalbatterypassport-dbp) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | Battery sustainability and EU compliance. |
| [ElectricalFacilityRecord](#electricalfacilityrecord-efr) | [DFR](https://vocabulary.uncefact.org/untp/DigitalFacilityRecord) | Manufacturing facility sustainability data. |

#### RMAPConformityCredential

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests responsible sourcing of minerals.
- **Typical flow:** Certifier → Mining company → Electronics manufacturer (verifies)

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### VAPConformityCredential

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests supplier facility meets RBA Code.
- **Typical flow:** Auditor → Factory → Brand (verifies)

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### ElectricalGoodsPassport (EGP)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** ESG data for electrical and electronic products.
- **Typical flow:** Manufacturer → Customers → End users

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### DigitalBatteryPassport (DBP)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** Battery sustainability and EU compliance.
- **Typical flow:** Battery manufacturer → Vehicle OEM → Consumer

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### ElectricalFacilityRecord (EFR)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalFacilityRecord`
- **Purpose:** Manufacturing facility sustainability data.
- **Typical flow:** Facility operator → Brand (due diligence)

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

---

## Universal Data Protocol for the Global Built Environment

**Status:** 🟡 In Development  •  **Short name:** UDP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/ext/udp` |
| Industry | Built Environment (construction) |
| Geography | Global |

**Overview**

> The Universal Data Protocol (UDP) extends UNTP's decentralised framework to provide transparent, trustworthy, and verifiable data in the global built environment. UDP plans a Building Passport (DPP extension) and Building Maintenance Event (DTE extension) for built-environment lifecycle data, alongside conformity vocabulary catalogues registered separately in the CVC register. The UDP is an open protocol enabling efficient exchange of verifiable data, enhancing reporting and compliance across jurisdictions and life cycle stages.

- **Owner:** Standards Australia
  - DID: `did:web:placeholder-domain.com:untp:ext:standards-australia`
  - Website: https://www.standards.org.au/
  - Type: standards-body
- **Co-owner:** International Code Council
  - DID: `did:web:placeholder-domain.com:untp:ext:icc`
  - Website: https://www.iccsafe.org/
  - Type: standards-body

_Registration VC not yet issued by extension owner._

### Credentials Defined

| Credential | Extends | Purpose |
| --- | --- | --- |
| [BuildingPassport](#buildingpassport) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | Digital product passport for buildings: design, construction materials, performance characteristics, and lifecycle data. |
| [BuildingMaintenanceEvent](#buildingmaintenanceevent) | [DTE](https://vocabulary.uncefact.org/untp/DigitalTraceabilityEvent) | Lifecycle event for buildings: maintenance, inspections, retrofits, and other interventions over the building's operating life. |

#### BuildingPassport

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** Digital product passport for buildings: design, construction materials, performance characteristics, and lifecycle data.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### BuildingMaintenanceEvent

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalTraceabilityEvent`
- **Purpose:** Lifecycle event for buildings: maintenance, inspections, retrofits, and other interventions over the building's operating life.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

---

## Australian Agriculture Traceability Protocol

**Status:** 🔵 Pilot  •  **Short name:** AATP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/ext/aatp` |
| Industry | Agriculture |
| Geography | Australia |
| Extension website | https://aatp.foodagility.com/ |

**Overview**

> The AATP is an adaptation of the UN Transparency Protocol designed to help Australian producers meet emerging environmental, social, and governance regulatory and consumer requirements. Operating as a governance framework, the AATP facilitates interaction between multiple certifiers, farm systems, and enterprise systems. Interoperability and traceability tools help the Australian agriculture sector attain higher quality information about the value of Australian-made products.

- **Owner:** Food Agility CRC
  - DID: `did:web:placeholder-domain.com:untp:ext:foodagility`
  - Website: https://www.foodagility.com/
  - Type: research-centre

_Registration VC not yet issued by extension owner._

### Credentials Defined

| Credential | Extends | Purpose |
| --- | --- | --- |
| [DigitalLivestockPassport](#digitallivestockpassport) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | For cattle, sheep, poultry — includes animal breed, RFID tag ID, welfare certifications. |
| [DigitalHorticulturePassport](#digitalhorticulturepassport) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | For fruits and vegetables — includes crop variety, organic certification, harvest date. |
| [DigitalGrainPassport](#digitalgrainpassport) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | For wheat, barley, rice — includes grain variety, moisture content, storage conditions. |

#### DigitalLivestockPassport

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** For cattle, sheep, poultry — includes animal breed, RFID tag ID, welfare certifications.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - **Schema:** https://aatp.foodagility.com/schemas/0.1.0/DigitalLivestockPassport.schema.json
    - hash: _not yet computed_
  - **Context:** https://aatp.foodagility.com/contexts/0.1.0/aatp-context.jsonld
    - hash: _not yet computed_
  - **Vocabulary:** https://aatp.foodagility.com/vocabularies/0.1.0/aatp-vocabulary.ttl
    - hash: _not yet computed_

#### DigitalHorticulturePassport

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** For fruits and vegetables — includes crop variety, organic certification, harvest date.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - **Schema:** https://aatp.foodagility.com/schemas/0.1.0/DigitalHorticulturePassport.schema.json
    - hash: _not yet computed_

#### DigitalGrainPassport

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** For wheat, barley, rice — includes grain variety, moisture content, storage conditions.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - **Schema:** https://aatp.foodagility.com/schemas/0.1.0/DigitalGrainPassport.schema.json
    - hash: _not yet computed_

---

## Global Battery Alliance Transparency Protocol

**Status:** 🟡 In Development  •  **Short name:** GBA-TP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/ext/gba-tp` |
| Industry | Batteries and accumulators |
| ISIC codes | `B.7`, `C.24`, `C.2720` |
| Geography | Global |

**Overview**

> The Global Battery Alliance is the leading multistakeholder organisation for sustainable, transparent and resilient battery supply chains. Its flagship initiative, the Battery Passport, leverages digital product passport technology to create harmonised data exchange, reporting, compliance and sustainability certification frameworks for companies in the battery supply chain worldwide.

- **Owner:** Global Battery Alliance
  - DID: `did:web:placeholder-domain.com:untp:ext:gba`
  - Website: https://www.globalbattery.org/
  - Type: consortium

_Registration VC not yet issued by extension owner._

### Credentials Defined

| Credential | Extends | Purpose |
| --- | --- | --- |
| [DigitalBatteryPassport](#digitalbatterypassport-dbp) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | Battery supply chain transparency and EU regulatory reporting. |
| [BatterySustainabilityCertificate](#batterysustainabilitycertificate) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests battery meets GBA sustainability certification. |
| [CarbonCalculationCertificate](#carboncalculationcertificate-ccc) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests correct carbon emissions calculation per the GBA Rulebook. |
| [DigitalSiteFacilityReport](#digitalsitefacilityreport-dsr) | [DFR](https://vocabulary.uncefact.org/untp/DigitalFacilityRecord) | Site/facility data aligned to Battery Passport requirements. NOTE: source page lists this as extending DPP — this register treats it as DFR pending owner confirmation, since 'site/facility' data is the DFR's domain. |
| [SiteFacilityVerificationCredential](#sitefacilityverificationcredential-sfvc) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests site/facility data reporting conformance. |
| [ApprovedVerifierCredential](#approvedverifiercredential-avc) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests provider approved for verification services. |
| [ApprovedCertifierCredential](#approvedcertifiercredential) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests provider approved for certification services. |
| [ApprovedCarbonCalculationPartnerCredential](#approvedcarboncalculationpartnercredential) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Attests provider approved for carbon calculation services. |

#### DigitalBatteryPassport (DBP)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** Battery supply chain transparency and EU regulatory reporting.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### BatterySustainabilityCertificate

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests battery meets GBA sustainability certification.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### CarbonCalculationCertificate (CCC)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests correct carbon emissions calculation per the GBA Rulebook.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### DigitalSiteFacilityReport (DSR)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalFacilityRecord`
- **Purpose:** Site/facility data aligned to Battery Passport requirements. NOTE: source page lists this as extending DPP — this register treats it as DFR pending owner confirmation, since 'site/facility' data is the DFR's domain.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### SiteFacilityVerificationCredential (SFVC)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests site/facility data reporting conformance.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### ApprovedVerifierCredential (AVC)

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests provider approved for verification services.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### ApprovedCertifierCredential

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests provider approved for certification services.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### ApprovedCarbonCalculationPartnerCredential

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Attests provider approved for carbon calculation services.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

---

## International Copper Association Transparency Protocol

**Status:** 🟡 In Development  •  **Short name:** ICATP

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/ext/icatp` |
| Industry | Copper mining and processing |
| Geography | Global |
| Extension website | https://internationalcopper.org/ |

**Overview**

> The International Copper Association (ICA) promotes copper, protects its markets, and defends and sustains copper demand as the superior material to address global challenges like electrification, urbanisation and digitalisation. The copper extension to UNTP helps copper producers demonstrate responsible production practices and environmental performance and build trust in the copper supply chain.

- **Owner:** International Copper Association
  - DID: `did:web:placeholder-domain.com:untp:ext:ica`
  - Website: https://internationalcopper.org/
  - Type: industry-association

_Registration VC not yet issued by extension owner._

### Credentials Defined

| Credential | Extends | Purpose |
| --- | --- | --- |
| [CopperPassport](#copperpassport) | [DPP](https://vocabulary.uncefact.org/untp/DigitalProductPassport) | Quality and sustainability characteristics of copper concentrate. |
| [CoppermarkCredential](#coppermarkcredential) | [DCC](https://vocabulary.uncefact.org/untp/DigitalConformityCredential) | Coppermark responsible production assurance. |

#### CopperPassport

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalProductPassport`
- **Purpose:** Quality and sustainability characteristics of copper concentrate.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

#### CoppermarkCredential

- **Extends:** `https://vocabulary.uncefact.org/untp/DigitalConformityCredential`
- **Purpose:** Coppermark responsible production assurance.

  **Version `0.1.0`** (extends UNTP `0.6.1`)

  - _Schema, context, and vocabulary not yet published or registered._

---

<sub>Generated 2026-05-04T05:39:29.119Z from `registers/ext/register.json`.</sub>

---

## How to Register(Ext)

# How to Register an Extension

This guide walks extension owners through the steps required to get a UNTP extension listed in the Credential Extensions (EXT) Register.

If you want to understand how the registry itself is governed (registrar role, agent operation, dispute and retention policy), see the [Governance](./governance.md) document. If you simply want to browse already-registered extensions, see the [register itself](./).

## Who should register

You are a candidate extension owner if your organisation is a **member organisation** that represents the shared interests of multiple constituent organisations and your community needs UNTP credentials with sector-specific or jurisdiction-specific extensions. Eligible owner types include:

- Industry associations
- Standards bodies
- Intergovernmental bodies
- Multi-stakeholder consortia
- Research centres acting on behalf of an industry community

Single companies are **not** eligible owners. Extensions exist to serve communities, not individual vendors. If your need is company-specific, use UNTP core's per-class `@vocab` mechanism documented in the [Extensions Methodology](https://untp.unece.org/docs/tools-and-support/ExtensionsMethodology) — no registration required.

## What you'll get when you're done

- An entry in the EXT Register at `https://registers.uncefact.org/untp/ext/{your-extension-slug}`.
- A UNECE-issued Digital Identity Anchor (DIA) credential about your owner DID, hosted on your register entry.
- Continuous, automated drift detection by the UNTP registrar agent — your published schema, context, and vocabulary are hashed on every cycle and any silent change is flagged.
- Discoverability for software vendors, conformity assessment bodies, and community activations selecting extensions to support.

## Quick summary

The full process boils down to three things:

1. **Publish an owner DID** at a domain you control (typically `did:web:yourdomain.org`).
2. **Publish your extension schema, JSON-LD context, and vocabulary** at stable URIs you control. The context MUST import the UNTP context at exactly the version your extension extends.
3. **Issue a registration Verifiable Credential** describing your extension and pointing at the schema/context/vocabulary URIs, and notify UNECE.

The registrar agent does the rest: fetches the documents, hashes them, runs UNTP extension-conformance checks (UNTP context required, all terms resolved, no UNTP redefinitions, samples validate), and writes signed observations.

## Prerequisites

Before you start, you'll need:

| Item | Notes |
|---|---|
| A web domain you control | Required for `did:web` and for hosting your extension artefacts. |
| Ability to host static linked-data documents | JSON Schema, JSON-LD context, RDF/SKOS vocabulary, sample VCs. |
| A defined community use case | What credential type does your community need? What does it extend? |
| Familiarity with the [UNTP specification](https://untp.unece.org/docs/specification/) | Especially the credential type your extension extends and the [Extensions Methodology](https://untp.unece.org/docs/tools-and-support/ExtensionsMethodology). |
| A representative who can liaise with UNECE | For initial onboarding and any future disputes. |

You do **not** need:

- A formal vote or charter from your members before registering. Registration is on intent.
- Pre-existing UNTP-conformant software for your members. The agent observes the extension itself, not its implementations.
- A complete vocabulary on day one. You can register at `proposed` and progress as you publish.

## Step-by-step

### Step 1 — Get in touch with UNECE

Tell UNECE you intend to publish a UNTP extension. UNECE will create a `proposed` register entry as a placeholder while you set up your DID and develop your artefacts. There is no review or approval gate at this stage — proposals are accepted on intent.

You'll receive a placeholder DID and a slug for your extension entry; both will be replaced once you publish your real DID and registration VC.

### Step 2 — Publish your owner DID

Stand up `did:web:yourdomain.org` (or another DID method you prefer). Your DID Document must include at least one `assertionMethod` verification method usable to sign Verifiable Credentials.

Notify UNECE of your DID URL. UNECE will replace the placeholder DID on your entry, and shortly after will issue a UNECE-signed DIA credential about your DID — this is the trust anchor that downstream verifiers use to confirm your extension is duly registered.

### Step 3 — Identify what credential types you're defining

For each credential type your extension defines:

- Pick a `credentialType` name (e.g. `DigitalBatteryPassport`, `LivestockDigitalProductPassport`). Use PascalCase. The name becomes a class IRI under your domain and an entry in the credential's `type` array.
- Identify which UNTP base credential type it extends. The choices are: `DigitalProductPassport`, `DigitalConformityCredential`, `DigitalTraceabilityEvent`, `DigitalFacilityRecord`, or `DigitalIdentityAnchor`. Each registered extension MUST extend one of these (or another already-registered extension credential).
- Decide which UNTP version you'll extend (e.g. `0.7.0`). The extension is locked to this UNTP version until you publish a new extension version.

You can register multiple credential types under one extension entry.

### Step 4 — Develop the schema, context, and vocabulary triple

For each credential type and version, publish three documents at stable URIs:

| Document | What it does | Example URI |
|---|---|---|
| **JSON Schema** | Defines the credential's structure (required and optional properties). | `https://yourdomain.org/extensions/your-ext/0.1.0/YourCredential.schema.json` |
| **JSON-LD context** | Maps each property name to an RDF IRI. MUST import the UNTP context at the declared version. MUST NOT redefine any UNTP term. | `https://yourdomain.org/extensions/your-ext/0.1.0/your-context.jsonld` |
| **Vocabulary** | RDF or SKOS document defining the meaning of every term your context introduces. | `https://yourdomain.org/extensions/your-ext/0.1.0/your-vocabulary.ttl` |

Once published, **never edit a versioned URI's content**. Mint a new version instead. The agent records content hashes on first observation and detects any later drift.

The context can declare an `@vocab` catch-all for terms that an implementer may add that are NOT defined in either your vocabulary or UNTP — but every term your extension itself uses must be properly defined in your vocabulary or context.

### Step 5 — Publish at least one sample instance per credential type

For each credential type, publish at least one sample VC instance at a stable URI. Two samples per type are recommended; negative-test samples (samples that should fail validation, marked `isExpectedPass: false`) improve coverage.

Each sample should illustrate a real-world scenario (a typical use case for the credential). The agent fetches and validates samples on every cycle; sample-validation failures appear in your conformance observation.

### Step 6 — Issue your registration VC

Sign a Verifiable Credential whose `credentialSubject` matches the `ExtensionEntry` shape (per [`register-schema.json`](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/ext/register-schema.json)) including:

- Your extension name, statement, industry sector, geographic scope.
- Your owner type (industry-association, standards-body, intergovernmental, consortium, research-centre).
- Each credential type, what it extends, and the schema/context/vocabulary URIs.
- Sample URIs and metadata.
- Optional co-owners (for jointly governed extensions).

Host the VC at a stable URI you control (e.g. `https://yourdomain.org/.well-known/untp/ext/registration-vc.json`). Notify UNECE of the URI.

### Step 7 — First observation

The registrar agent fetches your registration VC, verifies the signature, fetches your schema/context/vocabulary documents, hashes them, and runs the conformance checks. If everything passes and you have at least one sample per credential type, status moves to `pilot`.

You can ask UNECE for a faster-than-cyclical first observation; otherwise it runs at the next scheduled cycle (typically within a week).

## What gets verified

These are the conformance checks the agent runs on every cycle. Pass these and your status holds.

| Check | What you need to do to pass |
|---|---|
| Registration VC signature valid | Keep your DID Document's verification methods current; re-sign and re-publish your VC after any key rotation. |
| Schema hash match | Treat published schema documents as immutable. Edits = new versions, never overwrites. |
| Context hash match | Same for context documents. |
| Vocabulary hash match | Same for vocabulary documents. |
| UNTP context required | Your extension context must import the UNTP context at exactly the `extendsUntpVersion` you declared. |
| Extension context defined | You must publish your own context document (you can't only reuse the UNTP context). |
| All terms resolved | Every property in your schema must resolve to a definition either via your context/vocabulary or via UNTP's. |
| No UNTP redefinitions | Your context must not redefine any term defined in the UNTP context. |
| `@vocab` catch-all scope | If you declare `@vocab`, it must only catch terms outside both your vocabulary and the UNTP vocabulary. |
| Samples validate | Each `isExpectedPass: true` sample must validate against your schema; each `isExpectedPass: false` sample must fail as declared. |

A small failure (e.g. one sample issue) yields `partially-conformant`. A fatal failure (signature, hash, redefinition, term resolution) yields `non-conformant`. The agent records exactly which checks failed.

## After registration: the lifecycle

```mermaid
stateDiagram-v2
  [*] --> proposed
  proposed --> development
  development --> pilot
  pilot --> active
  pilot --> dormant
  active --> dormant
  active --> withdrawn
  dormant --> pilot
  dormant --> withdrawn
  withdrawn --> [*]
```

After your initial registration:

- The agent re-fetches your published documents on every cycle (typically weekly).
- Drift in your published documents (changes to a hash, broken term references, etc.) is detected automatically and surfaces as observation failures.
- Your status reflects the latest observation — no human review or re-submission is required.

## Maintaining your registration

### Publishing a new extension version

A version in this register is the unit at which schemas, hashes, and observations are tracked. To publish a new version of one of your credential types:

1. Mint a new `versionLabel` (e.g. `0.2.0`). Use SemVer or a calendar scheme — your choice, just be consistent.
2. Mint a new stable URI for each new schema/context/vocabulary document. **Do not edit the previous version's documents.** Old implementers must continue to resolve the old hashes.
3. Decide whether the new version still extends the same UNTP version. If you're upgrading to a new UNTP core version, set `extendsUntpVersion` accordingly and re-test against the new core context.
4. Update samples for the new version (or document explicitly that the old samples remain valid).
5. Re-issue your registration VC with the new version appended to the `versions[]` array. Keep prior versions in the array — the register is append-only.
6. Notify UNECE if you want a faster-than-cyclical update; otherwise the next cycle picks it up.

The agent treats each version independently: an old version remaining `conformant` does not depend on the new version passing.

### Rotating keys

If you need to rotate the signing key your DID controls:

1. Update your DID Document's verification methods.
2. Re-sign your registration VC with the new key.
3. Re-publish the VC at the same URI.

The agent re-verifies the registration VC on every cycle. There is a brief window where an in-flight observation may fail signature validation; the next cycle will succeed.

### Withdrawing

You may exit at any time. Tell UNECE; your entry is marked `withdrawn`. Historical observations are retained for audit. Your published schema/context/vocabulary URIs should remain reachable for a reasonable transition period to avoid breaking historical credentials that reference them.

## Disputes

If you disagree with an observation about your extension:

1. Fetch the `registrarAttestation` linked from the observation. It points to a signed VC the agent issued, with all check details.
2. If you can demonstrate the check was incorrect (e.g. transient fetch failure, clock-skew issue, misinterpretation of a conformance rule), file a dispute with UNECE.
3. UNECE re-runs the relevant validation independently. If your dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. If the disagreement concerns *interpretation* of a conformance rule (rather than the data), the change goes through the formal change-control process described in the [Governance](./governance.md#change-control) document.

## Common questions

**What if my industry doesn't already have a UNTP extension?**
You're a candidate to create one if you represent the shared interests of multiple member organisations. Get in touch with UNECE; the [Community Activation Program](https://untp.unece.org/docs/governance/CommunityActivationProgram) is a structured path for industry associations leading new extensions.

**Can my extension extend another community's extension?**
Yes. The schema permits an `ExtensionCredential` whose `extends` URI points at another registered extension credential rather than a UNTP core type. The `rdfs:subPropertyOf rdfs:subClassOf` relationship makes inheritance transitive.

**Two communities want to define the same credential type. Who wins?**
Both can register. The disambiguation is by extension context URI, not by `credentialType` name alone. Verifiers resolve types via the credential's `@context` array. We recommend communities check the existing register before defining a new credential type and prefer convergence where possible.

**Is there a fee?**
There is likely to be a minimal registration fee that is used to maintain register integrity on a non-for-profit basis. The actual fee structure will be determined before UNTP version 1.0 release.

**What happens if the UNTP core version I extend gets superseded?**
Your existing extension version remains valid against the UNTP version it was registered under. To support a new UNTP core version, mint a new extension version with `extendsUntpVersion` set to the new core version.

**Do I need to publish my schema as machine-readable JSON Schema?**
Yes. The agent validates samples against the schema; samples are how the schema gets exercised. A free-text specification document doesn't satisfy the conformance checks.

## Where to get help

- **The Extensions Methodology:** [https://untp.unece.org/docs/tools-and-support/ExtensionsMethodology](https://untp.unece.org/docs/tools-and-support/ExtensionsMethodology)
- **Sample registered extensions:** see the [register itself](./)
- **Direct contact:** raise an issue on the [UNTP specification repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), or reach out via the UNTP mailing list or UNTP slack channel (join via the links on the home page).

---

## Registry Governance(Idr)

# UNTP Identifier Scheme Register — Governance

This document describes how the UNTP Identifier Scheme (IDR) Register is governed: its purpose, how the registrar agent maintains it, the trust model, retention and dispute policy, and how the register relates to the other UNTP registers (and to the GRID authoritative tier).

If you are an **identifier scheme operator** (a standards body, industry association, facility data service, or similar) looking for step-by-step instructions to register your scheme, see the [Registration Guide](./registration-guide.md).

If you are an **implementer or verifier** looking up registered identifier schemes, see the [register itself](./).

## Purpose

The IDR Register has **two distinct purposes**:

1. **Discovery directory.** Given an identifier in any UNTP credential, a verifier can find the scheme that issued it, learn its format, and construct a resolver URL to fetch verifiable data about the identified entity. The register answers: "What is this identifier, who governs it, where do I look it up?"
2. **Trust anchor.** UNECE issues a Digital Identity Anchor (DIA) credential about each registered scheme operator. When the operator then issues its own DIAs to its registered entities (e.g. an industry association issues a DIA to each member), a verifier can chain trust from UNECE → operator → entity.

The register is the **community/informal tier** of the identifier landscape. Schemes with formal national or treaty-based statutory authority — national business registers, land registers, government asset registers, trademark registers — belong in [GRID](https://grid.unece.org/) (the strictly governed authoritative tier). Together IDR and GRID cover the full identifier landscape that UNTP credentials reference; the cross-tier link is `mirrorsAuthoritativeRegister` on each IDR entry where applicable.

## How authority is shared

Authority is layered:

- **Scheme operators** publish a DID, issue a registration VC committing to maintain a UNTP-conformant resolver service, and (optionally) issue DIA credentials to their registered entities.
- **UNECE** (the registrar) issues a DIA credential about each operator's DID anchoring identity and the scheme operated, periodically tests resolvers, and writes signed observations.

Neither party can act unilaterally. Operators publish; UNECE attests; verifiers trust the chain.

This model gives:

- **Operator independence** — each scheme operator continues to govern its own identifier scheme. UNECE doesn't replace any of them — it indexes them and attests their existence.
- **Trust chain anchoring** — a verifier looking at an operator-issued DIA-about-a-member needs to know that the operator itself is a legitimate registered scheme operator. Without UNECE's DIA-about-the-operator at the top of the chain, every member-DIA is just an assertion.
- **Discovery** — given an arbitrary identifier string, how does a verifier know which scheme issued it? The IDR register gives every UNTP-aware verifier a single endpoint to look up identifier schemes by pattern-matching against registered patterns and templates.

## Roles

| Role | Identity | Responsibilities |
|---|---|---|
| **Registrar** | UNECE | Owns the IDR register; defines policy; issues DIA credentials about registered scheme operators; operates the registrar agent; mediates disputes. |
| **Registrar Agent** | `did:webvh:untp.unece.org` | Crawls each scheme's `registryServiceURL` and `resolverEndpoint`; verifies registration VC signatures; tests UNTP IDR conformance and DIA issuance where claimed; signs observations. |
| **Scheme Operator** | Operator DID (e.g. `did:web:operator.example`) | Operates the identifier scheme. See the [Registration Guide](./registration-guide.md) for the full operator-facing process. |
| **Registered Entity** | Entity-level DID or scheme identifier (e.g. a member with a scheme-issued ID) | Consumer of the operator's DIA credentials. Not part of IDR governance, but the audience the trust chain serves. |
| **GRID Registrar** | (Out of scope here, lives at `grid.unece.org`) | Operates the parallel authoritative-tier register. IDR entries optionally cross-reference GRID entries via `mirrorsAuthoritativeRegister`. |
| **Verifier** | n/a | Consumes IDR entries to interpret identifiers in DPPs, DCCs, DTEs, DFRs, and DIAs. |

## What the agent verifies

These are the checks the registrar agent runs on every cycle. The operator-facing perspective on these checks (and how to satisfy them) is in the [Registration Guide](./registration-guide.md#what-gets-verified).

| Check | What it verifies |
|---|---|
| **Registration VC signature valid** | The registration VC verifies against the operator DID's current verification methods. |
| **Registry URL reachable** | The operator's `registryServiceURL` returns content. |
| **Identifier pattern compiles** | `registeredIdPattern` is a valid regex and `registeredIdExample` matches it. |
| **Resolver template resolves** | A test resolution using `registeredIdExample` against `resolverEndpoint` returns a 2xx response. |
| **UNTP IDR conformant** *(when `implementsUntpIdr: true`)* | Resolver response conforms to the UNTP IDR specification (linkset format, link relations, content types). |
| **DIA issuance verified** *(when `issuesDia: true`)* | Sample resolution returns a DIA credential or a verifiable link to one; the DIA's signature verifies. |
| **DIA extension consistency** *(when `diaExtension` present)* | The referenced EXT register entry exists and is `pilot` or better; the issued DIA's `type` array includes the extension type. |
| **GRID cross-reference resolves** *(when `mirrorsAuthoritativeRegister` present)* | The referenced GRID entry exists. |

A small failure (e.g. one broken URI template) yields `partially-conformant`. A fatal failure (signature, registry unreachable, claimed-but-absent DIA issuance) yields `non-conformant`.

## Identity, Document, and Credential Relationships

```mermaid
flowchart LR
  subgraph Operator["Scheme Operator"]
    OperatorDID["Operator DIDdid:web:operator.example"]
    OperatorKey[("OperatorSigning Key")]
    RegVC["Registration VCcredentialSubject = IdentifierSchemeEntry"]
    RegistryService["Registry Serviceat registryServiceURL"]
    Resolver["Resolver Endpoint(UNTP IDR-conformant)"]
    MemberDIA["Member DIA(per registered entity)"]
  end

  subgraph Entities["Registered Entities"]
    Member["Member organisatione.g. scheme-id-001234"]
  end

  subgraph Registrar["UNECE Registrar"]
    UnRegistrarDID["UNECE Registrar DIDdid:webvh:untp.unece.org"]
    UnRegistrarKey[("UNECESigning Key")]
    RegistrarDIA["Registrar DIA(UNECE → Operator)"]
    AgentDID["Registrar Agent DIDdid:webvh:untp.unece.org"]
    Observation["Conformance Observation VC"]
    IdrRegister[("IDR Registerregister.json")]
  end

  subgraph Consumers["Downstream Consumers"]
    DPP["DPP referencingscheme-issued ID incredentialSubject.issuer"]
    Verifier["Verifier resolves ID,chains DIAs back to UNECE"]
  end

  OperatorKey -. controls .-> OperatorDID
  UnRegistrarKey -. controls .-> UnRegistrarDID
  UnRegistrarKey -. controls .-> AgentDID

  OperatorDID -- signs --> RegVC
  RegVC -- references --> RegistryService
  RegVC -- declares --> Resolver
  RegistryService -- contains --> Member
  Resolver -- resolves --> Member
  OperatorDID -- signs --> MemberDIA
  MemberDIA -- about --> Member

  UnRegistrarDID -- signs --> RegistrarDIA
  RegistrarDIA -- about --> OperatorDID

  AgentDID -- fetches --> RegVC
  AgentDID -- crawls --> RegistryService
  AgentDID -- tests --> Resolver
  AgentDID -- samples --> MemberDIA
  AgentDID -- signs --> Observation
  Observation -- recorded in --> IdrRegister
  RegistrarDIA -- hosted on --> IdrRegister

  DPP -- contains identifier --> Member
  Verifier -- looks up scheme --> IdrRegister
  Verifier -- chains trust --> RegistrarDIA
  Verifier -- verifies --> MemberDIA
```

**How to read the diagram:**

- **Solid arrows** are runtime data references or signatures.
- **Dotted arrows** are key-control (which private key controls which DID).
- **The trust chain runs UNECE → Operator → Entity.** UNECE signs the registrar DIA about the operator. The operator signs DIAs about its members. A verifier, given a member's identifier in a DPP, can chase the chain all the way back to UNECE without trusting any single party blindly.
- **The registrar DIA is hosted on the IDR register.** Verifiers fetch it from the register entry, not from UNECE's website — the register IS the trust anchor publication channel.
- **The resolver is the discovery surface.** Verifiers don't need to know the operator's DID up front; they encounter an identifier, look up its scheme in the IDR register, and use the resolver template to fetch identification data.

## Trust boundaries and failure modes

| Threat | Mitigation |
|---|---|
| Operator publishes a registration VC pointing at a registry they don't control. | DID-bound signature; UNECE verifies operator DID legitimacy through the registrar DIA issuance process before publishing the registrar DIA. |
| Operator silently changes resolver behaviour after registration. | Agent re-tests `resolverEndpoint` on every crawl; behavioural drift flagged. |
| Operator key compromise. | Rotate the DID Document's verification methods; agent re-validates the registration VC on each cycle; UNECE re-issues the registrar DIA after confirming the rotation. |
| Operator claims `issuesDia: true` but doesn't actually issue DIAs. | Agent samples a known registered identifier and tests resolution; failure flagged. |
| Operator issues fraudulent DIAs about non-members. | Out of scope for the registrar agent (it samples but doesn't audit completeness). Operator governance is responsible. |
| Member DIA chain breaks (member-DIA's issuer doesn't match the registered operator DID). | Verifier-side check, not registrar-side. The IDR register publishes the operator DID; verifiers reject DIAs whose issuer doesn't match. |
| Confusion between IDR and GRID for a scheme. | Use `mirrorsAuthoritativeRegister` to make the cross-tier relationship explicit when applicable. |
| Identifier collision between two schemes. | Avoid by URI scope: every IDR entry's `registeredIdUriTemplate` produces a different absolute URI namespace. Identifiers are disambiguated by scheme URI, not by raw value. |

## Disputes

The registry's dispute-handling process:

1. Each `ConformanceObservation` includes a `registrarAttestation` linking to the signed VC the agent issued.
2. The operator files a dispute with UNECE; UNECE re-runs the relevant check independently.
3. Outcome is recorded — original retained, amendment linked back. Retractions are not silent.
4. Disagreements about IDR specification interpretation follow the change-control process below.

The operator-facing perspective (what to do if you disagree with an observation) is in the [Registration Guide](./registration-guide.md#disputes).

## Cadence and retention

- **Crawl cycle:** the registrar agent runs at least daily for active schemes; pilot and dormant schemes may be sampled less frequently.
- **Retention:** observations are append-only and retained indefinitely. Retracted observations are marked, not deleted.
- **Dormant trigger:** 12 months without a registration VC update or detected scheme activity (no resolver use, no DIA issuance signals).
- **Register publication:** `register.json` is regenerated on every observation cycle and published at `https://registers.uncefact.org/untp/idr/register.json`. Per-entry URIs are content-negotiated to return HTML, JSON-LD, or Turtle.

## Relationship to other registers

- **GRID (`grid.unece.org/`)** — the strictly governed authoritative tier. National business registers, land registers, government asset registers, trademark registers belong there. Where an IDR community scheme mirrors or derives authority from a GRID entry (e.g. a national member registry that aligns with the country's official business registry), use `mirrorsAuthoritativeRegister` to link them. This is the most important cross-register link in the IDR design.
- **[Software Implementers Register (SWI)](../swi/governance.md)** — when a SWI-listed software issues a UNTP credential containing an identifier from an IDR scheme, the SWI agent's observation cycle uses the IDR register to resolve and validate the identifier.
- **[Credential Extensions Register (EXT)](../ext/governance.md)** — when an operator runs a DIA-issuing scheme using a community extension (e.g. an industry-association member DIA using an extended DIA type), the operator references the extension entry via `diaExtension`. The agent cross-validates.
- **[Conformity Vocabulary Catalogue (CVC)](../cvc/governance.md)** — independent of IDR. CVC catalogues conformity assessment criteria; IDR catalogues identifier schemes. They intersect when a CVC scheme's vocabulary references organisations identified by an IDR-registered scheme.

## Change control

Changes to this governance document, the IDR register schema, or the conformance check rules are managed under the UN/CEFACT Open Development Process and announced on the UNTP specification site at least 30 days before taking effect. Material changes that would invalidate currently-conformant scheme entries are subject to a longer notice window (typically 90 days) and a migration guide.

Changes to the underlying [UNTP Identity Resolver specification](https://untp.unece.org/docs/specification/IdentityResolver) — the spec operator resolver services conform to — follow the standard UNTP versioning process. Existing schemes remain conformant against the IDR spec version they declared in `untpIdrVersion`; upgrading is opt-in.

Feedback on the rules or ambiguities should be filed as an issue on the UNTP specification repository or sent to UNECE through the usual channels.

---

## Identifier Schemes

# UNTP Identifier Scheme Register

This page provides a summary of identifier scheme operators that have committed to publish their scheme as a UNTP-discoverable register and (optionally) issue Digital Identity Anchor credentials to their registered entities. As described in the UNTP [Identity Resolver](../../specification/IdentityResolver.md) and [Digital Identity Anchor](../../specification/DigitalIdentityAnchor.md) specifications, this is a key activity for standards bodies, industry associations, and facility data services that want their identifiers to be resolvable and verifiable across UNTP credentials. The register complements GRID (https://un.opensource.unicc.org/unece/uncefact/gtr/) which catalogues authoritative government-run registers (national business registers, land, asset, trademark).

## This Register

This register is maintained as a structured data set that can be read by machines or by humans.

| Field | Value |
| --- | --- |
| Register ID | `https://registers.unece.org/untp/idr` |
| Register Data | [JSON-LD register file](/registers/idr/register.json), [JSON Schema](/registers/idr/register-schema.json). Note — to be published as a linked-data vocabulary at registers.unece.org before UNTP v1.0 release. |
| Registrar | United Nations Economic Commission for Europe (UNECE) (`https://unece.org`) |
| Registrar DID | `did:webvh:untp.unece.org` |

## Summary of Registered Identifier Schemes

| Scheme | Operator | Identifies | Geography | UNTP IDR | Issues DIA | Status |
| --- | --- | --- | --- | :-: | :-: | --- |
| [GS1 Global Trade Item Number](#gs1-global-trade-item-number) | GS1 | `Product` | Worldwide | ✓ yes | ✓ yes | 🔵 Pilot |
| [GS1 Global Location Number](#gs1-global-location-number) | GS1 | `Facility` | Worldwide | ✓ yes | ✓ yes | 🔵 Pilot |
| [GS1 Global Individual Asset Identifier](#gs1-global-individual-asset-identifier) | GS1 | `Asset` | Worldwide | ✓ yes | ✓ yes | 🔵 Pilot |
| [Open Supply Hub Identifier](#open-supply-hub-identifier) | Open Supply Hub | `Facility` | Worldwide | ✓ yes | ✓ yes | 🔵 Pilot |
| [Responsible Business Alliance Member ID](#responsible-business-alliance-member-id) | Responsible Business Alliance | `Member` | Worldwide | ✓ yes | ✓ yes | 🔵 Pilot |
| [Global Battery Alliance Member ID](#global-battery-alliance-member-id) | Global Battery Alliance | `Member` | Worldwide | ✓ yes | ✓ yes | 🔵 Pilot |

## Identifier Scheme Entries

## GS1 Global Trade Item Number

**Status:** 🔵 Pilot  •  **Short name:** GTIN  •  **Identifies:** `Product`

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/idr/gs1-gtin` |
| Operator | GS1 (`did:web:placeholder-domain.com:untp:idr:gs1`) |
| Operator website | https://www.gs1.org |
| Registry service URL | https://id.gs1.org/ |
| Documentation | https://www.gs1.org/standards/id-keys/gtin |
| Geography | Worldwide |
| Legal basis | https://www.gs1.org/standards/id-keys/gtin |

**Statement**

> GTIN is a globally unique identifier for trade items (products and services). GTINs are 8, 12, 13, or 14 digits long and are encoded in GS1 barcodes and EPC/RFID tags. They are used to identify any item upon which there is a need to retrieve pre-defined information and that may be priced, ordered, or invoiced at any point in the supply chain.

**Identifier format**

| | |
| --- | --- |
| Pattern | `^\d{8}$|^\d{12,14}$` |
| Example | `09506000164908` |
| Canonical URI template | `https://id.gs1.org/01/{id}` |
| UNTP IDR resolver template | `https://id.gs1.org/01/{id}` |
| Human query template | `https://www.gs1.org/services/check-digit-calculator?value={id}` |

**UNTP conformance**

| Capability | Declared |
| --- | :-: |
| Implements UNTP IDR specification | ✓ yes |
| UNTP IDR version | `0.6.1` |
| Issues DIA credentials to registered entities | ✓ yes |

_Registrar DIA not yet issued by UNECE (Phase 1 outreach pending)._

---

## GS1 Global Location Number

**Status:** 🔵 Pilot  •  **Short name:** GLN  •  **Identifies:** `Facility`

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/idr/gs1-gln` |
| Operator | GS1 (`did:web:placeholder-domain.com:untp:idr:gs1`) |
| Operator website | https://www.gs1.org |
| Registry service URL | https://id.gs1.org/ |
| Documentation | https://www.gs1.org/standards/id-keys/gln |
| Geography | Worldwide |
| Legal basis | https://www.gs1.org/standards/id-keys/gln |

**Statement**

> GLN is a 13-digit globally unique identifier for legal entities, functional entities, and physical locations. Used to identify parties and locations in electronic commerce, supply chain management, and healthcare.

**Identifier format**

| | |
| --- | --- |
| Pattern | `^\d{13}$` |
| Example | `9506000164000` |
| Canonical URI template | `https://id.gs1.org/417/{id}` |
| UNTP IDR resolver template | `https://id.gs1.org/417/{id}` |
| Human query template | `https://www.gs1.org/services/check-digit-calculator?value={id}` |

**UNTP conformance**

| Capability | Declared |
| --- | :-: |
| Implements UNTP IDR specification | ✓ yes |
| UNTP IDR version | `0.6.1` |
| Issues DIA credentials to registered entities | ✓ yes |

_Registrar DIA not yet issued by UNECE (Phase 1 outreach pending)._

---

## GS1 Global Individual Asset Identifier

**Status:** 🔵 Pilot  •  **Short name:** GIAI  •  **Identifies:** `Asset`

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/idr/gs1-giai` |
| Operator | GS1 (`did:web:placeholder-domain.com:untp:idr:gs1`) |
| Operator website | https://www.gs1.org |
| Registry service URL | https://id.gs1.org/ |
| Documentation | https://www.gs1.org/standards/id-keys/giai |
| Geography | Worldwide |
| Legal basis | https://www.gs1.org/standards/id-keys/giai |

**Statement**

> GIAI is a globally unique identifier for individual assets — production machinery, vehicles, IT equipment, instruments, returnable transport items. The GIAI persists across the asset's operating lifetime and is the primary handle for asset-level lifecycle events (maintenance, retrofit, decommission) recorded in DTEs.

**Identifier format**

| | |
| --- | --- |
| Pattern | `^\d{6,12}[\x21-\x22\x25-\x2F\x30-\x39\x3A-\x3F\x41-\x5A\x5F\x61-\x7A]{1,18}$` |
| Example | `9506000164ABCD123` |
| Canonical URI template | `https://id.gs1.org/8004/{id}` |
| UNTP IDR resolver template | `https://id.gs1.org/8004/{id}` |
| Human query template | `https://www.gs1.org/services/check-digit-calculator?value={id}` |

**UNTP conformance**

| Capability | Declared |
| --- | :-: |
| Implements UNTP IDR specification | ✓ yes |
| UNTP IDR version | `0.6.1` |
| Issues DIA credentials to registered entities | ✓ yes |

_Registrar DIA not yet issued by UNECE (Phase 1 outreach pending)._

---

## Open Supply Hub Identifier

**Status:** 🔵 Pilot  •  **Short name:** OS-ID  •  **Identifies:** `Facility`

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/idr/open-supply-hub` |
| Operator | Open Supply Hub (`did:web:placeholder-domain.com:untp:idr:open-supply-hub`) |
| Operator website | https://opensupplyhub.org |
| Registry service URL | https://opensupplyhub.org/ |
| Documentation | https://opensupplyhub.org/about |
| Geography | Worldwide |
| Legal basis | https://opensupplyhub.org/about/governance |

**Statement**

> Open Supply Hub assigns a stable OS-ID to every production facility in its open data set, derived from name and address matching across thousands of public and contributed sources. OS-IDs persist across name changes and ownership transitions and provide the canonical identifier for cross-source facility joins in apparel, electronics, and food supply chains.

**Identifier format**

| | |
| --- | --- |
| Pattern | `^[A-Z0-9]{15}$` |
| Example | `AU2020026CXFBN8` |
| Canonical URI template | `https://opensupplyhub.org/facilities/{id}` |
| UNTP IDR resolver template | `https://opensupplyhub.org/api/facilities/{id}/` |
| Human query template | `https://opensupplyhub.org/facilities/{id}` |

**UNTP conformance**

| Capability | Declared |
| --- | :-: |
| Implements UNTP IDR specification | ✓ yes |
| UNTP IDR version | `0.6.1` |
| Issues DIA credentials to registered entities | ✓ yes |

_Registrar DIA not yet issued by UNECE (Phase 1 outreach pending)._

---

## Responsible Business Alliance Member ID

**Status:** 🔵 Pilot  •  **Short name:** RBA-Member  •  **Identifies:** `Member`

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/idr/rba-member` |
| Operator | Responsible Business Alliance (`did:web:placeholder-domain.com:untp:idr:rba`) |
| Operator website | https://www.responsiblebusiness.org |
| Registry service URL | https://www.responsiblebusiness.org/membership/ |
| Documentation | https://www.responsiblebusiness.org/about/members/ |
| Geography | Worldwide |
| Legal basis | https://www.responsiblebusiness.org/code-of-conduct/ |

**Statement**

> The RBA Member ID identifies organisations that have joined the Responsible Business Alliance and committed to its Code of Conduct. Membership identifiers are issued by RBA on accession and persist across reporting periods. Used to anchor RBA-assessed facility records (VAP), responsible-minerals attestations (RMAP), and supply-chain due diligence claims back to a verified industry-association membership.

**Identifier format**

| | |
| --- | --- |
| Pattern | `^RBA-\d{6}$` |
| Example | `RBA-001234` |
| Canonical URI template | `https://www.responsiblebusiness.org/members/{id}` |
| UNTP IDR resolver template | `https://www.responsiblebusiness.org/members/{id}` |
| Human query template | `https://www.responsiblebusiness.org/members/{id}` |

**UNTP conformance**

| Capability | Declared |
| --- | :-: |
| Implements UNTP IDR specification | ✓ yes |
| UNTP IDR version | `0.6.1` |
| Issues DIA credentials to registered entities | ✓ yes |
| DIA extension used | https://registers.uncefact.org/untp/ext/rbtp |

_Registrar DIA not yet issued by UNECE (Phase 1 outreach pending)._

---

## Global Battery Alliance Member ID

**Status:** 🔵 Pilot  •  **Short name:** GBA-Member  •  **Identifies:** `Member`

| Field | Value |
| --- | --- |
| Entry ID | `https://registers.uncefact.org/untp/idr/gba-member` |
| Operator | Global Battery Alliance (`did:web:placeholder-domain.com:untp:idr:gba`) |
| Operator website | https://www.globalbattery.org |
| Registry service URL | https://www.globalbattery.org/members/ |
| Documentation | https://www.globalbattery.org/about/membership/ |
| Geography | Worldwide |
| Legal basis | https://www.globalbattery.org/about/charter/ |

**Statement**

> The GBA Member ID identifies organisations participating in the Global Battery Alliance — battery manufacturers, automakers, mining and refining companies, recyclers, and downstream users. Membership identifiers anchor GBA Battery Passport assertions and Battery Sustainability Certificates back to a verified GBA-participating organisation.

**Identifier format**

| | |
| --- | --- |
| Pattern | `^GBA-\d{4}$` |
| Example | `GBA-0123` |
| Canonical URI template | `https://www.globalbattery.org/members/{id}` |
| UNTP IDR resolver template | `https://www.globalbattery.org/members/{id}` |
| Human query template | `https://www.globalbattery.org/members/{id}` |

**UNTP conformance**

| Capability | Declared |
| --- | :-: |
| Implements UNTP IDR specification | ✓ yes |
| UNTP IDR version | `0.6.1` |
| Issues DIA credentials to registered entities | ✓ yes |
| DIA extension used | https://registers.uncefact.org/untp/ext/gba-tp |

_Registrar DIA not yet issued by UNECE (Phase 1 outreach pending)._

---

<sub>Generated 2026-05-04T05:39:29.161Z from `registers/idr/register.json`.</sub>

---

## How to Register(Idr)

# How to Register an Identifier Scheme

This guide walks scheme operators through the steps required to get an identifier scheme listed in the UNTP Identifier Scheme (IDR) Register.

If you want to understand how the registry itself is governed (registrar role, agent operation, dispute and retention policy), see the [Governance](./governance.md) document. If you simply want to browse already-registered schemes, see the [register itself](./).

## Who should register

You are a candidate scheme operator if your organisation runs a registry that identifies products, facilities, organisations, members, locations, or key assets that appear in UNTP credentials. Typical IDR registrants include:

- Standards bodies operating product, location, or asset identifier schemes
- Industry associations issuing membership IDs
- Facility data services
- Asset registries (e.g. equipment, vehicle, instrument identifiers)

If you operate a register with **statutory authority** under national or treaty-based law (e.g. a national business register, land registry, official customs code list), your register belongs in [GRID](https://grid.unece.org/), not IDR. The two tiers complement each other; cross-tier linking via `mirrorsAuthoritativeRegister` is supported when applicable.

## What you'll get when you're done

- An entry in the IDR Register at `https://registers.uncefact.org/untp/idr/{your-scheme-slug}`.
- A UNECE-issued Digital Identity Anchor (DIA) credential about your operator DID, hosted on your register entry — the **trust anchor** for your scheme.
- (If you issue DIA credentials to your registered entities) a verifiable trust chain UNECE → you → your members, navigable by any UNTP-aware verifier.
- (If you implement the UNTP IDR specification) discovery via every UNTP-aware tool.
- Discoverability for software vendors and community activations choosing identifier infrastructure.

## Quick summary

The full process boils down to three things:

1. **Publish an operator DID** at a domain you control (typically `did:web:yourdomain.org`).
2. **Expose a publicly reachable resolver service URL** with an RFC 6570 URI template that accepts `{id}` as a variable.
3. **Issue a registration Verifiable Credential** describing your scheme, the identifier format, and the resolver template, and notify UNECE.

The registrar agent does the rest: tests your resolver with the example identifier, validates UNTP IDR conformance where claimed, samples DIA credentials issued to your registered entities where claimed, and writes signed observations.

UNECE then issues a DIA credential about your operator DID and hosts it on your register entry — completing the trust anchor.

## Prerequisites

Before you start, you'll need:

| Item | Notes |
|---|---|
| A web domain you control | Required for `did:web` and for hosting your registration VC. |
| A publicly reachable identifier registry service | The base URL the agent crawls + an RFC 6570 resolver URI template. |
| Identifier format declarations | A regex pattern for valid IDs, an example ID, and the canonical URI template per ID. |
| (Optional) A DIA-issuing capability | If you want the trust-anchor pathway, your scheme issues UNTP DIA credentials to its registered entities. |
| A representative who can liaise with UNECE | For initial onboarding and any future disputes. |

You do **not** need:

- A pre-existing UNTP IDR-conformant resolver. You can register at `pilot` with `implementsUntpIdr: false` and migrate later.
- A pre-existing DIA-issuance capability. The trust-anchor pathway is optional but strongly encouraged.
- Statutory authority. If you have it, you belong in GRID; if you don't, IDR is the right home.

## Step-by-step

### Step 1 — Get in touch with UNECE

Tell UNECE you intend to register an identifier scheme. UNECE will create a `proposed` register entry as a placeholder while you set up your DID and verify your resolver. There is no review or approval gate at this stage — proposals are accepted on intent.

You'll receive a placeholder DID and a slug for your scheme entry; both will be replaced once you publish your real DID and registration VC.

### Step 2 — Publish your operator DID

Stand up `did:web:yourdomain.org` (or another DID method you prefer). Your DID Document must include at least one `assertionMethod` verification method usable to sign Verifiable Credentials.

Notify UNECE of your DID URL. UNECE will replace the placeholder DID on your entry, and shortly after will issue a UNECE-signed DIA credential about your DID — this is the **trust anchor** that downstream verifiers use to confirm your scheme is duly registered. The DIA is hosted on your register entry.

### Step 3 — Verify your registry service URL

Confirm that your registry's base URL is publicly reachable and returns useful content (an HTML landing page, an API description, or both). The agent crawls this URL on every cycle to verify reachability.

### Step 4 — Define your identifier format

For your scheme, declare:

- **`registeredIdPattern`** — a regular expression that valid identifiers must match (e.g. `^\d{13}$` for a 13-digit numeric ID).
- **`registeredIdExample`** — an example valid identifier (e.g. `9506000164000`). The agent compiles the regex and tests the example matches.
- **`registeredIdUriTemplate`** — an RFC 6570 URI template for constructing the canonical URI of any registered identifier, with `{id}` as the variable (e.g. `https://id.example.org/scheme/{id}`).

### Step 5 — Define your resolver endpoint

Declare a `resolverEndpoint` URI template (with `{id}`) that resolves an identifier to verifiable data about the identified entity. The agent tests resolution by substituting your `registeredIdExample` into the template and confirming a 2xx response.

If your resolver implements the [UNTP Identity Resolver specification](https://untp.unece.org/docs/specification/IdentityResolver) — returning standard linksets with the documented link relations — set `implementsUntpIdr: true` and declare the spec version (e.g. `0.7.0`). The agent will additionally test conformance.

If your resolver is custom (returns its own response shape), set `implementsUntpIdr: false`. You'll still be listed as a discovery directory entry; you just won't pass the UNTP IDR conformance check.

### Step 6 — (Optional) Configure DIA issuance

If your scheme issues UNTP Digital Identity Anchor credentials to its registered entities (e.g. your members, registered facilities, or registered assets), set `issuesDia: true`.

If you use a community extension for your DIA credentials (e.g. a member DIA using an industry-extended DIA type), reference the extension's entry in the EXT register via `diaExtension`. The agent will cross-validate.

This step is optional but unlocks the **trust anchor pathway** — verifiers can chain trust UNECE → your operator DID → your registered entities, all the way back to the UN level.

### Step 7 — (Optional) Configure GRID cross-tier link

If your community scheme mirrors or derives authority from an authoritative GRID register (e.g. your member registry mirrors a national chamber of commerce business registry), declare it via `mirrorsAuthoritativeRegister` pointing at the GRID entry's URI. The agent verifies the GRID entry exists.

This is the cleanest way to make the cross-tier relationship explicit when your scheme exists in both informal (IDR) and authoritative (GRID) form.

### Step 8 — Issue your registration VC

Sign a Verifiable Credential whose `credentialSubject` matches the `IdentifierSchemeEntry` shape (per [`register-schema.json`](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/idr/register-schema.json)) including:

- Your scheme name, statement, identifier type (Organisation, Product, Facility, Asset, Location, Consignment, Member, or Person).
- The format declarations from Step 4.
- The resolver endpoint and (optionally) UNTP IDR version from Step 5.
- DIA issuance flags from Step 6.
- GRID cross-reference from Step 7.

Host the VC at a stable URI you control (e.g. `https://yourdomain.org/.well-known/untp/idr/registration-vc.json`). Notify UNECE of the URI.

### Step 9 — First crawl

The registrar agent fetches your registration VC, verifies the signature, tests your resolver with the example identifier, runs the conformance checks, and (where `issuesDia: true`) samples a DIA credential. If everything passes, status moves to `pilot` and UNECE issues your registrar DIA.

You can ask UNECE for a faster-than-cyclical first observation; otherwise it runs at the next scheduled cycle (typically within 24 hours).

## What gets verified

These are the conformance checks the agent runs on every cycle. Pass these and your status holds.

| Check | What you need to do to pass |
|---|---|
| Registration VC signature valid | Keep your DID Document's verification methods current; re-sign and re-publish your VC after any key rotation. |
| Registry URL reachable | Use stable hosting; ensure the base URL serves content. |
| Identifier pattern compiles | Make sure your `registeredIdPattern` is a valid regex and `registeredIdExample` matches it. |
| Resolver template resolves | The template substituted with `registeredIdExample` must return a 2xx response. |
| UNTP IDR conformant *(when claimed)* | Resolver returns standard linksets per the IDR specification at the declared version. |
| DIA issuance verified *(when claimed)* | Resolution returns a DIA credential or a verifiable link to one; the DIA's signature verifies against your operator DID. |
| DIA extension consistency *(when claimed)* | The referenced EXT register entry must exist and be `pilot` or better; the issued DIA's `type` array must include the extension type. |
| GRID cross-reference resolves *(when claimed)* | The referenced GRID entry must exist. |

A small failure (e.g. one broken URI template) yields `partially-conformant`. A fatal failure (signature, registry unreachable, claimed-but-absent DIA issuance) yields `non-conformant`. The agent records exactly which checks failed.

## After registration: the lifecycle

```mermaid
stateDiagram-v2
  [*] --> proposed
  proposed --> development
  development --> pilot
  pilot --> active
  pilot --> conformant
  active --> conformant
  active --> dormant
  conformant --> dormant
  dormant --> active
  active --> withdrawn
  conformant --> withdrawn
  dormant --> withdrawn
  withdrawn --> [*]
```

After your initial registration:

- The agent crawls daily for active schemes and writes signed observations on every cycle.
- Drift in your resolver behaviour (changes to response shape, broken template, etc.) is detected automatically and surfaces as observation failures.
- Your status reflects the latest observation — no human review or re-submission is required.

## Maintaining your registration

### Updating your registration metadata

Re-issue your registration VC when scheme metadata changes (e.g. new resolver template, updated documentation URL, change to identifier format, addition of DIA-extension reference). Old VCs are superseded; the agent always uses the latest.

### Upgrading UNTP IDR specification version

When you upgrade your resolver to a new IDR spec version, update `untpIdrVersion` and re-issue the registration VC. The agent re-tests conformance against the new version.

### Rotating keys

If you need to rotate the signing key your DID controls:

1. Update your DID Document's verification methods.
2. Re-sign your registration VC with the new key.
3. Re-publish the VC at the same URI.
4. Notify UNECE — they will re-issue your registrar DIA after confirming the rotation.

The agent re-verifies the registration VC on every cycle. There is a brief window where an in-flight observation may fail signature validation; the next cycle will succeed.

### Withdrawing

You may exit at any time. Tell UNECE; your entry is marked `withdrawn`. Historical observations are retained for audit. Your registry service should remain reachable for a reasonable transition period to avoid breaking historical credentials that contain identifiers from your scheme.

## Disputes

If you disagree with an observation about your scheme:

1. Fetch the `registrarAttestation` linked from the observation. It points to a signed VC the agent issued, with all check details (test queries, resolver responses, DIA samples).
2. If you can demonstrate the check was incorrect (e.g. transient fetch failure, clock-skew issue, misinterpretation of the IDR specification), file a dispute with UNECE.
3. UNECE re-runs the relevant validation independently. If your dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. If the disagreement concerns *interpretation* of an IDR specification rule (rather than the data), the change goes through the formal change-control process described in the [Governance](./governance.md#change-control) document.

## Common questions

**Should I be in IDR or GRID?**
If your registry has statutory authority under national or treaty-based law (e.g. you are designated by legislation as the authoritative national register for some category of entity), you belong in GRID. If your registry has community/industry authority (e.g. you are an industry association or standards body), you belong in IDR. Many schemes are duals — an industry registry that mirrors an authoritative national register — and use both with the cross-tier link.

**My scheme isn't UNTP IDR conformant yet. Can I still register?**
Yes. Set `implementsUntpIdr: false` in your registration VC. You'll be listed as a discovery directory entry. Implement IDR conformance later when you can; the agent will pick up the change on the next cycle after you update your registration VC.

**My scheme doesn't issue DIAs. Can I still register?**
Yes. Set `issuesDia: false`. You're a pure-discovery operator. The trust-anchor pathway just doesn't apply to your scheme.

**I operate multiple schemes. Do I need separate registrations?**
Each scheme is a separate IDR entry, but the operator DID can be shared (e.g. an operator running several identifier schemes can sign each scheme's registration VC with the same DID).

**My scheme is jointly governed. Whose DID signs the registration VC?**
One organisation's DID is the registration signer. If governance is genuinely shared, consider standing up a joint-venture DID at a domain controlled by both parties.

**Is there a fee?**
There is likely to be a minimal registration fee that is used to maintain register integrity on a non-for-profit basis. The actual fee structure will be determined before UNTP version 1.0 release.

## Where to get help

- **The UNTP Identity Resolver specification:** [https://untp.unece.org/docs/specification/IdentityResolver](https://untp.unece.org/docs/specification/IdentityResolver)
- **The Digital Identity Anchor specification:** [https://untp.unece.org/docs/specification/DigitalIdentityAnchor](https://untp.unece.org/docs/specification/DigitalIdentityAnchor)
- **Sample IDR entries:** see the [register itself](./).
- **Direct contact:** raise an issue on the [UNTP specification repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), or reach out via the UNTP mailing list or UNTP slack channel (join via the links on the home page).

---

## Overview

# UNTP Registers — Overview

The UNTP registers are a set of public, UN-maintained directories that catalogue the trusted technical building blocks every UNTP implementation needs: the software platforms, conformity schemes, credential extensions, and identifier services. They exist so your community can **build on what's already trusted, not start from scratch**. 

## The roots that hold the tree up

[UNTP governance](../governance/index.md) is structured as a tree.

![UNTP Implementation Tree](../assets/images/governance-implementation-tree.png)

- The **trunk** is the single UNTP core specification — the universal standard every implementation builds on.
- The **branches** are sectoral collaboration fora where industries (critical minerals, textiles, agriculture, batteries, …) meet to align and harmonise.
- The **leaves** are the community implementations — industry associations and brand alliances rolling UNTP out across their members.
- The **roots** are these registers. They feed the rest of the tree with the trusted, tested components every leaf draws on.

A community that has to commission its own software, define its own conformity vocabulary, build its own identifier resolver, and write a brand-new credential extension before it can issue a single Verifiable Credential is a community that won't activate. The registers exist so activation can begin with **selection** rather than construction. Pick what fits your needs from the catalogue, and ship. Or, if a community member does not find their preferred software tool or identity or conformity scheme in the registers, they can refer them to these pages.  

## The four registers, in plain English

| Register | What it catalogues | What it answers for you |
|---|---|---|
| [**Software Implementers**](./swi/) | Platforms that issue and verify UNTP credentials on behalf of brands, producers, and certifiers. | "Which software vendors can my members use, and is their software actually working as expected?" |
| [**Credential Extensions**](./ext/) | Industry-specific or jurisdiction-specific credential types that extend UNTP core (battery passport, livestock passport, electrical goods passport, etc.). | "Has someone already defined a credential format for my sector, or do I need to lead one?" |
| [**Conformity Schemes**](./cvc/) | Audit, certification, and assessment programmes whose criteria are referenced by UNTP credentials (RBA VAP, RMAP, GBA Battery Passport Rulebook, The Copper Mark, etc.). | "What standards and frameworks are available to back the sustainability claims my members will make?" |
| [**Identifier Schemes**](./idr/) | Identifier services for products, facilities, organisations, members, and key assets (GS1 GTIN, Open Supply Hub, RBA Member ID, etc.). | "Which identifier system should we use for products / facilities / members, and how do verifiers look them up?" |

A community planning to roll out UNTP can browse all four, pick the components that fit their use case, and trust that each has been independently verified — without doing the verification work themselves.

## Why this is faster and cheaper than building from scratch

A typical industry-association deployment of UNTP needs answers to four questions:

1. **What software will my members use to issue credentials?** → look in the [software implementer register](./swi/). If your favourite software is listed then you can confidently use it. If not then ask them to implement.
2. **Does my industry's credential format already exist?** → look in [credential extensions register](./ext/). If you find a match, adopt it. If no, create one and make it available to others.
3. **What conformity schemes back the claims my members make?** → look in [conformity schemes register](./cvc/). If your scheme is listed then you can confidently reference the criterion in your issued credentials. If not then ask them to publish and register a conformity vocabulary.
4. **What identifier schemes do we use for products, facilities, and members?** → look in [identifier schemes register](./idr/). If the identifier scheme you use is listed then you can link your credentials to those identifiers. If not then ask them to implement and register. 

Without the registers, every community does this research independently — different communities arrive at different answers, validation is inconsistent, and integration is painful. With the registers, every community draws from the same trusted catalogue. **Activation moves from research to selection**, and from months of vendor due diligence to a few days of choosing what fits.

## How the registers stay trustworthy

A traditional industry register is a curated list. Someone fills in a form, the registrar reviews it, the entry goes up. Updates need new submissions. Conformance is asserted by the implementer and accepted on faith.

The UNTP registers work differently. Once an implementer is registered, **most of the population and verification of registry details is done automatically by the UNTP validation observer**. The implementer's job is to publish a cryptographic identity, sign a registration credential, and expose their service or vocabulary at a stable URL. From that point, the observer system does the work:

- It crawls the registered services on every observation cycle.
- It verifies the published credentials, schemas, and vocabularies are well-formed and signed correctly.
- It compares what it sees today to what was registered, detecting silent drift.
- It writes a signed conformance observation back to the register.

What this means in practice for your community:

- **Continuous, independent assurance.** Your status reflects observed reality, not asserted intent. If a registered software platform starts shipping non-conformant credentials, the next cycle catches it — your community doesn't have to chase the vendor for a re-test.
- **No bottleneck on updates.** Registered parties update on their own schedule; the agent picks up changes automatically. The registrar's role is to operate the agent and mediate disputes, not to manually review every change.
- **Cryptographic auditability.** Every observation is itself a signed credential, so the audit trail is tamper-evident — no party (including UNECE) can quietly modify history.

This is critical at the scale UNTP is designed for, where millions of independent implementers are expected. Self-attestation does not scale to that many participants — there is no way to manually audit a million conformance claims. Continuous, automated, signed observation by a trusted agent is the only mechanism that gives buyers, regulators, and consumers confidence at scale.

## The trust chain

When you encounter a UNTP credential about a product or facility — say, a sustainability claim made by a manufacturer using software from vendor X under scheme Y — you can chase the chain of trust all the way back:

- The credential's content is verifiable against the **conformity scheme** it references and the **register** confirms the scheme is duly registered and observed.
- The software that issued it is identifiable from a block embedded in every credential and the **register** confirms the software vendor is duly registered, with continuous observation of conformance.
- The identifiers it carries (product, facility, member, etc.) are resolvable to authoritative information and the **register** confirms the identifier scheme operator is duly registered, with a UN-issued identity anchor at the top of the chain.
- If the credential is of an industry-specific type (battery passport, livestock passport, …) the **register** confirms the extension is duly registered with continuously-verified schemas and vocabularies.

The result is a public-good catalogue of trusted, tested UNTP infrastructure that every community activation can draw on. Strong roots, growing tree.

## How to engage

| If you are… | Start here |
|---|---|
| **A member organisation** considering a UNTP rollout for your industry | Read about the [Community Activation Program](../governance/CommunityActivationProgram.md), then browse the four registers to see what already exists for your sector. |
| **A software vendor** wanting to be listed | [How to register your software](./swi/registration-guide.md). |
| **An industry body** planning a sector-specific extension | [How to register an extension](./ext/registration-guide.md). |
| **A conformity scheme owner** wanting your scheme indexed | [How to register a conformity scheme](./cvc/registration-guide.md). |
| **An identifier scheme operator** wanting your scheme indexed | [How to register an identifier scheme](./idr/registration-guide.md). |
| **Curious about the architecture** behind the four registers | The governance documents per register: [SWI](./swi/governance.md) · [EXT](./ext/governance.md) · [CVC](./cvc/governance.md) · [IDR](./idr/governance.md). |

---

## Registry Governance(Swi)

# UNTP Software Implementers Register — Governance

This document describes how the UNTP Software Implementers (SWI) Register is governed: its purpose, how the registrar agent maintains it, the trust model, retention and dispute policy, and how the register relates to the other UNTP registers.

If you are a **software vendor** looking for step-by-step instructions to register your software, see the [Registration Guide](./registration-guide.md).

If you are an **implementer or verifier** looking up registered vendors and software, see the [register itself](./).

## Purpose

The SWI Register answers a single question for any party that encounters a UNTP credential in the wild: **"Which software issued this, and is that software a conformant UNTP implementation?"**

It is an *observatory*, not a certification scheme. The register's authority comes from cryptographically signed observations performed by an autonomous registrar agent against credentials that are already in production use, not from desk reviews or vendor self-attestations.

## How authority is shared

Authority over the register comes from two parties working together:

- **Vendors** publish a vendor DID, embed an `issuingSoftware` block in every credential their software issues (referencing the vendor DID and a stable software-version URI), and optionally operate a binding-credential service that counter-signs credential-to-software bindings.
- **UNECE** (the registrar) operates the registrar agent that discovers credentials in the wild via the Identity Resolver, validates them against UNTP core and registered extensions, and writes signed observations against the matching software version.

Vendors don't fill in conformance forms; the agent observes their software's actual behaviour in production. The register tracks observed reality, not asserted intent — critical at the scale UNTP is designed for, where millions of independent implementers cannot be manually audited.

## Roles

| Role | Identity | Responsibilities |
|---|---|---|
| **Registrar** | UNECE | Owns the register; defines policy; seeds vendor entries; operates the registrar agent; arbitrates disputes. |
| **Registrar Agent** | `did:webvh:untp.unece.org` | Discovers UNTP credentials via the IDR; validates them against UNTP core and registered extensions; signs and publishes conformance observations. |
| **Vendor** | Vendor root DID (e.g. `did:web:vendor.example`) | Publishes and maintains a software product. See the [Registration Guide](./registration-guide.md) for the full vendor-facing process. |
| **Vendor Delegate** | Per-customer delegate DID (e.g. `did:web:customer.binding.vendor.example`) | A DID issued by the vendor to a specific customer deployment, used to sign binding credentials. Keeps vendor root keys off customer premises. |
| **Customer / Deployer** | Customer issuer DID (e.g. `did:web:customer.example`) | Operates an instance of the vendor's software; is the `issuer` of UNTP credentials issued from that instance. |
| **Extensions Register Maintainer** | UNTP Extensions Register | Authoritative source of registered extension schemas/vocabularies the registrar agent uses to validate extension credentials (e.g. `DigitalBatteryPassport`). |

## Two independent assurance paths

The model gives consumers of UNTP credentials two independently-verifiable signals about which software issued a credential:

- **Forward signal (mandatory)** — the `issuingSoftware` block inside the credential, signed (transitively) by the credential issuer. Tells you *what the deployer claims*.
- **Reverse signal (optional)** — the vendor's binding credential, signed by a vendor-controlled delegate DID. Tells you *what the vendor confirms*.

When both signals agree, a malicious deployer cannot forge a false `issuingSoftware` claim because they cannot mint a binding credential signed by an authorised vendor delegate. Vendors that offer binding earn a stronger conformance signal in the register.

## What the agent verifies

These are the checks the registrar agent runs on every observed credential. The vendor-facing perspective on these checks (and how to satisfy them) is in the [Registration Guide](./registration-guide.md#what-gets-verified).

| Check | What it verifies |
|---|---|
| **Signature** | JWS / JWP / Data Integrity verification against the issuer DID's keys. |
| **Schema** | UNTP core schema for the declared `credentialType`, plus the schema of every extension type declared in the credential's `type` array (looked up via the Extensions Register). |
| **Vocabulary** | CVC topic/metric terms and any extension vocabulary terms resolve to known concepts. |
| **Binding** (optional) | Fetch the vendor's binding credential via `bindingCredentialDiscovery.uriTemplate`, confirm the `(credentialId, softwareVersionId)` pair, and verify it was signed by an authorised vendor delegate. |
| **Issuer authority** | Issuer DID is reachable and self-consistent. |

The agent appends a signed `ConformanceObservation` to the relevant `SoftwareVersion`, including counts across the five dimensions, a bounded sample of representative passes and failures, and a pointer to a registrar-signed observation VC. The vendor's `status` is then derived from rolling observations within the assessment window (default 30 days):

- `conformant` — all dimensions pass for ≥99% of observed credentials.
- `partially-conformant` — schema and signature pass, but binding or vocabulary failures exceed threshold.
- `non-conformant` — schema or signature failures exceed threshold.
- `insufficient-data` — fewer than the minimum credentials observed in the window.

## Identity, Key, and Credential Relationships

```mermaid
flowchart LR
  subgraph Vendor["Vendor"]
    VRootDID["Vendor Root DIDdid:web:vendor.example"]
    VRootKey[("Vendor RootSigning Key")]
    DelegateDID["Per-Customer Delegate DIDdid:web:customer.binding.vendor.example"]
    DelegateKey[("DelegateSigning Key")]
    SBOM["SCITT-anchored SBOM"]
    SwVer["Software Version IDhttps://vendor.example/.well-known/untp/software/your-platform/2026.04.1"]
  end

  subgraph Customer["Customer Deployment"]
    IssuerDID["Issuer DIDdid:web:customer.example"]
    IssuerKey[("IssuerSigning Key")]
    UNTPCred["UNTP Credential(DPP, DCC, ...)"]
    IssuingSwBlock["issuingSoftware blockvendor.id + software id"]
  end

  subgraph Vendor2["Vendor Binding Service"]
    BindingCred["Binding Credential(credentialId, softwareVersionId)"]
  end

  subgraph IDR["UNTP Identity Resolver"]
    Linkset["Linkset for product/facility ID"]
  end

  subgraph Registrar["UNECE Registrar"]
    AgentDID["Registrar Agent DIDdid:webvh:untp.unece.org"]
    AgentKey[("Registrar AgentSigning Key")]
    Observation["Conformance Observation VC"]
    SWIRegister[("SWI Registerregister.json")]
  end

  VRootKey -. controls .-> VRootDID
  VRootDID -- delegates authority to --> DelegateDID
  DelegateKey -. controls .-> DelegateDID
  IssuerKey -. controls .-> IssuerDID
  AgentKey -. controls .-> AgentDID

  SwVer -- references --> SBOM
  SwVer -- built by --> VRootDID

  IssuerDID -- signs --> UNTPCred
  UNTPCred -- contains --> IssuingSwBlock
  IssuingSwBlock -- references --> VRootDID
  IssuingSwBlock -- references --> SwVer

  Linkset -- resolves to --> UNTPCred

  DelegateDID -- signs --> BindingCred
  BindingCred -- attests --> UNTPCred
  BindingCred -- attests --> SwVer

  AgentDID -- discovers via --> Linkset
  AgentDID -- fetches --> UNTPCred
  AgentDID -- fetches --> BindingCred
  AgentDID -- signs --> Observation
  Observation -- recorded in --> SWIRegister
  Observation -- references --> SwVer
  Observation -- references --> UNTPCred
```

**How to read the diagram:**

- **Solid arrows** are runtime data references or signatures.
- **Dotted arrows** are key-control relationships (which private key controls which DID).
- **The vendor never signs UNTP credentials.** The customer deployer does. The vendor only (optionally) signs binding credentials, and only via a delegated key — the vendor root key never leaves the vendor.
- **The `issuingSoftware` block** is the bridge between the credential issuer (customer) and the vendor identity. It is the *forward* assurance signal.
- **The binding credential** is the *reverse* assurance signal: the vendor confirming "yes, our software at this version did issue that credential". Optional but strongly encouraged.
- **The registrar agent** is the only party that writes to the register. Vendors and customers do not push observations.

## Trust boundaries and failure modes

| Threat | Mitigation |
|---|---|
| Customer deployer forges an `issuingSoftware` block to claim conformance from a vendor whose software they don't actually run. | Registrar agent fetches the vendor's binding credential; absence or signature failure is recorded as `bindingFail`. Vendors that publish a binding template gain protection; those that don't accept the residual risk. |
| Vendor compromises a delegate key for one customer. | Vendor publishes an updated delegate list at `delegateDiscovery`; observations using the rotated-out delegate fail binding validation. Vendor root key is unaffected. |
| Vendor root key is compromised. | Vendor rotates the root DID's verification methods via their `did:web` document; the registrar agent re-validates against the current DID Document on each observation cycle. |
| Registrar agent is compromised. | Each observation is a signed VC; a forensic audit can compare observations to independently re-fetched credentials. UNECE retains the ability to mark observations as retracted and re-issue. |
| Stale or rotated `softwareVersionId`. | Software version IDs are append-only. Old versions remain in the register; vendors release new versions as new entries. |
| Vendor disputes an observation. | Observation evidence (sample credentials, IDR queries, validator output) is referenced from the observation VC; UNECE re-runs validation and amends/retracts as warranted. |

## Disputes

The registry's dispute-handling process:

1. Each observation references a registrar-signed VC and the validating evidence (sample credentials, IDR queries, validator output).
2. The vendor files a dispute with UNECE.
3. UNECE re-runs the validation independently. If the dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. Disputes about *interpretation* of a conformance rule (rather than the data) follow the change-control process below.

The vendor-facing perspective (what to do if you disagree with an observation) is in the [Registration Guide](./registration-guide.md#disputes).

## Cadence and retention

- **Observation cycle:** the registrar agent runs at least daily; high-volume vendors may be sampled more frequently.
- **Assessment window:** rolling 30 days by default; configurable per entry.
- **Retention:** observations are append-only and retained indefinitely. Retracted observations are marked, not deleted.
- **Register publication:** `register.json` is regenerated on every observation cycle and published at `https://registers.uncefact.org/untp/swi/register.json`. Per-entry URIs (e.g. `https://registers.uncefact.org/untp/swi/reeco`) are content-negotiated to return HTML, JSON-LD, or Turtle depending on the request `Accept` header.

## Relationship to other registers

- **[Identifier Scheme Register (IDR)](../idr/governance.md)** — the registrar agent uses identifier schemes registered here to discover credentials.
- **[Conformity Vocabulary Catalogue Register (CVC)](../cvc/governance.md)** — vocabulary validation in the observation cycle uses schemes registered here.
- **[Credential Extensions Register (EXT)](../ext/governance.md)** — schema and vocabulary validation for extension types (e.g. `DigitalBatteryPassport`) uses extensions registered here.

## Change control

Changes to this governance document, the register schema, or the conformance assessment thresholds are managed under the UN/CEFACT Open Development Process and announced on the UNTP specification site at least 30 days before taking effect.

Feedback on the rules or ambiguities should be filed as an issue on the UNTP specification repository or sent to UNECE through the usual channels.

---

## Software Implementers

# UNTP Software Implementer Register

This page provides a summary of software vendors that have committed to implement UNTP and to embed an `issuingSoftware` block in every credential their software issues. As described in the UNTP [implementation governance](../../governance/implementation-governance.md) framework, this is a key activity for software vendors that want their products to be discoverable by industry community members choosing technical platforms that they can be confident are interoperable.

## This Register

This register is maintained as a structured data set that can be read by machines or by humans.

| Field | Value |
| --- | --- |
| Register ID | `https://registers.unece.org/untp/swi` |
| Register Data | [JSON-LD register file](/registers/swi/register.json), [JSON Schema](/registers/swi/register-schema.json). Note — to be published as a linked-data vocabulary at registers.unece.org before UNTP v1.0 release. |
| Registrar | United Nations Economic Commission for Europe (UNECE) (`https://unece.org`) |
| Registrar DID | `did:webvh:untp.unece.org` |

## Summary of Registered Software Vendors

| Vendor | Products | Declared scope | Status | Last observed | Observed credentials |
| --- | --- | --- | --- | --- | ---: |
| [UNCEFACT](#uncefact) | VCkit, Test Kit | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC | `planned` | — | 0 |
| [Spherity](#spherity) | VERA | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC | `planned` | — | 0 |
| [Trust Provenance](#trust-provenance) | Trust Provenance | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC | `planned` | — | 0 |
| [Tilkal](#tilkal) | Tilkal Platform | VCP, DPP, DCC | `planned` | — | 0 |
| [Northern Block](#northern-block) | Orbit Enterprise, Trust Registry | VCP, DCC | `planned` | — | 0 |
| [FreshChain](#freshchain) | FreshChain Platform | VCP, DPP, DTE, DCC, DFR, IDR, DAC | `planned` | — | 0 |
| [Government of British Columbia](#government-of-british-columbia) | Traction | VCP, DCC, DIA | `planned` | — | 0 |
| [ReLOG3P SRL](#relog3p-srl) | ReACT, SRL | VCP, DPP, DTE, IDR, DIA, DAC, SVC | `planned` | — | 0 |
| [Lumoin](#lumoin) | Verifiable, CoreLoop | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC | `planned` | — | 0 |
| [Morpheus Network](#morpheus-network) | Morpheus Network Platform | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC | `planned` | — | 0 |
| [Cordina](#cordina) | Cordina interactive benchmarking engine | VCP, DTE, DCC, IDR | `planned` | — | 0 |
| [Enigio](#enigio) | Enigio trace:original | VCP, DPP, DTE, DCC, DFR, DAC | `planned` | — | 0 |
| [Sustainable Choice Group](#sustainable-choice-group) | Sustainability Tracker | VCP, DPP, IDR | `planned` | — | 0 |
| [Health LOQ](#health-loq) | Health LOQ Document Protection, Health LOQ Product Origin, Health LOQ Compliance Dashboard | VCP, DPP, DTE, DCC, IDR, DAC, SVC | `planned` | — | 0 |
| [SIMBA Chain](#simba-chain) | SIMBA Ensure | VCP, DPP, DTE, DCC, DFR, IDR, DAC | `planned` | — | 0 |
| [K4 Security](#k4-security) | KS Product Trust Service | VCP, DPP, DTE, DCC, IDR, DAC | `planned` | — | 0 |
| [Wholechain](#wholechain) | Wholechain Platform | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC | `planned` | — | 0 |
| [Tappr](#tappr) | Brand Cloud - SaaS, Passport Builder - SaaS | DPP, DTE, DCC, DFR, IDR | `planned` | — | 0 |
| [Movilitas.Cloud](#movilitas-cloud) | Movilitas.Cloud | DPP, DTE, DFR | `planned` | — | 0 |
| [Global Circular Network](#global-circular-network) | Global Circular Network Platform | DPP, DTE, DCC, DFR, IDR, DAC, SVC | `planned` | — | 0 |
| [Reeco](#reeco) | Reeco Platform | VCP, DPP | `planned` | — | 0 |

## Vendor Entries

## UNCEFACT

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:uncefact` |
| Website | https://unece.org/trade/uncefact |
| Registration country | Switzerland |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/uncefact` |
| Commitment date | 2024-09-01 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> The UN center for trade facilitation and e-business (UN/CEFACT) is pleased to provide a suite of UNTP open source reference implementations and a conformity testing toolkit to support global implementers of UNTP.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: VCkit

- **URL:** https://github.com/uncefact/project-vckit
- **Description:** Verifiable credential issuing and verifying toolkit.
- **Declared UNTP scope:** VCP
- **Declared UNTP versions:** all _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

### Product: Test Kit

- **URL:** https://uncefact.github.io/tests-untp/
- **Description:** A suite of conformity testing tools for all UNTP specifications.
- **Declared UNTP scope:** DPP, DTE, DCC, DFR, DIA
- **Declared UNTP versions:** all _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Spherity

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:spherity` |
| Website | https://www.spherity.com/ |
| Registration country | Germany |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/spherity` |
| Commitment date | 2024-09-11 |
| Pilot participation | No |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> Spherity is a global leader in digital identity solutions, focused on improving secure identity management for enterprises, products, and supply chains. Our self-sovereign identity (SSI) technology ensures compliance with data protection regulations and streamlines operations. We offer CARO for authentication and authorization in the US pharmaceutical supply chain, and VERA for the Digital Product Passport across multiple industries. Supporting UNTP implementation aligns with our mission to enhance transparency, accountability, and trust, benefiting our stakeholders and the industries we serve.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: VERA

- **URL:** https://vera.spherity.com/
- **Description:** Digital Product Passport Suite.
- **Declared UNTP scope:** VCP, DPP, DTE, DFR, IDR, DAC
- **Declared UNTP versions:** 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Trust Provenance

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:trust-provenance` |
| Website | https://trustprovenance.com/ |
| Registration country | Australia |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/trust-provenance` |
| Commitment date | 2024-09-11 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> The United Nations Transparency Protocol (UNTP) is crucial for Trust Provenance as it aligns with the company's mission to foster transparency and traceability in Australian agriculture. The UNTP provides a standardized framework for managing and sharing data across global supply chains, ensuring that the origins, production practices, and environmental impact of agricultural products are verifiable. By adopting the UNTP protocol, Trust Provenance can streamline its efforts to manage digital product passports.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Trust Provenance

- **URL:** https://trustprovenance.com/
- **Description:** Supply chain traceability and transparency suite.
- **Declared UNTP scope:** VCP, DPP, DTE, DFR, IDR, DAC
- **Declared UNTP versions:** all _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Tilkal

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:tilkal` |
| Website | https://www.tilkal.com |
| Registration country | France |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/tilkal` |
| Commitment date | 2024-09-12 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DCC |
| Status | `planned` |

**Implementation statement**

> Tilkal is a premier platform for supply chain traceability and transparency, integrating a B2B blockchain network with advanced analytics and risk scoring algorithms to deliver a secure, real-time view of the end-to-end supply chain. Trusted by companies across industries, Tilkal collects and consolidates operational, social and environmental data to prove origin and impact from raw materials to end products, supporting DPP creation and compliance assurance.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Tilkal Platform

- **URL:** https://www.tilkal.com
- **Description:** Supply chain traceability and transparency suite.
- **Declared UNTP scope:** VCP, DPP
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Northern Block

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:northern-block` |
| Website | https://northernblock.io/ |
| Registration country | Canada |
| Operating countries | Canada |
| Entry ID | `https://registers.uncefact.org/untp/swi/northern-block` |
| Commitment date | 2024-09-12 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DCC |
| Status | `planned` |

**Implementation statement**

> Northern Block's enterprise digital credentialing product enables the mining industry to exchange verifiable sustainability data based on industry standards, such as Towards Sustainable Mining. As these standards are key indicators of sustainable mining practices, it's essential that they can be easily integrated into digital product passports.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Mining | Towards Sustainable Mining, The Copper Mark | DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Orbit Enterprise

- **URL:** https://northernblock.io/orbit-enterprise
- **Description:** Enterprise Self-Sovereign Identity.
- **Declared UNTP scope:** VCP, DCC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

### Product: Trust Registry

- **URL:** https://trustregistry.nborbit.ca/
- **Description:** Enterprise Trust Registry.
- **Declared UNTP scope:** DCC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## FreshChain

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:freshchain` |
| Website | https://freshchain.com.au/ |
| Registration country | Australia |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/freshchain` |
| Commitment date | 2024-09-12 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DAC |
| Status | `planned` |

**Implementation statement**

> FreshChain is a fully integrated, blockchain enabled, paddock to plate assurance system that verifies the food you eat. It uses artificial intelligence, machine learning and deep learning algorithms to trace and monitor products throughout the supply chain. UNTP is an important implementable standard for FreshChain to empower our customers to connect into global transparent and sustainable supply chains.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Agriculture | Horticulture food safety, export compliance | DPP, DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: FreshChain Platform

- **URL:** https://freshchain.com.au/
- **Description:** Traceability from farm to fork.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, IDR, DIA, DAC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Government of British Columbia

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:government-of-british-columbia` |
| Website | https://digital.gov.bc.ca |
| Registration country | Canada |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/government-of-british-columbia` |
| Commitment date | 2024-09-12 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DCC, DIA |
| Status | `planned` |

**Implementation statement**

> The BC government sees UNTP implementation as an opportunity to enable BC producers of raw materials to differentiate their products in emerging sustainability-focused markets, contributing to a sustainable, clean, secure, and fair global economy.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Government | Compliance (permits, licenses, certificates) | VCP, DPP, DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Traction

- **URL:** https://digital.gov.bc.ca/digital-trust/tools/traction/
- **Description:** Traction is a tool for simplifying the sending and receiving of digital credentials. It's for governments and organizations.
- **Declared UNTP scope:** VCP, DPP, DCC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## ReLOG3P SRL

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:relog3p-srl` |
| Website | https://relog3p.com/ |
| Registration country | Italy |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/relog3p-srl` |
| Commitment date | 2024-09-12 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, IDR, DIA, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> ReLOG3P is an Innovative Startup and Benefit Corporation based in Italy founded with the specific aim to support Global Trade in achieving the UN Agenda 2030 and its Sustainable Development Goals as well as the EU Green Deal, Fit for 55%, and Sustainable and Smart Mobility Strategy objectives. Full transparency along supply chains is key, and UNTP's vision and mission are extremely aligned with ours.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: ReACT

- **Description:** Reshaping transport and logistics towards a sustainable future.
- **Declared UNTP scope:** VCP, DPP, DTE
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

### Product: SRL

- **Description:** Sustainable Reverse Logistics. A tool for simplifying the sending and receiving of digital credentials.
- **Declared UNTP scope:** VCP, DPP, DTE
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Lumoin

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:lumoin` |
| Website | https://lumoin.com |
| Registration country | Finland |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/lumoin` |
| Commitment date | 2024-09-14 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> Lumoin builds Verifiable and open-source components to drive the transition to a regenerative and circular economy by implementing the UN Transparency Protocol (UNTP). Verifiable offers secure management of Digital Product Passports (DPPs) and verifiable credentials, creating accountable, dependable pathways for supply-chain and project finance across global value chains.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Agriculture, Critical Minerals, Textiles | Supply chain transparency | VCP, DPP, DTE |
| Regulatory compliance | Supply chain | VCP, DPP, DTE, DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Verifiable

- **URL:** https://github.com/Lumoin/Verifiable
- **Description:** DID, VC and presentation methods and standards as open source.
- **Declared UNTP scope:** VCP, DPP, DCC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

### Product: CoreLoop

- **URL:** https://github.com/Lumoin/CoreLoop
- **Description:** UNTP and other data shapes standards and transformations as open source.
- **Declared UNTP scope:** DPP, DTE, SVC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Morpheus Network

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:morpheus-network` |
| Website | https://morpheus.network/ |
| Registration country | Canada |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/morpheus-network` |
| Commitment date | 2024-09-14 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC |
| Status | `planned` |

**Implementation statement**

> Morpheus.Network is a middleware solution designed for the complexities of supply chain IT systems and stakeholders. Acting as a 'binding glue,' it seamlessly connects fragmented data, software systems, and various stakeholders across the supply chain. Morpheus.Network is proud to be part of the UN/CEFACT and UN ESCAP ecosystems and is committed to advancing global supply chain transparency and efficiency.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Morpheus Network Platform

- **URL:** https://morpheus.network/platform/
- **Description:** Multi-award-winning supply chain platform with over 150 integrations providing middleware between disparate systems.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, DFR, IDR, DIA
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Cordina

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:cordina` |
| Website | https://www.cordina.io/ |
| Registration country | Australia |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/cordina` |
| Commitment date | 2024-10-04 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DTE, DCC, IDR |
| Status | `planned` |

**Implementation statement**

> Cordina is implementing UNTP to help simplify ESG disclosures for Heavy Industry and delivery of high value interactive benchmarking.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Critical Minerals, Heavy Industry | Emissions accounting | VCP, DTE, DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Cordina interactive benchmarking engine

- **URL:** https://www.cordina.io/product
- **Description:** Cordina data framework for industrial supply chains, demonstrating the value of interactive benchmarking vs scope 3 emissions reporting.
- **Declared UNTP scope:** VCP, DTE, DCC, IDR
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Enigio

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:enigio` |
| Website | https://enigio.com/ |
| Registration country | Sweden |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/enigio` |
| Commitment date | 2024-10-14 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, DAC |
| Status | `planned` |

**Implementation statement**

> Enigio's trace:original offers a solution that creates freely transferable electronic original documents which include structured data. This allows any recipient of a trace:original document to extract verified structured data effortlessly, without the need for onboarding or additional system integration.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Enigio trace:original

- **URL:** https://enigio.com/traceoriginal/
- **Description:** A solution for creating and managing digital original documents, with all the useful properties of paper but in a digital form.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, DFR, DAC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Sustainable Choice Group

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:sustainable-choice-group` |
| Website | https://www.sustainabilitytracker.com/scgroup/ |
| Registration country | Australia |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/sustainable-choice-group` |
| Commitment date | 2024-10-28 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, IDR |
| Status | `planned` |

**Implementation statement**

> Sustainability Tracker is a world first solution that houses brand sustainability credentials, initiatives, actions, and evidence in the palm of your hands. By simplifying complex data, Sustainability Tracker helps consumers to make considered choices in real time while they shop and helps brands share their sustainability messages without greenwashing.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Sustainability Tracker

- **URL:** https://www.sustainabilitytracker.com/
- **Description:** Houses brand sustainability credentials, initiatives, actions, and evidence in the palm of your hands.
- **Declared UNTP scope:** VCP, DPP, IDR
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Health LOQ

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:health-loq` |
| Website | https://healthloq.com/ |
| Registration country | USA |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/health-loq` |
| Commitment date | 2024-12-07 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, IDR, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> HealthLOQ provides product/ingredient/component origin transparency and certificate protection and verification software for companies in industries where supply chain transparency is critical. HealthLOQ specializes in providing secure and transparent solutions for tracking and verifying the integrity of products across the supply chain. HealthLOQ is a member of GRMA, the Global Retailer and Manufacturing Alliance.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Pharmaceuticals, Nutraceuticals, Food Products, Cosmetics, Military and Defense | Traceability and Integrity | VCP, DTE, DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Health LOQ Document Protection

- **URL:** https://healthloq.com/verify-document
- **Description:** Authenticates legitimate electronic documents and detects fraudulent or tampered versions using blockchain technology.
- **Declared UNTP scope:** VCP, IDR, DAC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

### Product: Health LOQ Product Origin

- **URL:** https://healthloq.com/products?product_type=all
- **Description:** Captures first-party inputs from ingredient suppliers and manufacturers and knits that information together into a product genealogy.
- **Declared UNTP scope:** DPP, DTE, IDR, DIA, DAC

_No software versions registered yet._

### Product: Health LOQ Compliance Dashboard

- **URL:** https://healthloq.com/compliance-dashboard
- **Description:** Verify a brand's credentials through the issuing organization. Automate the verification of CoAs and other documentation.
- **Declared UNTP scope:** VCP, IDR, DAC

_No software versions registered yet._

---

## SIMBA Chain

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:simba-chain` |
| Website | https://simbachain.com/ |
| Registration country | USA |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/simba-chain` |
| Commitment date | 2024-12-12 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DAC |
| Status | `planned` |

**Implementation statement**

> SIMBA Ensure is a blockchain-powered solution that delivers trust, transparency, and traceability across supply chains and life-cycles of assets and products by creating immutable digital records for asset verification. SIMBA is a participant in NAATBatt, SAE Battery Global Traceability Standards, and CIRPASS-2.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Automotive, Batteries | Traceability and Integrity | VCP, DTE, DCC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: SIMBA Ensure

- **URL:** https://simbachain.com/
- **Description:** Transfer error-free and tamper-proof data using any system, with any party. Provides trusted seamless data exchange for identity management, multi-vendor data sharing, and third party data verification.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, DFR, IDR, DAC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## K4 Security

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:k4-security` |
| Website | https://k4-security.com/ |
| Registration country | Republic of Korea |
| Operating countries | Republic of Korea |
| Entry ID | `https://registers.uncefact.org/untp/swi/k4-security` |
| Commitment date | 2025-01-13 |
| Pilot participation | Yes |
| Declared UNTP scope | VCP, DPP, DTE, DCC, IDR, DAC |
| Status | `planned` |

**Implementation statement**

> KSDPP (K4-Security Digital Product Passport) enables the application of Digital Product Passport. It allows for the verification of product authenticity while providing a fast and secure means to validate product and supplier information linked to the DPP.

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: KS Product Trust Service

- **URL:** https://dpp.globalwallet.kr/
- **Description:** KSDID PTS is a supply chain traceability software/service that provides a platform for businesses to create and manage Digital Product Passports.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, IDR, DAC
- **Declared UNTP versions:** 0.5, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Wholechain

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:wholechain` |
| Website | https://wholechain.com/ |
| Registration country | USA |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/wholechain` |
| Commitment date | 2025-08-21 |
| Declared UNTP scope | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> Wholechain is a supply chain traceability solution that tracks products from raw materials to finished goods. Built around global data standards such as GS1 and GDST (Global Dialogue on Seafood Traceability), Wholechain connects data across complex supply networks, helping businesses meet compliance requirements, enhance operational efficiency, and build consumer trust.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Agriculture, Critical Minerals, Textiles, Food Products, Cosmetics, Automotive, Batteries | Supply chain traceability | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Wholechain Platform

- **URL:** https://wholechain.com/
- **Description:** Collects and connects data across global supply chains, giving businesses the insights to manage risk, improve efficiency, and enable consumers to make more informed choices.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC
- **Declared UNTP versions:** 0.6, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Tappr

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:tappr` |
| Website | https://usetappr.com/ |
| Registration country | The Netherlands |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/tappr` |
| Commitment date | 2025-12-31 |
| Declared UNTP scope | DPP, DTE, DCC, DFR, IDR |
| Status | `planned` |

**Implementation statement**

> Tappr builds digital infrastructure for product traceability and Digital Product Passports, enabling brands and supply chains to exchange trusted product data without relying on centralised databases. UNTP enables verifiable, event-based data sharing at the source, reducing friction for suppliers while increasing trust for brands, regulators, and consumers.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Textiles, Furniture, Electronics | Supply chain traceability | DPP, DTE, DCC, DFR, IDR |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Brand Cloud - SaaS

- **Description:** Brand Cloud is Tappr's data storage solution, supporting the data model, exposing the data, and collecting data.
- **Declared UNTP scope:** DPP, DTE, DCC, DFR, IDR, SVC
- **Declared UNTP versions:** 0.6, 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

### Product: Passport Builder - SaaS

- **Description:** Passport Builder exposes the JSON-LD machine-readable UNTP data.
- **Declared UNTP scope:** DPP

_No software versions registered yet._

---

## Movilitas.Cloud {#movilitas-cloud}

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:movilitas-cloud` |
| Website | https://www.movilitas.cloud/ |
| Registration country | Belgium |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/movilitas-cloud` |
| Commitment date | 2025-12-31 |
| Declared UNTP scope | DPP, DTE, DFR |
| Status | `planned` |

**Implementation statement**

> Movilitas.Cloud is used to serialize prescription drugs with GS1 2D data matrix codes and to track and trace these products throughout the supply chain to adhere to legislation in different parts of the world. The system can also be used to apply QR codes on food products to allow consumers to learn about the different parties involved in the production of this product.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Pharma, Food | Supply chain traceability | DPP, DTE, DFR |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Movilitas.Cloud

- **URL:** https://www.movilitas.cloud/
- **Description:** Serialization and track-and-trace platform for pharmaceutical and food supply chains.
- **Declared UNTP scope:** DPP, DTE, DFR, SVC
- **Declared UNTP versions:** 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Global Circular Network

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:placeholder-domain.com:untp:swi:global-circular-network` |
| Website | https://www.globalcircularnetwork.com/ |
| Registration country | Australia |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/global-circular-network` |
| Commitment date | 2025-10-20 |
| Declared UNTP scope | DPP, DTE, DCC, DFR, IDR, DAC, SVC |
| Status | `planned` |

**Implementation statement**

> The Global Circular Network (GCN) Digital Product Passport Platform integrates RFID technology, including RFID THREADS, to enable secure, human and machine-readable tracking of textile products across interconnected global circular business networks, from fibre to feedstock. UNTP is essential to exchange reliable circularity data internationally, meet emerging regulatory standards, and advance sustainable, inclusive textile industry transformation at scale.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Textile Manufacturing (ISIC Rev.4 Division 13) | Supply chain traceability | VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Global Circular Network Platform

- **Description:** RFID-enabled DPP platform for textile circularity, linking B2B data systems across fibre to feedstock.
- **Declared UNTP scope:** VCP, DPP, DTE, DCC, DFR, IDR, DIA, DAC, SVC
- **Declared UNTP versions:** 1.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

## Reeco

| Field | Value |
| --- | --- |
| Vendor DID | `did:web:ia.reeco.eco` |
| Website | https://reeco.eco/ |
| Registration country | Italy |
| Operating countries | Global |
| Entry ID | `https://registers.uncefact.org/untp/swi/reeco` |
| Commitment date | 2026-04-30 |
| Declared UNTP scope | VCP, DPP |
| Status | `planned` |

**Implementation statement**

> Reeco is an integrated B2B SaaS platform for the textile industry that combines certification verification, supply chain traceability, mass balance calculation and Digital Product Passport emission. The system verifies certifications (GRS, RCS, OCS, GOTS, OEKO-TEX) in real time against issuing bodies and generates cryptographically signed, audit-ready DPPs. Implementing UNTP allows Reeco to deliver verifiable, interoperable product transparency aligned with EU regulation.

**Industry focus**

| Sector | Process focus | UNTP usage |
| --- | --- | --- |
| Textiles, Fashion | Certification verification, supply chain traceability, DPP emission | VCP, DPP |

_No binding credential service offered (binding-dimension validation will be skipped)._

### Product: Reeco Platform

- **URL:** https://reeco.eco/platform/
- **Description:** Integrated B2B SaaS portal for certification verification, supply chain traceability, mass balance calculation, and Digital Product Passport emission.
- **Declared UNTP scope:** VCP, DPP
- **Declared UNTP versions:** 0.7.0 _(transitional — pending vendor `softwareVersionId`)_

_No software versions registered yet._

---

<sub>Generated 2026-06-30T08:17:51.990Z from `registers/swi/register.json`.</sub>

---

## How to Register(Swi)

# How to Register Your Software

This guide walks software vendors through the steps required to get a software product listed in the UNTP Software Implementers (SWI) Register.

If you want to understand how the registry itself is governed (registrar role, agent operation, dispute and retention policy), see the [Governance](./governance.md) document. If you simply want to browse already-registered vendors, see the [register itself](./).

## Who should register

You are a candidate vendor if your organisation builds software that issues or verifies UNTP credentials on behalf of customers (producers, manufacturers, brands, traders, conformity assessment bodies, registry operators, regulators). Typical SWI registrants include:

- ERP, supply chain, and product lifecycle management platforms
- Specialist sustainability and traceability platforms
- Digital Product Passport (DPP) issuance services
- Verifiable Credential infrastructure providers
- Open-source toolkits and reference implementations

## What you'll get when you're done

- An entry in the SWI Register at `https://registers.uncefact.org/untp/swi/{your-vendor-slug}`.
- A UNECE-issued Digital Identity Anchor (DIA) credential about your vendor DID, hosted on your register entry.
- Continuous, automated conformity observation by the UNTP registrar agent — your register status reflects observed reality (the actual conformance of credentials your software issues in production).
- Discoverability for community activations selecting platforms to standardise on.

## Quick summary

The full process boils down to three things:

1. **Publish a vendor DID** at a domain you control (typically `did:web:example.com`).
2. **Embed the `issuingSoftware` block** in every credential your software issues, referencing your vendor DID and a stable `softwareVersionId` URI per build.
3. **Issue a registration Verifiable Credential** describing your products and software versions, and notify UNECE.

The registrar agent does the rest: discovers credentials in the wild via the Identity Resolver, reads each credential's `issuingSoftware` block to identify the build that issued it, validates against UNTP core and registered extensions, and writes signed observations against your software versions.

Optionally — and strongly recommended for vendors operating at scale — you can stand up a **binding-credential service** that counter-signs credential-to-software bindings. See Step 6 below.

## Prerequisites

Before you start, you'll need:

| Item | Notes |
|---|---|
| A web domain you control | Required for `did:web` and for hosting your registration VC. |
| Software that issues UNTP credentials | At least one of DPP, DCC, DTE, DFR, DIA. |
| Per-build versioning discipline | You'll mint a stable URI per build (the `softwareVersionId`) that becomes the unit of observation. |
| Familiarity with the [UNTP specification](https://untp.unece.org/docs/specification/) | Especially the credential types your software issues and the `issuingSoftware` block. |
| A representative who can liaise with UNECE | For initial onboarding and any future disputes. |

You do **not** need:

- A separate certification step before the agent observes you.
- Pre-production test credentials submitted for review (the agent observes your live production credentials).
- Specific software architecture — the model is method-agnostic about how you build your platform.

## Step-by-step

### Step 1 — Get in touch with UNECE

Tell UNECE you intend to register a software product. UNECE will create a `proposed` register entry as a placeholder while you set up your DID and update your software. There is no review or approval gate at this stage — proposals are accepted on intent.

You'll receive a placeholder DID and a slug for your vendor entry; both will be replaced once you publish your real DID and registration VC.

### Step 2 — Publish your vendor DID

Stand up `did:web:example.com` (or another DID method you prefer). Your DID Document must include at least one `assertionMethod` verification method usable to sign Verifiable Credentials.

Notify UNECE of your DID URL. UNECE will replace the placeholder DID on your entry, and shortly after will issue a UNECE-signed DIA credential about your DID — this is the trust anchor that downstream verifiers use to confirm your vendor identity.

### Step 3 — Mint a softwareVersionId per build

For every released build of your software, mint a stable URI on a domain you control that uniquely identifies the build. The recommended pattern is:

```
https://example.com/.well-known/untp/software/{product-slug}/{version}
```

For example: `https://vendor.example/.well-known/untp/software/your-platform/2026.04.1`

The URI is the unit at which conformance is observed. Don't reuse a `softwareVersionId` across builds; release a new build, mint a new URI.

### Step 4 — Embed the `issuingSoftware` block in every credential

Update your software so that every UNTP credential it issues includes an `issuingSoftware` block at the top level of the credential payload. Minimum content:

```json
{
  "issuingSoftware": {
    "vendor": {
      "id": "did:web:example.com",
      "name": "Your Vendor Name"
    },
    "id": "https://example.com/.well-known/untp/software/yourproduct/2026.04.1",
    "name": "Your Product Name",
    "version": "2026.04.1"
  }
}
```

The `vendor.id` is your vendor DID. The `id` is the `softwareVersionId` from Step 3. The agent uses both to correlate observed credentials with your register entry.

### Step 5 — Issue your registration VC

Sign a Verifiable Credential whose `credentialSubject` matches the `SoftwareVendorEntry` shape (per [`register-schema.json`](https://opensource.unicc.org/un/unece/uncefact/spec-untp/-/blob/main/registers/swi/register-schema.json)) including:

- Your vendor name, statement, registration country, operating countries.
- Your declared UNTP scope (which credential types your software issues).
- Your products, each with one or more software versions.
- Industry focus where applicable.

Host the VC at a stable URI you control (e.g. `https://example.com/.well-known/untp/swi/registration-vc.json`). Notify UNECE of the URI.

### Step 6 — (Optional) Stand up a binding-credential service

This step is optional but provides the strongest conformance signal in the register and protects against forged `issuingSoftware` claims by malicious deployers.

A binding credential is a vendor-signed counter-claim that confirms a particular UNTP credential was actually issued by a particular software version. The recommended architecture is:

- **Per-customer-deployment delegate DID model.** You issue a delegated DID to each customer deployment. The delegate signs binding credentials on behalf of your vendor root DID, but your vendor root key never leaves your premises.
- **A discovery URI template** declared in your registration VC's `bindingCredentialDiscovery.uriTemplate`, taking `{credentialId}` as a variable and resolving to the binding credential.
- **A delegate discovery endpoint** publishing the list of currently-authorised delegate DIDs.

When the agent observes a credential issued by your software, it fetches the binding credential, verifies the delegate DID is authorised, and confirms the `(credentialId, softwareVersionId)` pair. Vendors that offer binding earn a stronger `binding` signal in the observation.

### Step 7 — First observations

The registrar agent crawls the Identity Resolver, fetches discovered credentials, reads each `issuingSoftware` block, and matches it to a vendor and software version in the register. New software versions are auto-created on first sighting.

For each observed credential, the agent runs five checks (signature, schema, vocabulary, binding, issuer authority) and records a signed observation. As observations accumulate, your software-version status reflects rolling pass/fail rates.

You can ask UNECE to seed the agent with your test product/facility identifiers if your software has not yet issued credentials in the wild; otherwise observations begin once your software has issued credentials that the agent can discover.

## What gets verified

These are the conformance checks the agent runs on every observed credential. Pass these and your status holds.

| Check | What you need to do to pass |
|---|---|
| **Signature** | Issuers using your software must sign credentials with valid keys; their DID Documents must be reachable. |
| **Schema** | Credentials must validate against UNTP core schema for their declared `credentialType`, plus the schema of every extension type in their `type` array. |
| **Vocabulary** | All vocabulary terms (CVC topics, extension vocabulary terms) must resolve to known concepts. |
| **Binding** (optional) | If you've stood up a binding service, the agent fetches your binding credential and verifies the (credentialId, softwareVersionId) pair against an authorised delegate DID. |
| **Issuer authority** | The credential's issuer DID must be reachable and self-consistent. |

A vendor's `status` is then derived from rolling observations within the assessment window (default 30 days):

- `conformant` — all dimensions pass for ≥99% of observed credentials.
- `partially-conformant` — schema and signature pass, but binding or vocabulary failures exceed threshold.
- `non-conformant` — schema or signature failures exceed threshold.
- `insufficient-data` — fewer than the minimum credentials observed in the window.

The agent always records exactly which checks failed for each sample credential, so you can fix exactly what's broken.

## After registration: the lifecycle

```mermaid
stateDiagram-v2
  [*] --> proposed
  proposed --> planned
  planned --> active
  active --> observed
  observed --> conformant
  conformant --> partially_conformant
  conformant --> non_conformant
  partially_conformant --> conformant
  non_conformant --> conformant
  active --> withdrawn
  conformant --> withdrawn
  withdrawn --> [*]
```

After your initial registration:

- The agent observes credentials your software issues on every cycle.
- Each new build of your software (a new `softwareVersionId`) is auto-created in the register on first sighting — you don't need to pre-register every version.
- Your status reflects the latest assessment window — no human review or re-submission is required.

## Maintaining your registration

### Releasing a new software version

Just ship the build. The agent picks up the new `softwareVersionId` automatically when credentials carrying it appear in the wild. Optionally, you can publish a SCITT-anchored SBOM at the new version's URI for additional supply-chain integrity assurance.

You may also re-issue your registration VC if your declared product or scope metadata changes (e.g. you add a new product, expand operating countries, change your DIA-extension reference).

### Rotating keys

If you need to rotate the signing key your DID controls:

1. Update your DID Document's verification methods.
2. Re-sign your registration VC with the new key.
3. Re-publish the VC at the same URI.

The agent re-verifies the registration VC on every cycle. There is a brief window where an in-flight observation may fail signature validation; the next cycle will succeed.

For binding credentials with delegated DIDs, follow the same pattern: rotate the delegate's verification methods, update your `delegateDiscovery` endpoint to reflect the new authorised delegates.

### Withdrawing

You may exit at any time. Tell UNECE; your entry is marked `withdrawn`. Historical observations are retained for audit. Credentials your software issued during the active period remain referenceable; their `issuingSoftware` blocks still resolve to your archived register entry.

## Disputes

If you disagree with an observation about your software:

1. Fetch the `registrarAttestation` linked from the observation. It points to a signed VC the agent issued, with all check details and references to the sample credentials it observed.
2. If you can demonstrate the check was incorrect (e.g. the sample credential the agent observed was actually invalid for reasons attributable to the deployer rather than your software), file a dispute with UNECE.
3. UNECE re-runs the validation independently. If your dispute is upheld, the observation is amended; the original is retained, marked retracted, and the new observation links back to it.
4. If the disagreement concerns *interpretation* of a conformance rule (rather than the data), the change goes through the formal change-control process described in the [Governance](./governance.md#change-control) document.

## Common questions

**Do I need to register every version of my software?**
No. The agent auto-creates software-version entries on first sighting of a `softwareVersionId` in the wild. Your registration VC describes your products, but individual versions appear automatically.

**My customers issue the credentials, not me. Why does my software get observed?**
The `issuingSoftware` block your software embeds in every credential is the bridge between the issuer (your customer) and the vendor identity (you). The agent uses that block to attribute observed credentials back to your software.

**What if a customer modifies my software and issues bad credentials?**
That's the case the optional binding-credential service protects against. Without binding, the agent records the failure against your software version (since the credential carries your `issuingSoftware` block). With binding, the agent can detect that the customer's bad credentials don't have a matching binding signature and the failure is recorded as a `bindingFail` rather than a schema/signature failure.

**Can I be observed if I haven't issued any production credentials yet?**
You can be in `proposed` or `planned` status with just your DID and registration VC. To advance to `observed` or `conformant`, your software needs to be in production issuing credentials that the agent can discover via the IDR.

**Is there a fee?**
There is likely to be a minimal registration fee that is used to maintain register integrity on a non-for-profit basis. The actual fee structure will be determined before UNTP version 1.0 release.

## Where to get help

- **The UNTP specification:** [https://untp.unece.org/docs/specification/](https://untp.unece.org/docs/specification/)
- **Sample software vendor entries:** see the [register itself](./).
- **Direct contact:** raise an issue on the [UNTP specification repository](https://opensource.unicc.org/un/unece/uncefact/spec-untp), or reach out via the UNTP mailing list or UNTP slack channel (join via the links on the home page).

---

## Architecture

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview

The architecture is the blueprint for all the components of the specification and how they work together. It defines the **design principles** which underpin the UNTP and shows the components working together from the perspective of a **single actor** and across the **entire value-chain**. The UNTP is a fundamentally **decentralised architecture** with no central store of data.

## Principles

The architecture principles that guide the UNTP design are 

|Name|Principle|Rationale|
|--|--|--|
|No dependency |UNTP should not require any collaboration or dependency between issuers, consumers and verifiers of DPPs|Imposing such collaboration as a pre-requisite for action in a complex many-to-many ecosystem would essentially stall progress|
|Unknown verifier |UNTP should not assume that the consumer / verifier of UNTP data is known to the issuer, even when confidential data access is required|In a decentralised architecture with thousands of issuers, it would be impractical to register every authorised verifier with every issuer.|
|Any maturity|UNTP should not assume any technical maturity for verifiers|DPPs and other credentials must work equally for human and machine verifiers - otherwise an insurmountable complexity of knowing which customer has what capability would be required|
|Legacy data carriers |UNTP should work with any carrier of a product identifier including 1D barcodes, RFID tags, 2D codes and digital documents|1D barcodes and RFID tags are ubiquitous and will only be replaced slowly.  Uptake should not require manufacturers to re-instrument their production lines and printing processes|
|Verifiability|UNTP should provide confidence in the integrity and trustworthiness of the data|Without trustworthy data, the value of sustainability claims is reduced - possibly to the extent that the business case for adoption is non viable. |
|Any criteria|UNTP should not dictate any specific sustainability criteria but make the criteria transparent and allow criteria to be mapped (to achieve interoperability) |Costs will explode if every exporter must provide certification to every export market criteria. Where criteria are equivalent, mutual recognition provides a much more cost effective sustainability trajectory.|
|Action requires value|The benefits of UNTP implementation must exceed the costs.|If not then there will be no implementation|

## UNTP Conceptual Architecture

Our mission is to support global traceability and transparency **at scale**. To achieve that mission we must not only define the **data** standards but also solve all the barriers to adoption at scale. That includes how to **find** the data, how to **secure** the data, how to **understand** the data, and most critically, how to realise enduring business **value** from the data. These are the five pillars of UNTP.

![UNTP Components](../assets/images/arch-untp-components.png)

Small-scale tests are possible with any of these pillars missing but scalability to full production volumes is not.

### The Data

The data is the heart of the UNTP. Four credential types work together to create a digital twin of a verifiable value chain of any complexity.

* The **[Digital Product Passport (DPP)](DigitalProductPassport.md)** is issued by a product manufacturer and carries basic product data together with a set of conformity "claims" that specify product performance against defined criteria. The DPP is essentially a bundle of differentiated value that a buyer can use to choose a preferred supplier. It also provides a statement of material provenance — what materials the product is made from and where they were sourced — to assist with local-content rules and sanctions compliance.
* The **[Digital Facility Record (DFR)](DigitalFacilityRecord.md)** is issued by the owner or operator of a facility such as a mine, farm, processing plant, or recycling centre. It provides facility-level information including geolocation, bulk material and product types, and conformity claims such as emissions footprint and deforestation status.
* The **[Conformity Credential (DCC)](ConformityCredential.md)** is issued by an independent auditor or certifier and carries one or more assessments of a product or facility against well-defined criteria. When the product ID and criteria in a DCC assessment match a DPP claim, the claim's value is enhanced through independent verification.
* The **[Digital Traceability Event (DTE)](DigitalTraceabilityEvents.md)** links input products to output products at batch level, enabling provenance tracing through manufacturing processes to discover an entire value chain.

All four credential types are designed to be extensible to meet the needs of specific industry sectors or jurisdictions.

**Implements principles:** *Any criteria* — data structures carry claims against any standard or regulation without dictating which to use. *No dependency* — each actor independently issues their own credentials without requiring coordination with consumers or verifiers.

### Finding the Data

We deliberately say "finding" the data rather than "exchanging" the data because a critical principle is that the issuer usually will not know who will ultimately consume it. If you know the identifier of a product, you should be able to get the data about that product — even years after it was created.

* The **[Identity Resolver (IDR)](IdentityResolver.md)** implements ISO/IEC 18975, providing a standardised way to resolve an identifier (of a product, batch, item, facility, or entity) to a set of links to further information. The IDR works with simple identifiers encoded as 1D barcodes and complex identifiers encoded as QR codes, returning a rich variety of information tailored to the requestor's needs.
* The **[Verifiable Credentials Profile (VCP)](VerifiableCredentials.md)** includes a human-readable rendering template so that every UNTP credential is understandable by both humans and machines. The same product scan returns a nicely formatted passport to a person using their phone — or a structured data set to an automated scanner at the factory door.

**Implements principles:** *Unknown verifier* — IDR allows anyone with an identifier to find the data without the issuer knowing who will consume it. *Legacy data carriers* — IDR works with 1D barcodes, RFID tags, QR codes, and digital documents. *Any maturity* — VCP rendering templates make every credential readable by humans with no technology, as well as by machines.

### Securing the Data

As the value of sustainability attributes increases, so does the temptation to make fake claims. Without confidence in data integrity, value is diminished. Without confidence that sensitive data is accessible only to authorised parties, businesses will be less likely to participate. UNTP addresses both challenges through tamper-evident, revocable, identity-linked credentials that each actor can disclose according to their own balance of transparency and confidentiality.

* The **[Verifiable Credentials Profile (VCP)](VerifiableCredentials.md)** ensures that all UNTP data objects are issued as W3C Verifiable Credentials — tamper-evident, issuer-identifiable, and revocable. The VCP defines a simple, interoperable subset of the broader W3C specifications.
* The **[Digital Identity Anchor (DIA)](DigitalIdentityAnchor.md)** links a self-issued W3C Decentralised Identifier (DID) to a known public identity (such as a VAT registration number) through a credential issued by a trusted authority. This gives verifiers confidence that the issuer is who they claim to be.
* The **[Decentralised Access Control (DAC)](DecentralisedAccessControl.md)** provides a way to encrypt sensitive data with a unique key per item and distribute decryption keys to authorised roles without any advance knowledge of who holds which role. Even if a key is leaked, exposure is limited to a single item. The DAC also allows verified purchasers to update a DPP with post-sale events such as consumption, repair, or recycling.

**Implements principles:** *Verifiability* — VCP ensures tamper-evident, issuer-identifiable, revocable credentials. *Unknown verifier* — DAC distributes decryption keys without advance knowledge of who holds which role. *No dependency* — no pre-registration between issuers and verifiers is required.

### Understanding the Data

The UNTP credentials are deliberately simple, but that simplicity hides a world of complexity. In a world of thousands of standards and regulations, each with dozens or hundreds of criteria, how can one claim about social welfare or biodiversity be meaningfully compared to another? The UNTP does not dictate which standards any claim must reference, but it provides the tools to digitalise, unambiguously reference, and harmonise them.

* The **[Conformity Vocabulary Catalog (CVC)](ConformityVocabularyCatalog.md)** provides a framework to digitalise and unambiguously reference all standards, regulations, and conformity schemes worldwide. It maps sustainability and compliance criteria across different regulatory frameworks and industry practices so that equivalent criteria can be recognised across jurisdictions.
* The **[Core Vocabulary](CoreVocabulary.md)** and **[Core Taxonomies](CoreTaxonomies.md)** provide the shared semantic foundation. UN-standard conformity topics classify *what* is being assessed; performance metrics define *how* performance is measured. Together they enable alignment and comparability across industries and economies.

**Implements principles:** *Any criteria* — CVC maps criteria across standards and regulations without dictating which to use, enabling mutual recognition where criteria are equivalent.

### Valuing the Data

Without sufficient commercial incentive, businesses will not act. Regulatory compliance provides one driver, but broader incentives — corporate sustainability disclosures, reputational risk management, and preferential financial terms — are equally important. UNTP provides tools to quantify these incentives and drive voluntary adoption.

* The **[Business Case Template (BCT)](../business-case/BusinessCaseIndustry.md)** is a simple template for each role (buyer, supplier, certifier, software vendor, regulator) to build a business case for UNTP investment. Continuously updated with lessons from early implementations.
* The **[Community Activation Program (CAP)](../governance/CommunityActivationProgram.md)** is a business template for community-level UNTP adoption, including financial cost/benefit modelling. Industry-wide coordination unlocks interoperability benefits, shared software costs, and potential funding from governments or development banks.

**Implements principles:** *Action requires value* — BCT and CAP exist to quantify the business value of implementation and ensure benefits exceed costs. *No dependency* — each actor or community can independently build their own case for adoption.

## Vocabulary Architecture

UNTP credentials must be semantically interoperable with global standards (W3C VCDM, schema.org, GS1) and with the regulatory rulebooks of every jurisdiction. The vocabulary architecture is designed to achieve this through layered integration.

![Vocabulary Architecture](../assets/images/arch-untp-vocabularies.png)

At the foundation, the **[Core Vocabulary](CoreVocabulary.md)** defines the shared data model for all UNTP credentials, extending W3C and schema.org concepts rather than reinventing them. The **[Core Taxonomies](CoreTaxonomies.md)** provide standardised classification schemes — conformity topics and performance metrics — that give consistent meaning to claims and assessments. Above this shared foundation, the **[Conformity Vocabulary Catalog (CVC)](ConformityVocabularyCatalog.md)** maps the criteria from thousands of industry standards, national regulations, and conformity schemes into a harmonised framework. Industry extensions can add sector-specific vocabulary without breaking core interoperability, because they build on rather than replace the shared semantic layer.

## Emergent Value Chain Transparency

UNTP is designed for gradual, independent adoption. There is no need for a coordinated rollout — each actor implements for their own reasons, at their own pace.

![Value Chain Transparency](../assets/images/arch-untp-valueChain.png)

When a manufacturer publishes a product passport, value is created immediately: buyers can access verified sustainability data and make informed purchasing decisions. As more actors across the value chain participate — miners, refiners, component makers, assemblers — a verifiable digital twin of the entire supply chain emerges. Critically, this cross-industry traceability does not require collaboration between sectors. A copper miner implementing UNTP for their own regulatory reasons automatically makes provenance data available to a battery manufacturer in a completely different industry. The architecture crosses industry boundaries without requiring coordination between them.

## Interoperability Layers

The UNTP architecture maps to the [European Interoperability Framework (EIF)](https://ec.europa.eu/isa2/eif_en/) four-layer model, ensuring that every layer of interoperability is addressed.

![Interoperability Layers](../assets/images/arch-untp-layers.png)

| EIF Layer | UNTP Components | Role |
|---|---|---|
| Technical | VCP, DAC, IDR | Secure credential exchange, access control, identifier resolution |
| Semantic | DPP, DFR, DTE, DCC + Core Vocabulary + Core Taxonomies | Consistent meaning of exchanged data |
| Organisational | BCT, CAP | Industry-specific needs, incentives, community activation |
| Legal / Organisational | DIA, CVC | Identity recognition across legal boundaries; alignment between conformity rulebooks |

The **technical layer** ensures that credentials can be exchanged, verified, and discovered regardless of the platforms involved. The **semantic layer** ensures that the data means the same thing to every party. The **organisational layer** provides the business case and community structures that drive adoption. The **legal / organisational layer** bridges identity trust and regulatory alignment across jurisdictions. Together, these layers deliver end-to-end interoperability from technical plumbing to legal recognition.

---

## Conformity Credential

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

### V0.7.0 Schema and Samples

The JSON schema and sample credential instances for the Conformity Credential are maintained in this repository.

- **JSON Schema:**

| Schema | Description |
| --- | --- |
| [ConformityCredential.json](pathname:///artefacts/schema/v0.7.0/dcc/ConformityCredential.json) | Full credential schema including the W3C VC envelope and ConformityAttestation subject |
| [ConformityAttestation.json](pathname:///artefacts/schema/v0.7.0/dcc/ConformityAttestation.json) | Standalone schema for the ConformityAttestation credential subject |

- **Sample Instances:**

| Sample | Description |
| --- | --- |
| [ConformityCredential_instance.json](pathname:///artefacts/samples/v0.7.0/dcc/ConformityCredential_instance.json) | Conformity certification of a copper mine in Zambia |
| [ConformityCredential_smelter_instance.json](pathname:///artefacts/samples/v0.7.0/dcc/ConformityCredential_smelter_instance.json) | Conformity certification of a copper refinery in Japan |
| [ConformityCredential_battery_instance.json](pathname:///artefacts/samples/v0.7.0/dcc/ConformityCredential_battery_instance.json) | Conformity certification of a battery factory in Germany |

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

### Vocabulary and Context

The Conformity Credential is built on the [UNTP Core Vocabulary](CoreVocabulary.md), which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published at [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/).

### Sample Credential

| URL | QR | Description |
| --- | --- | --- |
| [Sample Conformity Credential](https://untp.showthething.com/verify?uri=https%3A%2F%2Funtp-storage.s3.ap-southeast-2.amazonaws.com%2F40c79344-f024-41b7-abac-dc0f65396f7d.json) | ![Sample Conformity Credential](../assets/images/sample-dcc-qrcode-v0.7.0.jpg) | A sample conformity credential as a signed Verifiable Credential. The URL (or QR scan) resolves to a hosted verifier that displays a human-readable version. Raw JSON data can be viewed via the `JSON` tab and the full credential can be downloaded via the download button. |

## Overview
A product passport typically makes various separate claims (eg emissions intensity, deforestation free, fair work, etc), each of which  MAY be linked to a specific conformity credential  As well as providing details of assessment standards used to substantiate a claim, the conformity credential MAY also reference an assurance credential that attests to the authority of the party to perform the specific ESG assessments. 

Conformity assessment bodies (CABs) undertake assessments for the purpose of determining whether products, processes or organisations meet specified requirements.  The joint UNIDO/ISO publication [Building Trust - The Conformity Assessment Toolbox](https://www.unido.org/sites/default/files/2009-10/building_trust_FINAL_0.pdf) represents a useful resource for understanding conformity assessment and its role in international trade.

The conformity credential data model was originally developed by a separate [UN/CEFACT project on digital conformity.](https://unece.org/sites/default/files/2023-10/WhitePaper_DigitalProductConformityCertificateExchange.pdf) 

## Conceptual Model

![Conformity Credential](../assets/images/dcc-concept.png)

## Requirements

The conformity credential is designed to meet the following detailed requirements as well as the more general [UNTP Requirements](https://untp.unece.org/docs/about/Requirements).

| ID     | Name | Requirement Statement | Solution Mapping |
| ------ | -------------------------------- | -------------------------------- | -------------------------------- |
| CC-01 | Signed| The issuer of the Conformity Credential, typically a conformity assessment body (CAB), MUST be verifiable | Conformity Credential MUST be issued as a digital [verifiable credential](VerifiableCredentials.md) signed by the CAB|
| CC-02 | Assurance level| The Conformity Credential MUST identify the nature of assurance over the assessment process, , such as formal recognition by a Governmental authority or an Accreditation Body | `ConformityAttestation.assessorLevel`, `ConformityAttestation.assessmentLevel`, and `ConformityAttestation.authorisation`|
| CC-03 | Object of conformity| The Conformity Credential MUST unambiguously identify the object of the conformity assessment, whether a product, facility or organisation.| `ConformityAssessment.assessedProduct`, `ConformityAssessment.assessedFacility`, `ConformityAssessment.assessedOrganisation` |
| CC-04 | Reference standard or regulation | The Conformity Credential MUST identify the reference standard(s) and/or regulation(s) that specify the criteria against which the conformity assessment is made. If appropriate this MUST include specific measurable thresholds (eg minimum tensile strength)| `ConformityAttestation.referenceScheme`, `ConformityAttestation.referenceProfile`, and `ConformityAssessment.assessmentCriteria` |
| CC-05 | Conformity Attestation| The Conformity Credential MUST unambiguously state whether or not the object of the assessment is conformant to the reference standard or regulation criteria| `ConformityAssessment.conformance` |
| CC-06 | Measured metrics| The Conformity Credential SHOULD include actual measured values (eg emissions intensity, tensile strength, etc) with the conformity assessment | `ConformityAssessment.assessedPerformance` |
| CC-07 | Evidence| The Conformity Credential MAY include references to audit-able evidence (eg instrument recordings, satellite images, etc) to support the assessment. If so then the hash of the evidence file-set SHOULD be included (so that an auditor can be sure that the evidence data has not changed). The evidence data MAY be encrypted with decryption keys provided on request | `ConformityAttestation.auditableEvidence` |

## Logical Model

The Conformity Credential is an assembly of re-usable components from the UNTP core vocabulary.

![Conformity Credential](../assets/images/dcc-model.svg)

For detailed class and property definitions, see the [Core Vocabulary](CoreVocabulary.md) reference. Conformity topic and performance metric classifications are defined in the [Core Taxonomies](CoreTaxonomies.md). For implementation details and sample JSON-LD snippets, see [The Components of a Conformity Credential](#the-components-of-a-conformity-credential) below.

## Assessment Assurance 

Formal processes for substantiating claims made about products, processes or services represent a fundamental concept within [UNECE Recommendation No.49](https://unece.org/trade/documents/2025/07/session-documents/revised-recommendation-no-49-transparency-scale-fostering) and within UNTP.  However, for such processes to be reliable, it is essential to define the basis for confidence in such processes.   

The UNTP approach embraces the objectives and design principles of UNECE Recommendation No. 49, by emphasising the concepts of verifiability, independence, international standards and the role of recognised authorities.

In this context, three categories of assurance have been defined, as follows.

| Assurance Category     | Description | 
| ------ | -------------------------------- | 
| **Authority-derived assurance** | Assurance is available via one of the listed pathways that assessment credibility has been established and maintained in alignment with the objectives and design principles of UECE Rec. 49 and international conformity norms. | 
| **Scheme-derived assurance** | Care is recommended as credibility derives from assurances provided by the referenced scheme, which do not necessarily represent suitable assurance that assessment credibility has been established in alignment with the objectives and design principles of UNECE Rec. 49 and international conformity norms.| 
| **No UNTP-recognised assurance** | Available assurances are not recognised as representing suitable assurance that assessment credibility has been established in alignment with the objectives and design principles of UNECE Rec. 49 and international conformity norms. | 

Describing assurance over the conformity assessment chain of results necessarily requires consideration of both the CAB processes and the scheme (or program) under which the assessment is delivered.  However, assurance over a scheme and assurance over the conformity assessment processes (relating to that scheme) are sometimes established by different processes and by different parties and it is the combination of these that provides a more complete understanding of assessment assurance.

Defined assessment assurance levels are summarised below.  Note that these relate to assurances over a scheme and the scheme processes implemented by CABs.  They do NOT relate to assurances that arise from a scheme, for example, approval or certification of manufacturers, suppliers or products/processes/services covered by a scheme.

Eligibility for a given assessment assurance level is digitally verifiable through data points linked to a conformity credential and/or scheme representation. Any recognitions indicated MUST be maintained as current, with currency defined by the party providing such recognition.
# 

  
    
      SCHEMEEVALUATIONALTERNATIVES
    
    
      Self-declaration by scheme ownerSee Note 1
    
    
    
  
  
    Or
    
      Evaluation of scheme suitability by a recognised authoritySee Note 2
    
    
    
  
  
    Or
    
      Government-owned scheme or government-mandated schemeSee Note 3
    
    
    
  
  
    Or
    
      Benchmarking of schemeSee Note 4
    
  

  
    +
  

  
    
      CONFORMITYASSESSMENTASSURANCETYPESee Note 5
    
    
      Scheme owner recognition of other parties assessing against the scheme standardsSee Notes 6 &amp; 7
    
    
      Scheme owner directly conducting conformity assessment activitiesSee Note 6
    
    
      Independent peer assessment for accredited CABSee Notes 8 &amp; 9
    
    
      Peer assessment process managed by governmentSee Note 3
    
    
      Accreditation of CAB under global mutual recognition arrangement by a body peer-evaluated to ISO/IEC 17011See Note 10
    
    
      Government mandate for conformity assessment activitySee Note 3
    
    
      Benchmarking of scheme by an organization approved to UNIDO benchmarking principles and processSee Note 11
    
  

  
    =
  

  
    
      RESULT:ASSESSMENTASSURANCELEVEL
    
    
      Scheme-derived assurance: Recognition of CAB by registered scheme
    
    
      Scheme-derived assurance: Self-declaration by registered scheme
    
    
      Authority-derived assurance: Peer assessment body recognition for accredited CAB
    
    
      Authority-derived assurance: Recognition by a governmental peer assessment authority
    
    
      Authority-derived assurance: Global accreditation mutual recognition arrangement
    
    
      Authority-derived assurance: Recognition by government mandate
    
    
      Authority-derived assurance: Recognition by approved benchmarking organisation
    
  

**Notes to Table:**
1.	The form of the self-declaration MUST be in accordance with a UNTP template reflecting relevant international standards.
2.	This refers to evaluation of a scheme by the Global Accreditation Cooperation Incorporated or through this body’s regional accreditation cooperation members or member bodies of its Mutual Recognition Arrangement for such scope - this supersedes the role of the former International Accreditation Forum (refer [www.global-aci.org](https://global-aci.org)).
3.	Ownership or mandate provided by national government or intergovernmental entity.
4.	Scheme benchmarking organisations ensure that a scheme suitability assessment has been conducted for the candidate scheme.
5.	A CAB issuing UNTP conformity credentials is sometimes also the scheme owner.
6.	The linked scheme self-declaration is available to assist in judging credibility of the scheme.
7.	Users of conformity credentials issued by a CAB recognised under a scheme have the linked scheme self-declaration available containting details of the CAB-approval process used by the scheme owner.
8.	This pathway applies to CABs accredited under the Mutual Recognition Arrangement of the Global Accreditation Cooperation Incorporated
9.	Schemes used by CABs MAY be owned by the peer assessment body but the CAB itself SHALL NOTE be owned by or otherwise related to the peer assessment body.
10.	Scheme evaluation is a prerequisite for accreditation of CABs by bodies that are signatories to the Global Accreditation Cooperation Incorporated Mutual Recognition Arrangement. 
11.	UNIDO Global Best Practice Framework for Organisations Performing Benchmarking Activities for Certification-related Conformity Assessment Schemes 2026. The process for approval of benchmarking organisations to the UNIDO principles is still to be defined.

In terms of the processes that MUST be applied for the listed assurance pathways, it is important to recognise that all of the following MUST be addressed EXCEPT in the case of government-owned schemes, or direct government approval of CABs.  

1. **Scheme Governance**
   
    Meet applicable international standards* which address scheme governance and integrity.

2. **Development of scheme**
   
   Meet applicable international standards* which address scheme development.
   
3. **Standards Development**

    Meet applicable international standards* which address the development of scheme standards.

4.	**Competency of personnel**

    Demonstrate that personnel are trained and/or certified as competent in the following activities:
    * 	Development of standards and schemes
    * Governance, management, design, development, validation of the scheme, implementation and monitoring the integrity of the conformity assessment scheme through ethical and impartial requirements for those engaging in the process
5.	**Conformity assessment**
  
    Meet applicable international standards* for management of conformity assessment processes.

*All references to ’international standards’ in the above list mean standards that are globally accepted and published for the purpose of standardising the management and delivery of conformity assessment schemes (or programs) of relevance to the product/process/organisation attributes for which assurance is to be demonstrated.   Refer to the ‘International Standards’ table in the next section for examples of relevant standards.

Examples of international standards supporting assurance pathways are provided in the table below.  

| Name     | Description | 
| ------ | -------------------------------- | 
| **Scheme - Governance** | Example standards: IAF MD-25, ISEAL Good Practice Guide for Sustainability Systems (GPGSS), ISEAL Credibility Principles, ISSA 5000, ICVCM CCP Assessment Framework,  ICROA, UNFCCC – CDM, ISO 14030 , SBTi,  ISO/IEC 17060, ISO/IEC 17067, ISO/IEC 17026, ISO/IEC 17032, ISO/IEC 17028, ISO /IEC17029, GFSI, SSCI, GSSI, ASC, PEFC, MSC, RSPO, SAC , FSC, RJC, ICMM, GEN, GLOBALG.A.P, ISO 14065, ISO/IEC 17020, ISO/IEC 17021-1, ISO 19011, GSTC, ISO 21401, ISO 21621, ISO 21902, IMDRF, ITU Conformity assessment and interoperability program, Global Certification Forum (GCF), PTCRB, CTIA, GSMA, IRMA, ICROA, ISSB, Cloud Security Alliance (CSA). | 
| **Scheme - Development of scheme** | Example standards: IAF MD-25, ISO/IEC 17007, ISO/IEC 17060, ISO/IEC 17065, ISO/IEC 17067, ISEAL GPGSS, ISO Guide 82, ISO 14019- Parts I, 2 and 4, ISO 14020, ISO 14021, ISO 14024, ISO/IEC 14025, ISO 14067, ISO 14068, ISO 14064 - Parts I, 2 and 3, GHG Protocol: Note: In the case of peer assessment or benchmarking pathways, alternative standards may be nominated (such as WRI, GRI, IFRS/ISSB, FAO- CODEX Alimentarius, USGBC) for use within the specific context of the peer assessment or benchmarking program | 
| **Scheme - Standards Development** | Example standards: ISO/IEC 17007, ISEAL GPGSS, ISO Guide 2, ,ISO Guide 59, ISO Guide 78, ISO Guide 64, ISO Guide 76,  ISO Guide 82   | 
| **Scheme - Competency of personnel** |Principles for defining competence of personnel may be found in ISO/IEC 17024 as well as supplementary references such as IAF MD 25, ISO/IEC 17021-1, ISSA 5000, ISEAL GPGSS, ISO Guide 82, ISO IWA 48, ISO 14019- Parts I, 2 and 4, ISO 14020, ISO 14021, ISO 14024, ISO/IEC 14025, ISO 14030, ISO 14067, ISO 14064 - Parts I, 2 and 3, ISO 14065, ISO 14068, IPC VVB Verifier/validator, SBTi, UNFCCC Article 6 - CDM  | 
| **Conformity assessment** | Example standards: ISO CASCO toolbox of standards. Note: In the case of peer assessment or benchmarking pathways, alternative standards may be nominated (such as ISEAL, IECEE Conformity Assessment Systems, GRI, The International EPD System, ICVCM CCP Assessment Framework, ICROA, ISO 14030, SBTi, GEN, UNFCC&IPCC, OECD, FAO&WHO, GSSI or SSCI standards, IFOAN, SMIIC, UNFCCC Article 6 - CDM, UNIDO, WRI) for use within the specific context of the overall peer assessment or benchmarking program.  | 

## The Components of a Conformity Credential

This section provides sample JSON-LD snippets for each Conformity Credential component, drawn from the [copper mine sample credential](pathname:///artefacts/samples/v0.7.0/dcc/ConformityCredential_instance.json).

### Credential Envelope

All Conformity Credentials are issued as [W3C Verifiable Credentials (VCDM 2.0)](https://www.w3.org/TR/vc-data-model-2.0/). The credential `type` includes both `VerifiableCredential` and `DigitalConformityCredential`, and the `@context` references both the W3C VCDM and UNTP context URIs. The issuer `id` SHOULD be a DID using a supported [DID method](VerifiableCredentials.md#did-methods), with `issuerAlsoKnownAs` linking to authoritative business register identifiers. The issuing party should be the conformity assessment body (CAB). Please refer to [DPP VC Guidance](DigitalProductPassport.md#credential-envelope) for further information about the use of the verifiable credentials data model for UNTP.

```json
{
  "type": ["DigitalConformityCredential", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/"
  ],
  "id": "https://credentials.sample-cab.example.com/dcc/mine-001",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-cab.example.com",
    "name": "Sample Conformity Assessment Body",
    "issuerAlsoKnownAs": [
      {
        "id": "https://sample-register.example.com/companies/CAB-001",
        "name": "Sample Conformity Assessment Services Pty Ltd",
        "registeredId": "CAB-001",
        "idScheme": {
          "id": "https://sample-register.example.com",
          "name": "Swiss Central Business Name Index (ZEFIX)"
        }
      }
    ]
  },
  "validFrom": "2025-01-15T00:00:00Z",
  "validUntil": "2028-01-15T00:00:00Z",
  "name": "Coppermark Certification — Sample Copper Mine",
  "credentialSubject": { "type": ["ConformityAttestation"], "...": "..." }
}
```

### Conformity Attestation

The `ConformityAttestation` is the `credentialSubject` of the Conformity Credential. It is best thought of as the digital version of the paper product or facility conformity certificate.

- The `id` MUST be a globally unique identifier (URI) for the attestation. Typically a certificate number with the CAB web domain as a prefix.
- `assessorLevel` classifies the independence of the party performing the assessment (e.g. `3rdParty`, `2ndParty`, `1stParty`).
- `assessmentLevel` classifies the assurance over the assessment process (e.g. `authority-benchmark`, `scheme-owner`, `unspecified`).
- `attestationType` indicates the type of attestation (e.g. `certification`, `inspection`, `testing`).
- `issuedToParty` identifies the entity to whom the attestation is issued — usually the product manufacturer or facility operator.
- `referenceScheme` and `referenceProfile` link this attestation to a published [Conformity Vocabulary Catalog](ConformityVocabularyCatalog.md), identifying the scheme and the specific profile under which the assessment was conducted.
- `profileScore` records the overall assessment outcome against the scheme’s scoring framework.
- `authorisation` lists accreditations that a competent authority has issued to the CAB, providing trust that the certifier is properly accredited.
- `conformityCertificate` links to the full certificate document (e.g. a PDF), with optional integrity verification via `digestMultibase`.
- `auditableEvidence` links to the evidence files that informed the assessments. These are usually commercially sensitive but important for audits.
- `conformityAssessment` is an array of detailed assessments made about identified products or facilities against specific criteria.

```json
"credentialSubject": {
  "type": ["ConformityAttestation"],
  "id": "https://coppermark-cab.example.com/attestation/CM-KM-2025-001",
  "name": "Coppermark Responsible Production Certificate — Sample Mine",
  "description": "Third-party conformity assessment of Sample Copper Mine against Coppermark Responsible Risk Assessment (RRA) v3.0, covering environmental, social, and governance criteria for responsible copper production.",
  "assessorLevel": "3rdParty",
  "assessmentLevel": "authority-benchmark",
  "attestationType": "certification",
  "issuedToParty": {
    "id": "did:web:sample-mine.example.com",
    "name": "Sample Copper Mine Pty Ltd",
    "registeredId": "MINE-001",
    "idScheme": {
      "id": "https://sample-register.example.com",
      "name": "Patents and Companies Registration Agency (Zambia)"
    }
  },
  "authorisation": ["..."],
  "referenceScheme": {"..."},
  "referenceProfile": {"..."},
  "profileScore": {"..."},
  "conformityCertificate": {"..."},
  "auditableEvidence": {"..."},
  "conformityAssessment": ["..."]
}
```

### Authorisation

Authorisations are endorsements issued by a competent authority (such as a government agency, a national accreditation authority, or a scheme owner) to the conformity assessment body. They provide trust that the CAB is properly accredited to issue certificates under the referenced scheme.

- `name` describes the accreditation.
- `trustmark` is a base64-encoded image typically shown on paper accreditations.
- `issuingAuthority` identifies the competent authority that granted the endorsement.
- `endorsementEvidence` is a `Link` to the actual accreditation details. This SHOULD point to a trusted source such as a web page on the accreditation authority site or a digital verifiable credential.

Note that the `authorisation` structure is part of the attestation issued by the CAB. As such it is only an unverified claim until confirmed via the `endorsementEvidence` link.

```json
"authorisation": [
  {
    "name": "Accreditation of Sample Conformity Assessment Body as a Coppermark Approved Assessment Firm.",
    "trustmark": {
      "name": "Coppermark Approved Assessor",
      "description": "Trust mark issued by The Copper Mark Company to accredited assessment firms.",
      "imageData": "Y29wcGVybWFyay1sb2dv",
      "mediaType": "image/png"
    },
    "issuingAuthority": {
      "id": "https://coppermark.org",
      "name": "The Copper Mark Company",
      "registeredId": "CM-AUTH-001",
      "idScheme": {
        "id": "https://coppermark.org",
        "name": "Coppermark Registry"
      }
    },
    "endorsementEvidence": {
      "linkURL": "https://coppermark.org/approved-assessors/sgs",
      "linkName": "Sample CAB Coppermark Accreditation",
      "mediaType": "text/html",
      "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dcc"
    }
  }
]
```

### Reference Scheme, Profile, and Profile Score

The `referenceScheme` and `referenceProfile` properties link the attestation to a published [Conformity Vocabulary Catalog](ConformityVocabularyCatalog.md) (CVC). The scheme identifies the overarching conformity program; the profile identifies the specific versioned set of criteria under which this assessment was conducted. The `profileScore` records the overall outcome using the scoring framework defined by the scheme.

- `referenceScheme` identifies the conformity scheme by its `id` and `name`.
- `referenceProfile` identifies the specific versioned profile within the scheme.
- `profileScore` carries the overall result using a `code`, `rank`, and `definition` drawn from the scheme’s scoring framework.

```json
"referenceScheme": {
  "id": "https://coppermark.org",
  "name": "Coppermark"
},
"referenceProfile": {
  "id": "https://coppermark.org/rra/v3.0",
  "name": "Coppermark Responsible Risk Assessment (RRA) v3.0"
},
"profileScore": {
  "code": "fully-meets",
  "rank": 3,
  "definition": "The site fully meets all applicable Coppermark criteria with no significant non-conformances."
}
```

### Conformity Certificate and Auditable Evidence

The `conformityCertificate` and `auditableEvidence` properties are both `Link` objects. The certificate links to the full version of the conformity attestation (e.g. a PDF or web page); the auditable evidence links to the underlying evidence files that informed the assessments.

- `linkURL` points to the external resource.
- `linkName` provides a human-readable description.
- `mediaType` specifies the content type of the linked resource.
- `linkType` classifies the link using a controlled vocabulary.
- `digestMultibase` may optionally be included to ensure content integrity — the hash of the target content at the time the credential was issued.

```json
"conformityCertificate": {
  "linkURL": "https://coppermark.org/participants/kansanshi-mining",
  "linkName": "Coppermark Public Certificate — Sample Copper Mine Pty Ltd",
  "mediaType": "text/html",
  "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dcc"
},
"auditableEvidence": {
  "linkURL": "https://coppermark-cab.example.com/reports/CM-KM-2025-001-full.pdf",
  "linkName": "Full Assessment Report — Sample Mine (Restricted)",
  "mediaType": "application/pdf",
  "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dcc"
}
```

### Conformity Assessment

One Conformity Credential may include many assessments in the `conformityAssessment` array. Each assessment represents the evaluation of an identified product, facility, or organisation against one or more specific criteria. A single assessment includes:

- A unique `id` and human-readable `name` and `description`.
- `assessmentCriteria` — one or more criteria from a standard, regulation, or scheme, each classified by a `conformityTopic`.
- `assessmentDate` — when the assessment was conducted.
- `assessedPerformance` — measured values quantifying the assessment outcome.
- `assessedFacility`, `assessedProduct`, or `assessedOrganisation` — the subject of the assessment, with `idVerifiedByCAB` indicating whether the CAB verified the subject’s identity.
- `conformance` — a boolean indicating whether the assessed subject conforms to the referenced criteria.

```json
"conformityAssessment": [
  {
    "type": ["ConformityAssessment"],
    "id": "https://coppermark-cab.example.com/assessment/CM-KM-2025-001-GHG",
    "name": "GHG Emissions Assessment (Criteria 26, 27)",
    "description": "Assessment of greenhouse gas emissions management, measurement, and reduction initiatives at Sample Copper Mine against Coppermark criteria 26 and 27.",
    "assessmentCriteria": ["..."],
    "assessmentDate": "2025-01-10",
    "assessedPerformance": ["..."],
    "assessedFacility": [
      {
        "facility": {
          "id": "https://facility-register.example.com/fac-001",
          "name": "Sample Copper Mine",
          "registeredId": "fac-001"
        },
        "idVerifiedByCAB": true
      }
    ],
    "assessedOrganisation": {
      "organisation": {
        "id": "did:web:sample-mine.example.com",
        "name": "Sample Copper Mine Pty Ltd",
        "registeredId": "MINE-001"
      },
      "idVerifiedByCAB": true
    },
    "conformance": true
  }
]
```

### Assessment Criteria and Conformity Topic

Each assessment references one or more criteria via the `assessmentCriteria` array. A criterion identifies a specific auditable requirement within a scheme, and MUST be classified by a `conformityTopic` drawn from the UNTP [Conformity Topics](CoreTaxonomies.md) taxonomy. The criterion `id` SHOULD be a URI published by the scheme owner via the [Conformity Vocabulary Catalog](ConformityVocabularyCatalog.md), so that the same criterion can be referenced unambiguously across Conformity Credentials, Product Passports, and FAcility Records.

```json
"assessmentCriteria": [
  {
    "id": "https://coppermark.org/rra/v3.0/criterion/26",
    "name": "GHG Emissions — Coppermark Criterion 26",
    "conformityTopic": [
      {
        "type": ["ConformityTopic"],
        "id": "https://vocabulary.uncefact.org/conformity-topic/greenhouse-gas-emissions",
        "name": "Greenhouse Gas Emissions",
        "definition": "Assessment of direct and indirect greenhouse gas emissions across scopes 1, 2, and 3, including measurement, reporting, and reduction targets aligned with climate science."
      }
    ]
  },
  {
    "id": "https://coppermark.org/rra/v3.0/criterion/27",
    "name": "Energy Use and Efficiency — Coppermark Criterion 27",
    "conformityTopic": [
      {
        "type": ["ConformityTopic"],
        "id": "https://vocabulary.uncefact.org/conformity-topic/renewable-energy-use",
        "name": "Renewable Energy Use",
        "definition": "Adoption and integration of renewable energy sources to reduce reliance on fossil fuels and lower the carbon footprint of operations and products."
      }
    ]
  }
]
```

### Assessed Performance

The `assessedPerformance` array carries the measured values from the assessment. Each entry references a `metric` from the UNTP [Performance Metrics](CoreTaxonomies.md) taxonomy and provides either a numeric `measure` (value and unit), a categorical `score` (code and rank), or both.

```json
"assessedPerformance": [
  {
    "metric": {
      "id": "https://vocabulary.uncefact.org/performance-metric/scope-1-ghg-emissions",
      "name": "Scope 1 GHG Emissions"
    },
    "measure": {
      "value": 45000,
      "unit": "TNE"
    }
  }
]
```

---

## Conformity Vocabulary

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

### V0.7.0 Schema and Sample

A complete conformity vocabulary is a single hierarchy rooted at a Conformity Scheme that embeds its versioned Profiles, each of which embeds its versioned Criterion. The JSON schema and a sample instance are maintained in this repository.

- **JSON Schema:**

| Schema | Description |
| --- | --- |
| [ConformityScheme.json](pathname:///artefacts/schema/v0.7.0/cvc/ConformityScheme.json) | Root schema for a conformity scheme including owner, endorsement, scoring framework, and the included profiles and their criterion |

- **Sample Instance:**

| Sample | Description |
| --- | --- |
| [ConformityScheme_instance.json](pathname:///artefacts/samples/v0.7.0/cvc/ConformityScheme_instance.json) | Minerals Assurance Scheme — endorsed scheme containing the Tantalum Processor Standard profile with embedded due-diligence, mass-balance, and processor-input-controls criterion |

The sample represents a minerals assurance scheme for responsible sourcing, with a tantalum processor profile and three representative criterion types.

## Overview

Web vocabularies are a means to bring consistent meaning to conformity claims and assessments throughout transparent value chains, by ensuring that the standards used in claims and assessments are referenced as unique digital objects. Different participants will reference the same documentation in an identical, machine-recognisable, manner.  Critically, this enables Product Passport claims to be verified against corresponding conformity credentials and to facilitate comparison among different conformity credentials

To achieve these outcomes, these digital objects need to be discoverable from a version-specific and persistent URI link.  This specification provides instruction for conformity scheme owners about how to publish their schemes and associated criterion as linked data vocabularies so that they can be referenced by CABs in conformity credentials and by manufacturers in their Product Passport and Facility Record claims.

A key design principle is to keep the work of CABs and Manufacturers simple by pushing re-usable complexity to the scheme. For example, when a scheme owner is responsible for the deconstruction of their scheme into fine grained and categorised criterion then the criteria against which assessments are undertaken by CABs are made transparent through references within conformity credentials to the scheme vocabulary. Similarly, when scheme owners clearly reference all standards and regulations that their scheme is designed to meet then verifiers can easily assess whether a given conformity credential is sufficient to meet their regulatory compliance needs.

## Conformity Vocabulary Catalog

UNTP will maintain a catalogue of schemes that are registered with UNTP by scheme owners that have implemented this specification. This provides an entry point for discovery of rich scheme data maintained consistently by multiple scheme owners.
* The first (current) version is the current [Scheme Owners](../implementations/cvc/) registration page.
* Before the first stable release of UNTP, the various registers (conformity schemes, identifier schemes, etc) will be published as machine readable and human readable structured linked data. 

The scheme register is also a useful source of examples as each scheme publishes its conformity vocabulary.

## Standards and Regulations

Some conformity schemes generate their own standards internally and these may be formally referenced according to the Logical Model defined for the scheme vocabulary.  It is also common for  conformity schemes to reference formal standards (eg from ISO,national standards bodies or other institutions), often with the intention to meet legal requirements of national regulators or international treaties. 

Therefore part of this specification also includes mechanisms to reference both internally-generated standards and relevant externally-published standards and regulations. In either case, for these references to be stable, meaningful and consistent across schemes, the standards and regulations themselves also need globally unique URI identifiers.

* Most regulations are already published by nation states in a digitally referenceable way as stable URLs. For example the Australian National Greenhouse and Energy Reporting (NGER) regulation measurement standards are permanently referenceable at https://www.legislation.gov.au/F2008L02309 
* However, it is less common for Standards Development Organisations (SDOs) to maintain their catalogue of standards as digitally referenceable objects with appropriate version control. However, where it can be established that an SDO does produce viable digital references then these SHOULD be used for the purposes of UNTP. 

## Conceptual Model

Diagram 1 shows how the Conformity Vocabulary works with UNTP credentials, such as Product Passports, Facility Records and Conformity Credentials, to bring unambiguous meaning to sustainability claims and assessments.

**Diagram 1:**
![Conformity Vocabulary Catalog](../assets/images/cvc-concept.png)

* Conformity Schemes (Grey) include one or more versioned profiles that are themselves composed from independently versioned criterion. 
  * A criterion is a versioned set of auditable requirements related to a specific conformity topic such as Forced Labour. It is identified and referenced by a URI such as `myscheme.org/criterion/forced-labour/1.0.0` 
  * A profile is essentially a versioned description of the scheme, or subset of a scheme, in terms of a broad conformity outcome elements, without including details of the auditable criteria. It is identified and referenced by a URI such as `myscheme.org/profiles/mine-site/1.0.0` It composes one or more versioned criterion (which contain the auditable criteria) to construct a high-level set of requirements against which a conformity attestation might be issued. A profile MAY additionally link to any external national regulations, international conventions, voluntary standards etc, to which it is aligned and for which it aims to assist compliance.
  * Criterion and profiles are independently versioned. That's because a profile (v1.0.0) might compose 20 criterion.  An update to the profile (eg v1.1.0) might only change a couple of criterion with the rest unchanged.
* Product Passports and Facility Records (green): Manufacturer or brand owners issue Product Passports and Facility Records that include a series of performance claims. Each claim MAY reference one or more criterion published by a scheme owner so that the claim is unambiguously understood. Note that a single Product Passport or Facility Record MAY make claims that reference criterion from multiple different schemes.
* Conformity Credential (brown): The UNTP conformity credential provides a means for a conformity assessment body to list assessment outcomes for specific products or facilities against defined criteria. A Conformity Credential includes one `attestation` that maps to a Conformity Vocabulary `profile` and multiple `assessments`, each of which map to a Conformity Vocabulary `criterion`
* A Conformity Vocabulary profile should list the external national regulations, international conventions, and voluntary standards to which it is aligned and which it aims to assist compliance.

For a Conformity Credential to verifiably support a claim contained in a Product Passport or Facility Record, there SHOULD be matching of the criteria referenced in the Product Passport or Facility Record and the supporting credential.  Where assessments are undertaken in accordance with a scheme for which a scheme vocabulary exists, the mechanism for achieving such matching is to use the same identifier for the scheme criteria within both the Conformity Credential and the Product Passport or Facility Record.

Any conformity scheme is associated with a unique versioned set of participation rules and other scheme-level information established by the scheme owner, meaning that concurrently-delivered schemes or profiles involving rule variants or other differences (such as endorsement coverage) MUST be registered as separate scheme vocabularies, even if owned and/or operated by the same entity. This is a different situation from where scheme rules may be updated but a transition period permitted, such that the validity of both versions may overlap for a period.

## Requirements

|ID|Requirement Statement|Solution Mapping|
|--|--|--|
|CVC-01|Scheme owners MUST publish the granular scheme criteria, potentially reflecting different sustainability attributes recognised within the scheme and potentially at varying performance levels, in such a way that each scheme criteria can be unambiguously referenced by issuers of conformity credentials, facility records, and product passports |[Conformity Vocabulary Schema](#conformity-vocabulary-schema)|
|CVC-02|Scheme owners MUST manage versions of schemes to reflect changes in the criteria within a scheme so that claims and assessments can be understood within a specific version context|[Conformity Vocabulary Schema](#conformity-vocabulary-schema)|
|CVC-03|Scheme owners are provided with guidance in establishing their vocabulary in accordance with the prescribed UNTP Schema.| [Conformity Vocabulary Publishing Guide](#conformity-vocabulary-schema)|
|CVC-04|Scheme owner tag scheme criteria with context labels such as commodity type or facility type so that a relevant assessment can be identified for a given context.| [Conformity Vocabulary Schema](#conformity-vocabulary-schema)|
|CVC-05|Conformity Assessment Bodies (CABs) have access to the URI associated with any scheme criteria so that these can be correctly referenced in the assessments recorded in digital conformity credentials.| [Conformity Vocabulary Catalog](#conformity-vocabulary-catalog) |
|CVC-06|Product suppliers or facility operators are provided with access tothe URI associated with any scheme criteria so that these can be correctly referenced in the claims recorded within product passports and facility records.|[Conformity Vocabulary Catalog](#conformity-vocabulary-catalog) |
|CVC-07|Given that there are hundreds of sustainability schemes, each with potentially hundreds of scheme criteria, consumers of digital credentials are provided with access to a classification for sustainability attributes to more easily compare assessments for a given sustainability attribute across different schemes.|[Conformity Criteria Topic Classification](#conformity-topic-codes) |

## Conformity Vocabulary Schema

This conformity vocabulary publishing guide provides scheme owners with a best practice framework that can be used to publish their schemes as a structured set of criteria, each with a unique identifier (URI) and with rich metadata about each criteria (eg topic classification, regulatory alignment, performance thresholds, etc). This is a critical activity so that issuers of product passports, conformity credentials, and facility records, can unambiguously reference a scheme and it's criteria. 

### Implementation Maturity Levels

This specification defines a very rich model for conformity schemes that will maximise the value that schemes can offer to their users. Full implementation may take scheme owners some time and so UNTP facilitates a phased implementation by defining a maturity model that allows implementers to start simple.

* **Level 1** - Scheme only: At a minimum, scheme owners specify a permanent ID (As a URL) for each scheme version that they manage (eg `scheme.company.com/standard-a/1.8.0`) including scheme level metadata such as assessment level and endorsement. This provides issuers of Conformity Credentials with an unambiguous scheme reference but does not break down the scheme into meaningful components.
* **Level 2** - Scheme & criteria : Scheme owners publish both their versioned schemes and versioned criterion as permanent URLs. Each criterion is also classified by UNTP conformity topic code. This provides supply chain actors facing multiple claims against multiple schemes with an easy way to make sense of the scope of conformity claims and assessments.
* **Level 3** - Full vocabulary: Scheme and criteria are published with full metadata as well as performance thresholds and standard / regulatory alignment mappings. Assessments based on such schemes provide supply chain actors with the most complete and comparable compliance map. 

### Logical Model

This section describes the detailed logical data model of a conformity scheme vocabulary in more detail.

![CVC data model](../assets/images/cvc-model.svg)

The key ideas in the logical model of a published conformity vocabulary are

* A conformity scheme MUST have a unique ID, validity period, an owner, endorsement, and references one or more versioned scheme profiles.
* The conformity scheme MAY define performance levels against which criteria can be categorised. It may also define an allowed set of tags which can be assigned to criteria for the purposes of filtering or sorting.
* Scheme profile matches the scope of an audit under the scheme.  Many schemes maintain different scoped profiles for different facility types (eg smelter, mine-site, etc), commodity types (eg cotton, copper, etc), or conformity topic (forced labour, emissions, etc). Each profile composes one or more versioned assessment criterion. 
* Conformity profiles MAY define alignment (for example, partial, meets, exceeds)  against any regulations or standards.
* A criterion MUST have a unique ID (a URI) which is the key reference for any claims or assessments of product or facilities made in product passports or conformity credentials. 
* Each criterion SHOULD be classified according to the applicable UNTP [Conformity Topic Code](#conformity-topic-codes).
* A scheme criterion MAY specify a required performance threshold as a numeric (eg 300Mpa tensile strength) or a score (eg "B") which an assessed product or facility much achieve in order to be considered conformant.
* A scheme criterion MAY be classified according to formal classification schemes (eg applicable industry sector or commodity type).
* A given scheme criterion ID MAY be re-used by multiple Profile ID (for example a Scheme version increments but most of the conformity criteria don't change from one version to the next).

## Conformity Topic Codes

UNTP defines a standard taxonomy of conformity topics which SHOULD be used to classify criterion so that criterion across multiple schemes can be aligned around common topics such as forced labour, emissions, water usage, safety, etc.  Please refer to [conformity topics](CoreTaxonomies.md) for further details.

---

## Core Taxonomies

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

# Core Taxonomies

## Artifacts

### Published Taxonomies

The UNTP core taxonomies are published as linked data SKOS vocabularies.

| Taxonomy | URL |
| --- | --- |
| Conformity Topics | [https://vocabulary.uncefact.org/conformity-topics/](https://vocabulary.uncefact.org/conformity-topics/) |
| Performance Metrics | [https://vocabulary.uncefact.org/performance-metrics/](https://vocabulary.uncefact.org/performance-metrics/) |

Each taxonomy is a [SKOS ConceptScheme](https://www.w3.org/TR/skos-reference/) with hierarchical concepts. The published URLs return human-readable HTML by default and machine-readable JSON-LD when requested with `Accept: application/ld+json`. The source files are maintained in this repository at `artefacts/vocabularies/untp-topics/` and `artefacts/vocabularies/untp-metrics/`.

The taxonomies use http header content negotiation to ensure that the same URI that identifies a concept works for both human and machine readable responses. 

* `curl https://vocabulary.uncefact.org/conformity-topics/ -H 'Accept: application/ld+json'`
* `curl https://vocabulary.uncefact.org/performance-metrics/ -H 'Accept: application/ld+json'`

The content negotiation works at any level in the taxonomy hierarchy - so that every concept is available as a human and a machine readable form.

## Taxonomy Overview

UNTP defines two complementary taxonomies that bring consistent meaning to the claims and assessments exchanged across supply chains.

### Conformity Topics

Hundreds of conformity schemes worldwide each publish their own criteria — covering everything from greenhouse gas emissions to labour rights to product safety. Without a common classification, a buyer receiving claims and assessments from dozens of suppliers across a complex value chain has no way to consistently understand what each criterion is about. The **Conformity Topics** taxonomy solves this by providing a standard hierarchical classification of conformity subject areas. Every `Criterion` in a claim or assessment is tagged with one or more topics from this taxonomy, so that criteria from different schemes can be understood, compared, and aggregated around common themes such as "Greenhouse Gas Emissions" or "Waste Minimisation". The topics are also mapped to key international frameworks including the [UN Sustainable Development Goals](https://sdgs.un.org/goals), the [OECD Guidelines for Multinational Enterprises](https://www.oecd.org/en/topics/responsible-business-conduct.html), and significant regulatory acts such as the [EU Deforestation Regulation](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en) and the [EU Corporate Sustainability Due Diligence Directive](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en).

### Performance Metrics

Claims and assessments often include numerical performance measures — but without classification, a value like "10 Kg" is meaningless on its own. The **Performance Metrics** taxonomy provides a standard classification of quantitative measures such as "Scope 1 GHG Emissions" or "Recycled Content Percentage", giving consistent meaning to the numbers attached to claims and assessments. Each metric defines the recommended unit, aggregation method, and improvement direction, so that performance data can be correctly interpreted regardless of who issued the claim. Critically, the performance metrics are mapped to major international corporate disclosure frameworks including [IFRS Sustainability Disclosure Standards](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/) and [GRI Standards](https://www.globalreporting.org/standards/), so that consumers of product and facility-level performance data can consistently roll up supply chain measures into corporate-level sustainability disclosures.

### How the taxonomies connect to claims and assessments

The diagram below shows how the two taxonomies integrate with the UNTP vocabulary classes for claims and assessments. A supplier's `Claim` (carried on a product passport or facility record) and an independent `ConformityAssessment` (carried on a conformity credential) both reference the same `Criterion` — and both carry `Performance` data. The **Conformity Topics** taxonomy classifies the subject matter at the claim, assessment, and criterion level, ensuring consistent understanding of *what* is being assessed. The **Performance Metrics** taxonomy classifies the quantitative `Measure` attached to each performance result, ensuring consistent understanding of *what was measured and how*. Because both supplier-issued claims and independently-issued assessments reference the same taxonomy-classified criteria and metrics, a downstream buyer can meaningfully compare self-declared performance against third-party verified results.

```mermaid
classDiagram
    direction TB

    class ConformityTopic {
        &lt;&lt;Conformity Topics Taxonomy&gt;&gt;
    }
    class PerformanceMetric {
        &lt;&lt;Performance Metrics Taxonomy&gt;&gt;
    }

    Claim --> Criterion : referenceCriteria
    Claim --> Performance : claimedPerformance
    Claim --> ConformityTopic : conformityTopic

    ConformityAssessment --> Criterion : assessmentCriteria
    ConformityAssessment --> Performance : assessedPerformance
    ConformityAssessment --> ConformityTopic : conformityTopic

    Criterion --> ConformityTopic : conformityTopic

    Performance --> PerformanceMetric : metric
    Performance --> Measure : measure
```

The reference tables below are **auto-generated** from the machine-readable vocabularies. Re-generate by running:

```bash
node .claude/scripts/generate-taxonomy-docs.js \
  website/docs/specification/CoreTaxonomies.md \
  --title "Core Taxonomies" --sidebar-position 42 \
  --vocab artefacts/vocabularies/untp-topics/untp-topics.jsonld \
    --section-title "Conformity Topics" \
  --vocab artefacts/vocabularies/untp-metrics/untp-metrics.jsonld \
    --section-title "Performance Metrics"
```

<!-- GENERATED:BEGIN conformity-topics -->
## Conformity Topics

A hierarchical classification scheme for conformity topics used to categorise conformity criteria published by scheme owners. Encompasses sustainability (environmental, social, governance), product integrity, trade compliance, technical conformity, and information security domains. Designed as a common reference taxonomy for interoperable conformity assessments across regulatory frameworks and voluntary standards.

**Version:** 0.2.0-working

**Top-level categories:** 11  |  **Total concepts:** 101

### 01 Ecological Resilience

Environmental protection, resource conservation, and climate resilience. Covers emissions reduction, energy transition, water stewardship, waste prevention, biodiversity, and circular design.

> UN SDGs 6, 7, 12, 13, 14, 15; OECD Guidelines Chapter VI: Environment; EU ESPR Art. 5-8 and Annex I.

| Code | Topic | Definition |
| --- | --- | --- |
| 01.01 | Greenhouse Gas Emissions | Measuring, reporting, and reducing greenhouse gas emissions (CO2, methane, N2O, F-gases) across production, transport, and supply chain activities. |
| 01.02 | Renewable Energy Use | Transition to sustainable energy sources including solar, wind, hydro, and other renewables in production and operations. |
| 01.03 | Water Conservation | Sustainable water management including efficient use, pollution prevention, and watershed protection throughout operations and supply chains. |
| 01.04 | Waste Minimization | Reducing waste generation through prevention, reuse, and improved production processes across the product lifecycle. |
| 01.05 | Ecosystem Preservation | Protecting biodiversity, natural habitats, and ecosystem services from degradation caused by production and extraction activities. |
| 01.06 | Forest Conservation | Preventing deforestation and promoting sustainable forestry practices in raw material sourcing and land use. |
| 01.07 | Recycled Material Integration | Incorporation of secondary and recycled materials into production processes, reducing dependence on virgin resources. |
| 01.08 | Sustainable Product Design | Designing products for durability, repairability, recyclability, and minimal environmental impact throughout their lifecycle. |
| 01.09 | Chemical Safety | Restriction and responsible management of hazardous substances in materials, products, and production processes. |
| 01.10 | Air Quality Management | Controlling and reducing non-GHG air pollutant emissions including SOx, NOx, VOCs, particulates, and ozone-depleting substances from operations and production processes. |

### 02 Human Equity and Welfare

Protection of human rights, promotion of fair labor practices, and support for community wellbeing across operations and supply chains.

> UN SDGs 1, 3, 4, 5, 8, 10; OECD Guidelines Chapter IV: Human Rights and Chapter V: Employment and Industrial Relations; EU ESPR Art. 10.

| Code | Topic | Definition |
| --- | --- | --- |
| 02.01 | Rights and Equality | Ensuring non-discrimination and equal treatment regardless of race, gender, religion, disability, or other protected characteristics. |
| 02.02 | Decent Work Conditions | Provision of fair wages, reasonable working hours, and dignified employment conditions throughout the supply chain. |
| 02.03 | Workplace Safety | Protecting worker health and safety through hazard prevention, protective equipment, and safe working environments. |
| 02.04 | Community Empowerment | Supporting local community development, livelihoods, and participation in decisions that affect their wellbeing. |
| 02.05 | Worker Representation | Respecting freedom of association, collective bargaining rights, and worker participation in workplace governance. |
| 02.06 | Forced Labor Elimination | Preventing all forms of forced, bonded, or compulsory labor including debt bondage and human trafficking in supply chains. |
| 02.07 | Youth Protection | Safeguarding young workers from hazardous conditions and eliminating child labor in all forms across supply chains. |
| 02.08 | Gender Equity | Promoting gender diversity, equal opportunity, and elimination of gender-based discrimination in employment and business practices. |

### 03 Ethical Governance

Promoting organizational integrity, accountability, and transparent practices in business operations and decision-making.

> UN SDG 16; OECD Guidelines Chapter II: General Policies and Chapter VII: Combating Bribery; EU ESPR Art. 11-12.

| Code | Topic | Definition |
| --- | --- | --- |
| 03.01 | Anti-Corruption Measures | Preventing bribery, extortion, and corrupt practices through policies, controls, and organizational culture. |
| 03.02 | Open Reporting | Transparent disclosure of environmental, social, and governance performance to stakeholders and the public. |
| 03.03 | Legal Compliance | Adherence to applicable laws, regulations, and legal obligations in all jurisdictions of operation. |
| 03.04 | Responsible Procurement | Ethical sourcing and purchasing practices that consider environmental, social, and governance factors in supplier selection. |
| 03.05 | Stakeholder Inclusion | Meaningful engagement with affected parties including workers, communities, and civil society in governance processes. |
| 03.06 | Data Privacy | Protection of personal information and responsible data handling in compliance with privacy regulations and ethical standards. |
| 03.07 | Intellectual Property Protection | Respecting intellectual property rights including patents, trademarks, copyrights, and trade secrets. |
| 03.08 | Competitive Fairness | Ensuring fair market practices, preventing anti-competitive behavior, and maintaining a level playing field. |

### 04 Product Integrity

Ensuring products are safe, reliable, and meet quality and sustainability standards throughout their lifecycle.

> UN SDGs 9, 12; OECD Guidelines Chapter VIII: Consumer Interests; EU ESPR Art. 4-7 and Annex I.

| Code | Topic | Definition |
| --- | --- | --- |
| 04.01 | Product Safety Standards | Ensuring consumer safety through compliance with product safety requirements, testing, and hazard prevention. |
| 04.02 | Quality Performance | Meeting defined performance specifications, functional requirements, and quality benchmarks for products and services. |
| 04.03 | Substance Control | Banning or restricting harmful materials and substances of concern in product composition and manufacturing. |
| 04.04 | Product Longevity | Enhancing product durability, repairability, and lifespan to reduce premature obsolescence and waste. |
| 04.05 | Standards Adherence | Compliance with applicable product certifications, industry standards, and regulatory requirements. |
| 04.06 | Supply Chain Traceability | Tracking product origins, components, and transformations throughout the supply chain to enable transparency and accountability. |
| 04.07 | Consumer Information | Providing clear, accurate, and accessible product labeling and information to enable informed consumer choices. |
| 04.08 | End-of-Life Management | Effective collection, recycling, and disposal processes for products at end of useful life, minimizing environmental impact. |

### 05 Circular Value Chains

Advancing sustainability, circularity, and responsible practices throughout supply and production networks.

> UN SDGs 8, 12, 17; OECD Guidelines Chapter II: General Policies and Chapter VI: Environment; EU ESPR Art. 8, 10.

| Code | Topic | Definition |
| --- | --- | --- |
| 05.01 | Ethical Material Sourcing | Procuring raw materials through sustainable and responsible practices, avoiding conflict minerals and environmentally destructive extraction. |
| 05.02 | Supplier Sustainability | Ensuring suppliers meet environmental, social, and governance requirements through assessment, monitoring, and collaboration. |
| 05.03 | Resource Circularity | Promoting reuse, remanufacturing, and recycling of materials to create closed-loop resource flows. |
| 05.04 | Energy Optimization | Improving energy efficiency across supply chain operations including manufacturing, logistics, and warehousing. |
| 05.05 | Supply Chain Labor Rights | Ensuring fair treatment of workers throughout the supply chain including subcontractors and informal workers. |
| 05.06 | Origin Tracking | Transparent documentation and verification of material and product origins throughout the supply chain. |
| 05.07 | Supplier Development | Building supplier capacity and capability to meet sustainability requirements through training, support, and partnership. |
| 05.08 | Supply Chain Risk Reduction | Identifying, assessing, and mitigating environmental, social, and operational vulnerabilities in supply networks. |

### 06 Economic Sustainability

Balancing profitability with sustainable economic practices that create shared value for businesses and communities.

> UN SDGs 8, 9; OECD Guidelines Chapter II: General Policies; EU ESPR Art. 5, 7, 10, 11.

| Code | Topic | Definition |
| --- | --- | --- |
| 06.01 | Business Resilience | Building long-term profitability and organizational resilience through sustainable business models and practices. |
| 06.02 | Sustainable Investment | Directing capital toward green initiatives, sustainable technologies, and projects with positive environmental and social outcomes. |
| 06.03 | Green Innovation | Developing sustainable technologies, processes, and business models that reduce environmental impact while creating economic value. |
| 06.04 | Employment Opportunities | Creating decent jobs and fostering inclusive economic participation through sustainable business growth. |
| 06.05 | Regional Economic Growth | Supporting local economic development and equitable distribution of economic benefits in communities of operation. |
| 06.06 | Resource Efficiency | Optimizing resource utilization to reduce costs and environmental impact while maintaining productivity. |
| 06.07 | Economic Risk Management | Assessing and managing financial risks arising from environmental, social, and governance factors. |
| 06.08 | Supply Network Strength | Enhancing the stability, diversity, and resilience of value chain networks against disruption. |

### 07 Health and Safety Assurance

Prioritizing the health and safety of workers and communities through hazard prevention, preparedness, and wellbeing support.

> UN SDG 3; OECD Guidelines Chapter V: Employment and Industrial Relations; EU ESPR Art. 5, 10 and Annex I.

| Code | Topic | Definition |
| --- | --- | --- |
| 07.01 | Workplace Hazard Control | Systematic identification, assessment, and mitigation of workplace hazards to reduce risk of injury and illness, including incident reporting, investigation, and corrective action. |
| 07.02 | Emergency Readiness | Preparedness planning, training, and response capabilities for workplace emergencies including fire, chemical spills, and natural disasters. |
| 07.03 | Exposure Management | Controlling worker exposure to harmful chemical, biological, and physical agents through monitoring and protective measures. |
| 07.04 | Living Conditions | Ensuring safe, sanitary, and dignified accommodation for workers where employer-provided housing is applicable. |
| 07.05 | Healthcare Access | Providing access to medical support, occupational health services, and health insurance for workers. |
| 07.06 | Wellbeing Support | Addressing worker mental health, stress management, and overall wellbeing through support programs and workplace culture. |
| 07.07 | Nutrition Standards | Ensuring safe, adequate, and nutritious food provisions for workers where employer-provided meals are applicable. |
| 07.08 | Ergonomic Design | Designing safe physical work environments that minimize musculoskeletal strain and support worker comfort and productivity. |

### 08 Systemic Sustainability

Establishing management frameworks, policies, and processes for systematic improvement of environmental, social, and governance outcomes.

> UN SDGs 12, 16; OECD Guidelines Chapter II: General Policies; EU ESPR Art. 4, 5, 10-12.

| Code | Topic | Definition |
| --- | --- | --- |
| 08.01 | Sustainability Policies | Formal organizational commitments, policies, and targets for environmental, social, and governance performance. |
| 08.02 | Risk Identification | Systematic assessment and prioritization of environmental, social, and governance risks across operations and supply chains. |
| 08.03 | Outcome Tracking | Monitoring, measuring, and reporting on sustainability performance against defined targets and indicators. |
| 08.04 | Capacity Building | Training and developing stakeholder knowledge and skills to implement and maintain sustainability practices. |
| 08.05 | Process Enhancement | Continuous improvement of operational processes to achieve better sustainability outcomes over time. |
| 08.06 | Feedback Channels | Accessible grievance mechanisms, whistleblower protections, and feedback systems for workers, communities, and stakeholders to raise concerns without fear of retaliation. |
| 08.07 | Compliance Verification | Independent audits, inspections, and verification processes to confirm adherence to sustainability standards and regulations. |
| 08.08 | Transparent Communication | Public disclosure and reporting of sustainability policies, performance, and progress to stakeholders. |

### 09 Trade and Market Access

Adherence to trade regulations, customs requirements, market access rules, and cross-border compliance frameworks.

> WTO TBT and SPS Agreements; UNECE Trade Facilitation Recommendations; WCO Harmonized System.

| Code | Topic | Definition |
| --- | --- | --- |
| 09.01 | Import and Export Controls | Compliance with cross-border trade restrictions, licensing requirements, and controlled goods regulations. |
| 09.02 | Customs Classification | Accurate tariff classification and customs valuation of goods in accordance with the Harmonized System and national schedules. |
| 09.03 | Rules of Origin | Verification of product origin to determine eligibility for preferential tariff treatment under trade agreements. |
| 09.04 | Sanctions Compliance | Adherence to international trade sanctions, embargoes, and restricted party screening requirements. |
| 09.05 | Market Authorization | Meeting regulatory requirements for market entry including product registration, type approval, and pre-market conformity assessment. |
| 09.06 | Trade Documentation | Accuracy, completeness, and digital exchange of trade and customs documentation including certificates, invoices, and declarations. |
| 09.07 | Tariff and Duty Compliance | Correct assessment, declaration, and payment of applicable customs duties, taxes, and fees. |
| 09.08 | Mutual Recognition | Acceptance of conformity assessment results, certifications, and test reports across jurisdictions through mutual recognition agreements. |

### 10 Technical Conformity

Adherence to technical regulations, voluntary standards, and conformity assessment procedures that ensure product and process fitness for purpose.

> WTO TBT Agreement; ISO/IEC 17000 series conformity assessment standards; Codex Alimentarius.

| Code | Topic | Definition |
| --- | --- | --- |
| 10.01 | Technical Regulations | Compliance with mandatory government-imposed technical requirements for products, processes, and production methods. |
| 10.02 | Voluntary Standards | Adherence to consensus-based standards developed by recognized standards bodies for products, services, and management systems. |
| 10.03 | Metrology and Measurement | Accuracy and traceability of measurements and calibrations to national and international measurement standards. |
| 10.04 | Testing and Certification | Third-party conformity assessment including laboratory testing, product certification, and inspection by accredited bodies. |
| 10.05 | Sanitary and Phytosanitary Measures | Compliance with food safety, animal health, and plant health standards designed to protect human, animal, and plant life. |
| 10.06 | Interoperability Standards | Conformity with standards ensuring compatibility, data exchange, and seamless interaction between systems, components, and services. |
| 10.07 | Accessibility Requirements | Compliance with inclusive design and accessibility standards ensuring products and services are usable by people with diverse abilities. |
| 10.08 | Performance Specifications | Meeting defined functional, reliability, and performance benchmarks established by regulations, standards, or contractual requirements. |

### 11 Information Security and Digital Trust

Protection of data, digital systems, and information assets, and the establishment of trust frameworks for digital interactions.

> ISO/IEC 27001 Information Security; GDPR; eIDAS; NIST Cybersecurity Framework.

| Code | Topic | Definition |
| --- | --- | --- |
| 11.01 | Data Protection and Privacy | Safeguarding personal and sensitive data in compliance with privacy regulations, consent requirements, and ethical data handling principles. |
| 11.02 | Cybersecurity Controls | Implementation of technical and organizational security measures to protect digital infrastructure from threats and vulnerabilities. |
| 11.03 | Digital Identity and Trust | Verification and assurance of digital identities, credentials, and trust relationships in electronic transactions and communications. |
| 11.04 | Access Management | Controls for authentication, authorization, and system access ensuring only authorized parties can access resources and data. |
| 11.05 | Incident Response and Recovery | Preparedness planning, detection, response procedures, and recovery capabilities for security breaches and system failures. |
| 11.06 | System Integrity and Availability | Ensuring reliability, uptime, and integrity of digital systems through resilient architecture and continuity planning. |
| 11.07 | Encryption and Data Security | Protection of data confidentiality and integrity in transit and at rest through cryptographic controls and key management. |
| 11.08 | Audit Trail and Accountability | Logging, monitoring, and accountability mechanisms for digital activities to support compliance verification and forensic analysis. |
<!-- GENERATED:END conformity-topics -->

<!-- GENERATED:BEGIN performance-metrics -->
## Performance Metrics

A hierarchical vocabulary of standardised performance metrics for tagging fine-grained product and facility-level sustainability claims. Enables automatic roll-up to enterprise-level disclosures aligned with IFRS S1/S2, GRI, ESRS, and EU Battery Regulation. Counterpart to the UNTP Conformity Topic Classification — topics classify what is being assessed, metrics define what is measured.

**Version:** 0.1.0-working

**Top-level categories:** 10  |  **Total concepts:** 79

### 01 Greenhouse Gas Emissions

Metrics for measuring, reporting, and reducing greenhouse gas emissions across all scopes, including absolute values, intensities, and reduction progress.

> IFRS S2 paras 29–36; ESRS E1; GRI 305; GHG Protocol Corporate Standard.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 01.01 | Scope 1 GHG Emissions | Absolute GHG emissions from sources owned or controlled by the reporting entity, in tonnes CO2 equivalent. | TNE | sum | lower |
| 01.02 | Scope 2 GHG Emissions | Indirect GHG emissions from purchased electricity, steam, heating, and cooling consumed by the reporting entity, in tonnes CO2 equivalent. | TNE | sum | lower |
| 01.03 | Scope 3 Upstream Emissions | Indirect GHG emissions occurring in the upstream value chain including purchased goods, transportation, and business travel, in tonnes CO2 equivalent. | TNE | sum | lower |
| 01.04 | Scope 3 Downstream Emissions | Indirect GHG emissions occurring in the downstream value chain including product use, end-of-life treatment, and distribution, in tonnes CO2 equivalent. | TNE | sum | lower |
| 01.05 | Total GHG Emissions | Sum of Scope 1, Scope 2, and Scope 3 greenhouse gas emissions, in tonnes CO2 equivalent. | TNE | sum | lower |
| 01.06 | GHG Emissions Intensity | Greenhouse gas emissions per unit of economic output or physical activity, expressed as kg CO2e per unit of measure. | KGM | weighted-average | lower |
| 01.07 | Product Carbon Footprint | Total lifecycle greenhouse gas emissions attributable to a single product unit, from raw material extraction through end-of-life, in kg CO2 equivalent. | KGM | weighted-average | lower |
| 01.08 | Biogenic Emissions | CO2 emissions from the combustion or biodegradation of biomass, reported separately from fossil-fuel emissions, in tonnes CO2. | TNE | sum | lower |
| 01.09 | GHG Reduction Target Progress | Percentage of committed GHG reduction target achieved, measured against a declared baseline year. | P1 | latest | higher |

### 02 Energy

Metrics for measuring energy consumption, renewable energy share, and energy efficiency across operations and supply chains.

> IFRS S2 para 29; ESRS E1; GRI 302; EU Energy Efficiency Directive.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 02.01 | Total Energy Consumption | Total energy consumed from all sources including fuel, electricity, heating, cooling, and steam, in megawatt hours. | MWH | sum | lower |
| 02.02 | Renewable Energy Percentage | Share of total energy consumption sourced from renewable sources such as solar, wind, hydro, and geothermal. | P1 | weighted-average | higher |
| 02.03 | Energy Intensity | Energy consumed per unit of economic output or physical activity, expressed as MWh per unit of measure. | MWH | weighted-average | lower |
| 02.04 | On-site Renewable Generation | Total renewable energy generated on-site from owned or controlled installations, in megawatt hours. | MWH | sum | higher |
| 02.05 | Non-Renewable Energy Consumption | Energy consumed from non-renewable sources including fossil fuels and nuclear, in megawatt hours. | MWH | sum | lower |

### 03 Water

Metrics for measuring water withdrawal, consumption, discharge, recycling, and usage intensity across operations.

> ESRS E3; GRI 303; CEO Water Mandate; Alliance for Water Stewardship.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 03.01 | Total Water Withdrawal | Total volume of water drawn from surface, ground, sea, produced, or third-party sources, in cubic metres. | MTQ | sum | lower |
| 03.02 | Water Consumption | Volume of water withdrawn that is not returned to the original source, representing net water removed from the environment, in cubic metres. | MTQ | sum | lower |
| 03.03 | Water Recycling Rate | Percentage of total water use that is recycled or reused within operations. | P1 | weighted-average | higher |
| 03.04 | Water Discharge | Total volume of effluent water discharged to surface water, groundwater, or third-party treatment, in cubic metres. | MTQ | sum | lower |
| 03.05 | Water Intensity | Water consumed per unit of economic output or physical activity, expressed as litres per unit of measure. | LTR | weighted-average | lower |
| 03.06 | Water Stress Area Withdrawal | Volume of water withdrawn from areas classified as high or extremely-high baseline water stress, in cubic metres. | MTQ | sum | lower |

### 04 Waste and Circularity

Metrics for measuring waste generation, diversion, recycled content, recyclability, and circular economy performance.

> ESRS E5; GRI 306; EU ESPR Art. 5–8; EU Waste Framework Directive.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 04.01 | Total Waste Generated | Total weight of hazardous and non-hazardous waste generated by operations, in tonnes. | TNE | sum | lower |
| 04.02 | Hazardous Waste Generated | Total weight of waste classified as hazardous under applicable regulations, in tonnes. | TNE | sum | lower |
| 04.03 | Waste Diversion Rate | Percentage of total waste diverted from landfill and incineration through recycling, composting, or other recovery methods. | P1 | weighted-average | higher |
| 04.04 | Recycled Content Percentage | Share of pre-consumer and post-consumer recycled material in the total weight of a product or material input. | P1 | weighted-average | higher |
| 04.05 | Recyclability Rate | Percentage of product weight that is technically recyclable at end of life under available infrastructure. | P1 | weighted-average | higher |
| 04.06 | Material Recovery Rate | Percentage of end-of-life product mass actually recovered through recycling, remanufacturing, or refurbishment processes. | P1 | weighted-average | higher |
| 04.07 | Waste to Landfill | Total weight of waste disposed via landfill, in tonnes. | TNE | sum | lower |
| 04.08 | Product Durability Index | Expected useful life of a product under normal conditions of use, expressed in years or cycles as applicable. | ANN | average | higher |
| 04.09 | Reuse and Remanufacturing Rate | Percentage of product units or components returned to service through reuse, refurbishment, or remanufacturing. | P1 | weighted-average | higher |

### 05 Biodiversity and Land Use

Metrics for measuring deforestation-free sourcing, land-use change, biodiversity impact, and protection of sensitive areas.

> ESRS E4; GRI 304; TNFD; EU Deforestation Regulation; Kunming-Montreal Global Biodiversity Framework.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 05.01 | Deforestation-Free Sourcing | Percentage of raw material inputs verified as sourced without associated deforestation or forest degradation after a declared cut-off date. | P1 | weighted-average | higher |
| 05.02 | Land Use Change | Area of natural ecosystems converted to managed land for production or extraction activities, in hectares. | HAR | sum | lower |
| 05.03 | Biodiversity Impact Score | Composite index quantifying the impact of operations on species diversity and ecosystem integrity, using a recognised assessment framework (e.g., STAR, BII). | C62 | average | lower |
| 05.04 | Protected Area Impact | Area of operations, sourcing, or infrastructure footprint located within or adjacent to legally protected or high-biodiversity-value areas, in hectares. | HAR | sum | lower |

### 06 Pollution

Metrics for measuring air pollutant emissions, hazardous substance releases, and chemical safety performance beyond GHG emissions.

> ESRS E2; GRI 305 (non-GHG); EU Industrial Emissions Directive; Stockholm Convention; Montreal Protocol.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 06.01 | SOx Emissions | Total mass of sulphur oxides released to air from stationary and mobile sources, in tonnes. | TNE | sum | lower |
| 06.02 | NOx Emissions | Total mass of nitrogen oxides released to air from combustion and industrial processes, in tonnes. | TNE | sum | lower |
| 06.03 | VOC Emissions | Total mass of volatile organic compounds released to air from solvents, coatings, and industrial processes, in tonnes. | TNE | sum | lower |
| 06.04 | Particulate Matter Emissions | Total mass of fine particulate matter (PM2.5 and PM10) released to air from operations, in tonnes. | TNE | sum | lower |
| 06.05 | Substances of Concern | Total mass of substances of concern or substances of very high concern (SVHC) present in products or released during production, in kilograms. | KGM | sum | lower |
| 06.06 | Ozone-Depleting Substance Emissions | Total mass of ozone-depleting substances released, measured in kg CFC-11 equivalent. | KGM | sum | lower |

### 07 Workforce

Metrics for measuring labour practices, workplace safety, diversity, equity, and human rights performance across operations and supply chains.

> ESRS S1, S2; GRI 401–409; IFRS S1; ILO Core Conventions; UN Guiding Principles on Business and Human Rights.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 07.01 | Living Wage Coverage | Percentage of workers (including contractor and supply-chain workers in scope) receiving at least a verified living wage. | P1 | weighted-average | higher |
| 07.02 | Lost Time Injury Frequency Rate | Number of lost-time injuries per one million hours worked, measuring workplace safety performance. | C62 | average | lower |
| 07.03 | Gender Pay Gap | Difference in average compensation between male and female employees as a percentage of male average compensation. | P1 | weighted-average | lower |
| 07.04 | Women in Management | Percentage of management and leadership positions held by women. | P1 | weighted-average | higher |
| 07.05 | Training Hours per Employee | Average number of hours of training and professional development provided per employee per year. | HUR | average | higher |
| 07.06 | Collective Bargaining Coverage | Percentage of employees covered by collective bargaining agreements. | P1 | weighted-average | higher |
| 07.07 | Employee Turnover Rate | Percentage of employees who leave the organisation voluntarily or involuntarily during the reporting period. | P1 | average | lower |
| 07.08 | Child Labor Incidents | Number of confirmed incidents of child labor identified in own operations and supply chain during the reporting period. | C62 | count | lower |
| 07.09 | Forced Labor Incidents | Number of confirmed incidents of forced, bonded, or compulsory labor identified in own operations and supply chain during the reporting period. | C62 | count | lower |
| 07.10 | Workforce Diversity Ratio | Representation of under-represented groups in the workforce as a percentage of total headcount, covering gender, ethnicity, disability, and other protected characteristics. | P1 | weighted-average | higher |

### 08 Governance

Metrics for measuring anti-corruption practices, supply chain due diligence, ESG disclosure quality, and grievance mechanism effectiveness.

> ESRS G1; GRI 205, 308, 414; IFRS S1; OECD Guidelines Chapter VII.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 08.01 | Anti-Corruption Training Coverage | Percentage of employees and governance body members who have received anti-corruption training during the reporting period. | P1 | weighted-average | higher |
| 08.02 | Supplier Due Diligence Coverage | Percentage of significant suppliers assessed against environmental and social due diligence criteria during the reporting period. | P1 | weighted-average | higher |
| 08.03 | ESG Disclosure Score | Composite score measuring the completeness, accuracy, and timeliness of environmental, social, and governance public disclosures. | P1 | latest | higher |
| 08.04 | Grievance Response Rate | Percentage of grievances received through formal mechanisms that were acknowledged and addressed within the defined response timeframe. | P1 | average | higher |

### 09 Product Safety and Quality

Metrics for measuring physical, mechanical, thermal, electrical, chemical, and fire safety properties of products and materials against applicable safety standards and performance requirements.

> EU General Product Safety Regulation (EU) 2023/988; ICC International Building Code; ISO/IEC product safety standards; EU Construction Products Regulation.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 09.01 | Mechanical Strength | Tensile, compressive, or flexural strength of a material or product under specified test conditions, in megapascals. | MPA | minimum | higher |
| 09.02 | Impact Resistance | Energy absorbed by a material or product before fracture under impact loading, in joules. | JOU | minimum | higher |
| 09.03 | Thermal Performance | Thermal resistance (R-value) or thermal conductivity of a material or assembly, indicating its ability to insulate against heat transfer. | C62 | weighted-average | higher |
| 09.04 | Fire Resistance Rating | Duration a material or assembly maintains structural integrity, insulation, and limits heat transfer under standard fire exposure conditions, in minutes. | MIN | minimum | higher |
| 09.05 | Electrical Safety Rating | Composite test result or classification for electrical insulation, shock protection, and fault tolerance under applicable safety standards. | C62 | minimum | higher |
| 09.06 | Flammability Rating | Classification of a material's reaction to fire, covering ignitability, flame spread, heat release, and smoke generation under standard test conditions. | C62 | minimum | higher |
| 09.07 | Chemical Substance Concentration | Concentration of a specified regulated or restricted substance present in a product, in milligrams per kilogram. | MK | maximum | lower |
| 09.08 | Noise Emission Level | Sound power or sound pressure level emitted by a product during normal operation, in decibels. | C62 | maximum | lower |

### 10 Food Safety and Quality

Metrics for measuring microbiological safety, chemical contaminant levels, pesticide and veterinary drug residues, food additive levels, nutritional content, and allergen presence in food products.

> Codex Alimentarius (FAO/WHO); EU General Food Law Regulation (EC) 178/2002; EU food safety regulations; ISO 22000.

| Code | Metric | Definition | Unit | Aggregation | Direction |
| --- | --- | --- | --- | --- | --- |
| 10.01 | Microbiological Count | Colony-forming units of a specified microorganism per unit of food, measuring microbiological safety and hygiene performance. | C62 | maximum | lower |
| 10.02 | Chemical Contaminant Level | Concentration of a specified chemical contaminant (heavy metals, mycotoxins, dioxins, etc.) in food, in milligrams per kilogram. | MK | maximum | lower |
| 10.03 | Pesticide Residue Level | Concentration of a specified pesticide residue in food, measured against the applicable maximum residue limit, in milligrams per kilogram. | MK | maximum | lower |
| 10.04 | Veterinary Drug Residue Level | Concentration of a specified veterinary drug residue in animal-derived food, measured against the applicable maximum residue limit, in micrograms per kilogram. | MK | maximum | lower |
| 10.05 | Food Additive Level | Concentration of a specified food additive in the final product, measured against the applicable maximum permitted level, in milligrams per kilogram. | MK | maximum | lower |
| 10.06 | Nutritional Content | Amount of a specified nutrient (energy, protein, fat, carbohydrate, sugar, sodium, fibre, vitamins, minerals) per standard serving or per 100 grams of food. | GRM | average | context-dependent |
| 10.07 | Allergen Presence | Declared presence or measured concentration of a specified allergen in a food product, supporting consumer safety and regulatory labelling requirements. | MK | maximum | lower |
| 10.08 | Shelf Life Duration | Expected period during which a food product maintains safety and quality under stated storage conditions, in days. | DAY | minimum | higher |
<!-- GENERATED:END performance-metrics -->

---

## Core Vocabulary

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

## Artifacts

### Published Vocabulary and Context

The UNTP Core Vocabulary and versioned JSON-LD context files are published as linked data at [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/).

| Artefact | URL |
| --- | --- |
| Core Vocabulary | [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/) |
| V0.7.0 JSON-LD Context | [https://vocabulary.uncefact.org/untp/0.7.0/context/](https://vocabulary.uncefact.org/untp/0.7.0/context/) |

The vocabulary defines persistent linked data URIs for all UNTP classes and properties and is not versioned — terms are stable once published. The JSON-LD context files, which map credential properties to vocabulary URIs, are versioned with each specification release.

## Vocabulary Overview

The UNTP core vocabulary defines the classes and properties that underpin all five UNTP credential types: Digital Product Passport (DPP), Digital Facility Record (DFR), Digital Conformity Credential (DCC), Digital Traceability Event (DTE), and Digital Identity Anchor (DIA). Each credential type is a specialisation of `VerifiableCredential` that wraps a specific domain subject — for example, a DPP wraps a `Product`, while a DCC wraps a `ConformityAttestation`.

The vocabulary is designed to **extend, not duplicate**, established external vocabularies. The credential envelope inherits from the [W3C Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/), and the `Address` class extends [schema:PostalAddress](https://schema.org/PostalAddress). UNTP only defines properties that are specific to supply chain transparency — all inherited properties from W3C VCDM and Schema.org are referenced, not redefined.

The diagram below shows the high-level structure of the vocabulary. Five credential types each compose a domain subject class. A central design principle is **verifiable performance claims** — both products (via DPP) and facilities (via DFR) carry `Claim` objects that reference specific `Criterion` definitions. Independent conformity assessments (via DCC) evaluate the same criteria, providing third-party verification of the supplier's own claims. This shared reference to common criteria is what makes UNTP claims verifiable: a buyer can match a product's self-declared claims against independent assessment results for the same criteria. Traceability events (via DTE) record product lifecycle activities — manufacturing, movement, and modification — linking products to the facilities where these activities occur. `Party` is a shared class referenced across all subjects to identify the organisations involved.

```mermaid
classDiagram
    direction TB

    class VerifiableCredential {
        &lt;&lt;extends W3C VCDM&gt;&gt;
    }

    VerifiableCredential <|-- DigitalProductPassport
    VerifiableCredential <|-- DigitalFacilityRecord
    VerifiableCredential <|-- DigitalConformityCredential
    VerifiableCredential <|-- DigitalTraceabilityEvent
    VerifiableCredential <|-- DigitalIdentityAnchor

    DigitalProductPassport *-- Product : subject
    DigitalFacilityRecord *-- Facility : subject
    DigitalConformityCredential *-- ConformityAttestation : subject
    DigitalTraceabilityEvent *-- LifecycleEvent : subject
    DigitalIdentityAnchor *-- RegisteredIdentity : subject

    Product --> Facility : producedAt
    Product --> Material : materialProvenance
    Product --> Package : packaging
    Product --> Claim : performanceClaim
    Product --> Party : relatedParty

    Facility --> Claim : performanceClaim
    Facility --> Party : relatedParty

    ConformityAttestation --> ConformityAssessment : conformityAssessment
    ConformityAssessment --> Product : assessedProduct
    ConformityAssessment --> Facility : assessedFacility
    ConformityAssessment --> Criterion : assessmentCriteria

    Claim --> Criterion : referenceCriteria

    LifecycleEvent <|-- MakeEvent
    LifecycleEvent <|-- MoveEvent
    LifecycleEvent <|-- ModifyEvent
    MakeEvent --> Product : input/output
    MakeEvent --> Facility : madeAt
    MoveEvent --> Product : movedProduct
    MoveEvent --> Facility : from/to
    ModifyEvent --> Product : modifiedProduct
    ModifyEvent --> Facility : modifiedAt

    RegisteredIdentity --> Party : identifies
```

The reference tables below are **auto-generated** from the machine-readable ontology at [`untp-ontology.jsonld`](https://vocabulary.uncefact.org/untp/). Re-generate by running:

```bash
node .claude/scripts/generate-ontology-docs.js
```

<!-- GENERATED:BEGIN ontology -->
## Credential Types

### VerifiableCredential

A verifiable credential is a digital and verifiable version of everyday credentials such as certificates and licenses. It conforms to the W3C Verifiable Credentials Data Model v2.0 (VCDM).

**Extends:** [`VerifiableCredential`](https://www.w3.org/2018/credentials#VerifiableCredential) — inherited properties from the external vocabulary are not repeated here.

### DigitalProductPassport

A digital Product Passport (DPP) credential.

**Credential Subject:** [Product](#product)

**Sub-class of:** [VerifiableCredential](#verifiablecredential)

### DigitalFacilityRecord

A digital Facility Record (DFR) credential.

**Credential Subject:** [Facility](#facility)

**Sub-class of:** [VerifiableCredential](#verifiablecredential)

### DigitalConformityCredential

A Digital Conformity Credential (DCC) credential.

**Credential Subject:** [ConformityAttestation](#conformityattestation)

**Sub-class of:** [VerifiableCredential](#verifiablecredential)

### DigitalTraceabilityEvent

A Digital Traceability Event (DTE) credential.

**Credential Subject:** [LifecycleEvent](#lifecycleevent)

**Sub-class of:** [VerifiableCredential](#verifiablecredential)

### DigitalIdentityAnchor

The Digital Identity Anchor (DIA) is a very simple credential that is issued by a trusted authority and asserts an equivalence between a member identity as known to the authority (eg a VAT number) and one or more decentralised identifiers (DIDs) held by the member.

**Credential Subject:** [RegisteredIdentity](#registeredidentity)

**Sub-class of:** [VerifiableCredential](#verifiablecredential)

## Domain Classes

### Address

A postal address. Reuses streetAddress, postalCode, addressLocality, and addressRegion from schema.org PostalAddress. Extends with addressCountry (an ISO-3166 country code/name structure).

**Extends:** [`PostalAddress`](https://schema.org/PostalAddress) — inherited properties from the external vocabulary are not repeated here.

| Property | Type | Description |
| --- | --- | --- |
| addressCountry | [Country](#country) | The address country as an ISO-3166 two letter country code and name. |

### BitstringStatusListEntry

A privacy-preserving, space-efficient, and high-performance mechanism for publishing status information such as suspension or revocation of Verifiable Credentials through use of bitstrings.  See https://www.w3.org/TR/vc-bitstring-status-list/ for full details.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | optional identifier of this status list entry. |
| type | string | The type of status list - must be set to "The type property MUST be BitstringStatusListEntry." |
| statusPurpose | [CredentialStatus](#credentialstatus) | Status purpose drawn from a standard list but extensible as per w3c bitstring status list specification. |
| statusListIndex | integer | The statusListIndex property MUST be an arbitrary size integer greater than or equal to 0, expressed as a string in base 10. The value identifies the position of the status of the verifiable credential. |
| statusListCredential | URI | The statusListCredential property MUST be a URL to a verifiable credential. When the URL is dereferenced, the resulting verifiable credential MUST have type property that includes the BitstringStatusListCredential value. |

### Characteristics

A declaration of conformance with one or more criteria from a specific standard or regulation.

### Claim

A performance claim about a product, facility, or organisation that is made against a well defined criterion.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this claim. Typically represented as a URI companyURL/claimID URI or a UUID |
| name | string | Name of this claim - typically similar or the same as the referenced criterion name. |
| description | string | Description of this conformity claim |
| applicablePeriod | [Period](#period) | The applicable reporting period for this facility record. |
| referenceCriteria | [Criterion](#criterion) | The criterion against which the claim is made. |
| referenceRegulation | [Regulation](#regulation) | List of references to regulation to which conformity is claimed claimed for this product |
| referenceStandard | [Standard](#standard) | List of references to standards to which conformity is claimed claimed for this product |
| claimDate | date | That date on which the claimed performance is applicable. |
| claimedPerformance | [Performance](#performance) | The claimed performance level |
| evidence | [Link](#link) | A URI pointing to the evidence supporting the claim. SHOULD be a URL to a UNTP Digital Conformity Credential (DCC) |
| conformityTopic | [ConformityTopic](#conformitytopic) | The conformity topic category for this assessment |

### Classification

A classification scheme and code / name representing a category value for a product, entity, or facility.

| Property | Type | Description |
| --- | --- | --- |
| name | string | Name of the classification represented by the code |
| code | string | classification code within the scheme |
| definition | string | A rich definition of this classification code. |
| schemeId | URI | Classification scheme ID |
| schemeName | string | The name of the classification scheme |

### ConformityAssessment

A specific assessment about the product or facility against a specific specification.  Eg the carbon intensity of a given product or batch.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this assessment. Typically represented as a URI AssessmentBody/Assessment URI or a UUID |
| name | string | Name of this assessment - typically similar or the same as the referenced criterion name. |
| description | string | Description of this conformity assessment |
| referenceRegulation | [Regulation](#regulation) | The reference to the regulation that defines the assessment criteria |
| referenceStandard | [Standard](#standard) | The reference to the standard that defines the specification / criteria |
| evidence | [Link](#link) | Evidence to support this specific assessment. |
| conformityTopic | [ConformityTopic](#conformitytopic) | The UNTP conformity topic used to categorise this assessment. Should match the topic defined by the scheme criterion. |
| assessmentCriteria | [Criterion](#criterion) | The specification against which the assessment is made. |
| assessmentDate | date | The date on which this assessment was made. |
| assessedPerformance | [Performance](#performance) | The assessed performance against criteria. |
| assessedProduct | [ProductVerification](#productverification) | The product which is the subject of this assessment. |
| assessedFacility | [FacilityVerification](#facilityverification) | The facility which is the subject of this assessment. |
| assessedOrganisation | [Party](#party) | An organisation that is the subject of this assessment. |
| specifiedCondition | string | A list of specific conditions that constrain this conformity assessment. For example a specific jurisdiction, material type, or test method. |
| conformance | boolean | An indicator (true / false) whether the outcome of this assessment is conformant to the requirements defined by the standard or criterion. |

### ConformityAttestation

A conformity attestation issued by a competent body that defines one or more assessments (eg carbon intensity) about a product (eg battery) against a specification (eg LCA method) defined in a standard or regulation.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this attestation. Typically represented as a URI AssessmentBody/CertificateID URI or a UUID |
| name | string | Name of this attestation - typically the title of the certificate. |
| description | string | Description of this attestation. |
| assessorLevel | [AssessorLevel](#assessorlevel) | Assurance code pertaining to assessor (relation to the object under assessment) |
| assessmentLevel | [AssessmentLevel](#assessmentlevel) | Assurance pertaining to assessment (any authority or support for the assessment process) |
| attestationType | [AttestationType](#attestationtype) | The type of criterion (optional or mandatory). |
| issuedToParty | [Party](#party) | The party to whom the conformity attestation was issued. |
| authorisation | [Endorsement](#endorsement) | The authority under which a conformity claim is issued.  For example a national accreditation authority may authorise a test lab to issue test certificates about a product against a standard. |
| referenceScheme | [ConformityScheme](#conformityscheme) | The conformity scheme under which this attestation is made. |
| referenceProfile | [ConformityProfile](#conformityprofile) | The specific versioned conformity profile (comprising a set of versioned criteria) against which this conformity attestation is made. |
| profileScore | [Score](#score) | The overall performance against a scheme level performance measurement framework for the referenced profile or scheme. |
| conformityCertificate | [Link](#link) | A reference to the human / printable version of this conformity attestation - typically represented as a PDF document. The document may have more details than are represented in the digital attestation. |
| auditableEvidence | [Link](#link) | Auditable evidence supporting this assessment such as raw measurements, supporting documents. This is usually private data and would normally be encrypted. |
| trustmark | [Image](#image) | A trust mark as a small binary image encoded as base64 with a description.  Maye be displayed on the conformity credential rendering. |
| conformityAssessment | [ConformityAssessment](#conformityassessment) | A list of individual assessment made under this attestation. |

### ConformityProfile

A versioned conformity profile, managed under a scheme, which includes a specific list of versioned criteria. A conformity profile represents the precise scope of a conformity attestation.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this context specific conformity profile. Typically represented as a URI SchemeOwner/profileID URI |
| name | string | Name of this conformity profile as defined by the scheme owner. |
| description | string | The description of this versioned and context specific conformity profile. |
| version | string | Version of this scheme following SemVer best practice (major.minor.patch). |
| status | [CriterionStatus](#criterionstatus) | The status of this conformity profile (draft, active, deprecated) |
| documentation | URI | A web page that describes this entity in detail. |
| validFrom | date | The data from which this scheme version is valid. |
| subjectType | [AssessmentSubjectType](#assessmentsubjecttype) | The type of the subject of assessments made under this conformity profile (eg product, facility, organisation) |
| standardAlignment | [StandardAlignment](#standardalignment) | A list of voluntary standards referenced by this conformity profile and against which some level of compliance can be inferred for subjects that pass an assessment. |
| regulatoryAlignment | [RegulatoryAlignment](#regulatoryalignment) | A list of regulations or legally binding conventions referenced by this conformity profile and against which some level of compliance can be inferred for subjects that pass an assessment. |
| criterionScoringFramework | [ScoringFramework](#scoringframework) | A list of named scoring frameworks that are applied by criterion within this profile. |
| criterion | [Criterion](#criterion) | A list of criterion that are included in this conformity profile. |
| scope | [Classification](#classification) | A set of classification codes that may be used to categorize the applicability of this criteria - for example industry sector, jurisdiction or commodity type - based on a formal vocabulary. |
| scheme | [ConformityScheme](#conformityscheme) | The conformity scheme under which this versioned profile is maintained. |

### ConformityScheme

A formal governance scheme under which an attestation is issued (eg ACRS structural steel certification)

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this conformity scheme. Typically represented as a URI SchemeOwner/SchemeName URI |
| name | string | Name of this scheme as defined by the scheme owner. |
| description | string | Description of this conformity scheme |
| documentation | URI | A web page providing full documentation of this scheme. |
| trustmark | [Image](#image) | The trust mark or seal used by this conformity scheme. |
| owner | [Party](#party) | The party that is the owner / maintainer of this conformity scheme. |
| endorsementLevel | [SchemeEndorsementLevel](#schemeendorsementlevel) | The scheme assurance type. |
| endorsement | [Endorsement](#endorsement) | The endorsement provided to the scheme by an external authority such as a regulator, an accreditaiton authority, or a benchmarking scheme. |
| schemeScoringFramework | [ScoringFramework](#scoringframework) | The scheme level overall scoring framework that represents the achievement levels (AA, A, B etc) that maybe be awarded to the subject of an independent assessment under the scheme. |
| licenseType | [LicenseType](#licensetype) | Descriptive name and URL link to the license conditions associated with this scheme. |
| establishedDate | date | The date when this scheme was first established. |
| geographicScope | [Classification](#classification) | The geographic scope of this scheme as a list of ISO-3166 countries, regions, or code=001, name=Worldwide to indicate global coverage. |
| industryScope | [Classification](#classification) | A list of UN ISIC code & name indicating the industry scope for this scheme. |
| conformsTo | [Link](#link) | The name and URI of the vocabulary standard (eg UNTP CVC) that the machine readable version of this sceme conforms to. |
| includedProfile | [ConformityProfile](#conformityprofile) | The list of versioned conformity profiles included in this scheme |

### ConformityTopic

The UNTP standard classification scheme for conformity topic.  see http://vocabulary.uncefact.org/ConformityTopic

| Property | Type | Description |
| --- | --- | --- |
| id | URI | The unique identifier for this conformity topic |
| name | string | The human readable name for this conformity topic. |
| definition | string | The rich definition of this conformity topic. |

### Coordinate

A geographic point defined by latitude and longitude using the WGS84 geodetic coordinate reference system (EPSG:4326). Latitude and longitude are expressed in decimal degrees as floating-point numbers. Coordinates follow the conventional order (latitude, longitude) and represent a point on the Earth’s surface.

| Property | Type | Description |
| --- | --- | --- |
| latitude | number | latitude: Angular distance north or south of the equator, expressed in decimal degrees.Valid range: −90.0 to +90.0. |
| longitude | number | longitude: Angular distance east or west of the Prime Meridian, expressed in decimal degrees.Valid range: −180.0 to +180.0. |

### Country

Country Code and Name from ISO 3166

| Property | Type | Description |
| --- | --- | --- |
| countryCode | [CountryCode](#countrycode) | ISO 3166 country code |
| countryName | string | Country Name as defined in ISO 3166 |

### CredentialIssuer

The issuer party (person or organisation) of a verifiable credential.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | The W3C DID of the issuer - should be a did:web or did:webvh |
| name | string | The name of the issuer person or organisation |
| issuerAlsoKnownAs | [Party](#party) | An optional list of other registered identifiers for this credential issuer |

### Criterion

A specific rule or criterion within a standard or regulation. eg a carbon intensity calculation rule within an emissions standard.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this conformity criterion. Typically represented as a URI SchemeOwner/CriterionID URI |
| name | string | Name of this criterion as defined by the scheme owner. |
| description | string | Description of this criterion |
| conformityTopic | [ConformityTopic](#conformitytopic) | A global UN/CEFACT standard conformity topic code. |
| version | string | The major.minor version of the criterion. Minor versions represent changes that would not invalidate an assessment made under a previous version. |
| status | [CriterionStatus](#criterionstatus) | The lifecycle status of this criterion. |
| documentation | URI | A web page carrying detailed information about this criterion. |
| requiredPerformance | [Performance](#performance) | The required performance level as one or more score and/or a metric that represents compliance defined by the criteria |
| tag | string | A set of tags that can be used by the scheme owner to be able to filter or group criterion in a large vocabulary for specific use cases. |

### Dimension

Overall (length, width, height) dimensions and weight/volume of an item.

| Property | Type | Description |
| --- | --- | --- |
| weight | [Measure](#measure) | the weight of the product. EG \{"value":10, "unit":"KGM"\} |
| length | [Measure](#measure) | The length of the product or packaging eg \{"value":840, "unit":"MMT"\} |
| width | [Measure](#measure) | The width of the product or packaging. eg \{"value":150, "unit":"MMT"\} |
| height | [Measure](#measure) | The height of the product or packaging. eg \{"value":220, "unit":"MMT"\} |
| volume | [Measure](#measure) | The displacement volume of the product. eg \{"value":7.5, "unit":"LTR"\} |

### Endorsement

The authority under which a conformity claim is issued.  For example a national accreditation authority may authorise a test lab to issue test certificates about a product against a standard.

| Property | Type | Description |
| --- | --- | --- |
| name | string | The name of the accreditation. |
| trustmark | [Image](#image) | The trust mark image awarded by the AB to the CAB to indicate accreditation. |
| issuingAuthority | [Party](#party) | The competent authority that issued the accreditation. |
| endorsementEvidence | [Link](#link) | The evidence that supports the authority under which the attestation is issued - for an example an accreditation certificate. |

### Entity

A uniquely identified entity

| Property | Type | Description |
| --- | --- | --- |
| id | URI | The globally unique identifier of this entity. |
| name | string | The name of this entity. |
| description | string | A rich descrition of this identified entity. |

### EventProduct

A quantity of products or materials involved in a lifecycle event.

| Property | Type | Description |
| --- | --- | --- |
| product | [Product](#product) | The product item / model / batch subject to this lifecycle event. |
| quantity | [Measure](#measure) | The quantity of product subject to this lifecycle event.  Not needed for serialised items. |
| disposition | [ProductStatus](#productstatus) | The status of the product after the event has happened. |

### Facility

The physical site (eg farm or factory) where the product or materials was produced.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this facility. Typically represented as a URI identifierScheme/Identifier URI |
| name | string | Name of this facility as defined the location register. |
| description | string | Description of the facility including function and other names. |
| registeredId | string | The registration number (alphanumeric) of the facility within the identifier scheme. Unique within the register. |
| idScheme | [IdentifierScheme](#identifierscheme) | The ID scheme of the facility. eg a GS1 GLN or a National land registry scheme. If self issued then use the party ID of the facility owner. |
| countryOfOperation | [Country](#country) | The country in which this facility is operating.using ISO-3166 code and name. |
| processCategory | [Classification](#classification) | The industrial or production processes performed by this facility. Example unstats.un.org/isic/1030. |
| relatedParty | [PartyRole](#partyrole) | A list of parties with a specified role relationship to this facility |
| relatedDocument | [Link](#link) | A list of links to documents providing additional facility information. Documents that support a conformity claim (e.g. permits or certificates) SHOULD be referenced as claim evidence rather than here. |
| facilityAlsoKnownAs | [Facility](#facility) | An optional list of other registered identifiers for this facility - eg GLNs or other schemes. |
| locationInformation | [Location](#location) | Geo-location information for this facility as a resolvable geographic area (a Plus Code), and/or a geo-located point (latitude / longitude), and/or a defined boundary (GeoJSON Polygon). |
| address | [Address](#address) | The Postal address of the location. |
| materialUsage | [MaterialUsage](#materialusage) | The type and provenance of materials consumed by the facility during the reporting period. |
| performanceClaim | [Claim](#claim) | A list of performance claims (eg deforestation status) for this facility. |

### FacilityVerification

The facility which is the subject of this conformity assessment

| Property | Type | Description |
| --- | --- | --- |
| idVerifiedByCAB | boolean | Indicates whether the conformity assessment body has verified the identity of the facility which is the subject of the assessment. |
| facility | [Facility](#facility) | The facility which is the subject of this assessment |

### IdentifierScheme

An identifier registration scheme for products, facilities, or organisations. Typically operated by a state, national or global authority.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | The URI of this identifier scheme |
| name | string | The name of the identifier scheme. |

### Image

A binary image encoded as base64 text and embedded into the data.  Use this for small images like certification trust marks or regulated labels.  Large images should be external links.

| Property | Type | Description |
| --- | --- | --- |
| name | string | the display name for this image |
| description | string | The detailed description / supporting information for this image. |
| mediaType | string | The media type of this image (eg image/png) |
| imageData | string | The image data encoded as a base64 string. |

### LifecycleEvent

This abstract event structure provides a common language to describe product lifecycle events such as shipments, inspections, manufacturing processes, etc.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique ID for this lifecycle event. Should be a URI. Can be a UUID. |
| name | string | The name for this lifecycle event |
| description | string | The description of this lifecycle event. |
| relatedParty | [PartyRole](#partyrole) | Any related parties and their roles involved in this event (eg the carrier for a shipment event) |
| relatedDocument | [Link](#link) | A list of links to documentary evidence that supports this event. |
| eventDate | dateTime | The date and time at which this lifecycle event occurs. use 00:00 for time if only a date is required. |
| sensorData | [SensorData](#sensordata) | A sensor data set associated with this lifecycle event. |
| activityType | [Classification](#classification) | The business activity that this event represents (eg shipping, repair, etc) using a standard classification scheme - eg https://ref.gs1.org/cbv/BizStep. This may be replaced with industry specific vocabularies (ginning, spinning, weaving, dyeing, etc in textiles) |

### Link

A structure to provide a URL link plus metadata associated with the link.

| Property | Type | Description |
| --- | --- | --- |
| mediaType | string | The media type of the target resource. |
| digestMultibase | string | An optional multi-base encoded digest to ensure the content of the link has not changed. See https://www.w3.org/TR/vc-data-integrity/#resource-integrity for more information. |
| linkURL | URI | The URL of the target resource. |
| linkName | string | Display name for this link. |
| linkType | string | The type of the target resource - drawn from a controlled vocabulary |

### Location

Location information including address and geo-location of points, areas, and boundaries. At least one of plusCode, geoLocation, or geoBoundary are required.

| Property | Type | Description |
| --- | --- | --- |
| plusCode | URI | An open location code (https://maps.google.com/pluscodes/) representing this geographic location or region. Open location codes can represent any sized area from a point to a large region and are easily resolved to a visual map location. |
| geoLocation | [Coordinate](#coordinate) | The latitude and longitude coordinates that best represent the specified location. |
| geoBoundary | [Coordinate](#coordinate) | The list of ordered coordinates that define a closed area polygon as a location boundary. The first and last coordinates in the array must match - thereby defining a closed boundary. |

### MakeEvent

Transformation (manufacture/  production) of input products to output products at a given facility.

**Sub-class of:** [LifecycleEvent](#lifecycleevent)

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique ID for this lifecycle event. Should be a URI. Can be a UUID. |
| name | string | The name for this lifecycle event |
| description | string | The description of this lifecycle event. |
| relatedParty | [PartyRole](#partyrole) | Any related parties and their roles involved in this event (eg the carrier for a shipment event) |
| relatedDocument | [Link](#link) | A list of links to documentary evidence that supports this event. |
| eventDate | dateTime | The date and time at which this lifecycle event occurs. use 00:00 for time if only a date is required. |
| sensorData | [SensorData](#sensordata) | A sensor data set associated with this lifecycle event. |
| activityType | [Classification](#classification) | The business activity that this event represents (eg shipping, repair, etc) using a standard classification scheme - eg https://ref.gs1.org/cbv/BizStep. This may be replaced with industry specific vocabularies (ginning, spinning, weaving, dyeing, etc in textiles) |
| inputProduct | [EventProduct](#eventproduct) | An array of input products and quantities for this production or manufacturing process |
| outputProduct | [EventProduct](#eventproduct) | An array of output products and quantities for this produciton or manufacturing process |
| madeAtFacility | [Facility](#facility) | The facility at which this production / manufacturing event happens. |

### Material

The material class encapsulates details about the origin or source of raw materials in a product, including the country of origin and the mass fraction.

| Property | Type | Description |
| --- | --- | --- |
| name | string | Name of this material (eg "Egyptian Cotton") |
| originCountry | [Country](#country) | A ISO 3166-1 code representing the country of origin of the component or ingredient. |
| materialType | [Classification](#classification) | The type of this material - as a value drawn from a controlled vocabulary eg from UN Framework Classification for Resources (UNFC). |
| massFraction | number | The mass fraction as a decimal of the product (or facility reporting period)  represented by this material. |
| mass | [Measure](#measure) | The mass of the material component. |
| recycledMassFraction | number | Mass fraction of this material that is recycled (eg 50% recycled Lithium) |
| hazardous | boolean | Indicates whether this material is hazardous. If true then the materialSafetyInformation property must be present |
| symbol | [Image](#image) | Based 64 encoded binary used to represent a visual symbol for a given material. |
| materialSafetyInformation | [Link](#link) | Reference to further information about safe handling of this hazardous material (for example a link to a material safety data sheet) |

### MaterialUsage

A material usage record defining the consumption of materials for a given period, typically at an operating facility.  Used to specify volumetric consumption and country of origin without specifying specific suppliers.

| Property | Type | Description |
| --- | --- | --- |
| applicablePeriod | [Period](#period) | The period over which this material consumption is reported |
| materialConsumed | [Material](#material) | An list of materials consumed during the usage period. |

### Measure

The measure class defines a numeric measured value (eg 10) and a coded unit of measure (eg KG).  There is an optional upper and lower tolerance which can be used to specify uncertainty in the measure.

| Property | Type | Description |
| --- | --- | --- |
| value | number | The numeric value of the measure |
| upperTolerance | number | The upper tolerance associated with this measure expressed in the same units as the measure.  For example value=10, upperTolerance=0.1, unit=KGM would mean that this measure is 10kg + 0.1kg |
| lowerTolerance | number | The lower tolerance associated with this measure expressed in the same units as the measure.  For example value=10, lowerTolerance=0.1, unit=KGM would mean that this measure is 10kg - 0.1kg |
| unit | [UnitOfMeasure](#unitofmeasure) | Unit of measure drawn from the UNECE Rec20 measure code list. |

### ModifyEvent

Intervention (eg repair) on a product without changing it's identity at a given facility.

**Sub-class of:** [LifecycleEvent](#lifecycleevent)

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique ID for this lifecycle event. Should be a URI. Can be a UUID. |
| name | string | The name for this lifecycle event |
| description | string | The description of this lifecycle event. |
| relatedParty | [PartyRole](#partyrole) | Any related parties and their roles involved in this event (eg the carrier for a shipment event) |
| relatedDocument | [Link](#link) | A list of links to documentary evidence that supports this event. |
| eventDate | dateTime | The date and time at which this lifecycle event occurs. use 00:00 for time if only a date is required. |
| sensorData | [SensorData](#sensordata) | A sensor data set associated with this lifecycle event. |
| activityType | [Classification](#classification) | The business activity that this event represents (eg shipping, repair, etc) using a standard classification scheme - eg https://ref.gs1.org/cbv/BizStep. This may be replaced with industry specific vocabularies (ginning, spinning, weaving, dyeing, etc in textiles) |
| modifiedProduct | [EventProduct](#eventproduct) | An array of products and quantities for this intervention (repair, inspection, etc) |
| modifiedAtFacility | [Facility](#facility) | The facility at which this intervention event happens. |

### MoveEvent

Transfer (shipment) of products from one facility to another.

**Sub-class of:** [LifecycleEvent](#lifecycleevent)

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique ID for this lifecycle event. Should be a URI. Can be a UUID. |
| name | string | The name for this lifecycle event |
| description | string | The description of this lifecycle event. |
| relatedParty | [PartyRole](#partyrole) | Any related parties and their roles involved in this event (eg the carrier for a shipment event) |
| relatedDocument | [Link](#link) | A list of links to documentary evidence that supports this event. |
| eventDate | dateTime | The date and time at which this lifecycle event occurs. use 00:00 for time if only a date is required. |
| sensorData | [SensorData](#sensordata) | A sensor data set associated with this lifecycle event. |
| activityType | [Classification](#classification) | The business activity that this event represents (eg shipping, repair, etc) using a standard classification scheme - eg https://ref.gs1.org/cbv/BizStep. This may be replaced with industry specific vocabularies (ginning, spinning, weaving, dyeing, etc in textiles) |
| movedProduct | [EventProduct](#eventproduct) | An array of products and quantities for this movement / shipment process |
| fromFacility | [Facility](#facility) | The source facility for this movement / shipment of products |
| toFacility | [Facility](#facility) | The destination facility for this movement / shipment of products |
| consignmentId | URI | The consignment ID related to this movement of products. Ideally this is a resolvable URL but if not available then use a URN notation such as urn:carrier:waybillNumber. |

### Package

Details of product packaging

| Property | Type | Description |
| --- | --- | --- |
| description | string | Description of the packaging. |
| performanceClaim | [Claim](#claim) | conformity claims made about the packaging. |
| dimensions | [Dimension](#dimension) | dimensions of the packaging |
| materialUsed | [Material](#material) | materials used for the packaging. |
| packageLabel | [Image](#image) | An array of package labels that may appear on the packaging together with their meaning. Use for small images that represent certification marks or regulatory requirements. Large images should be linked as evidence to claims. |

### Party

An organisation.  May be a supply chain actor, a certifier, a government agency.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this party. Typically represented as a URI identifierScheme/Identifier URI |
| name | string | Legal registered name of this party. |
| description | string | Description of the party including function and other names. |
| registeredId | string | The registration number (alphanumeric) of the Party within the register. Unique within the register. |
| idScheme | [IdentifierScheme](#identifierscheme) | The identifier scheme of the party.  Typically a national business register or a global scheme such as GLEIF. |
| registrationCountry | [Country](#country) | the country in which this organisation is registered - using ISO-3166 code and name. |
| partyAddress | [Address](#address) | The address of the party |
| organisationWebsite | URI | Website for this organisation |
| industryCategory | [Classification](#classification) | The industry categories for this organisation.  Recommend use of UNCPC as the category scheme. for example - unstats.un.org/isic/1030 |
| partyAlsoKnownAs | [Party](#party) | An optional list of other registered identifiers for this organisation. For example DUNS, GLN, LEI, etc |

### PartyRole

A party with a defined relationship to the referencing entity

| Property | Type | Description |
| --- | --- | --- |
| role | [PartyRole](#partyrole) | The role played by the party in this relationship |
| party | [Party](#party) | The party that has the specified role. |

### Performance

A claimed, assessed, or required performance level defined either by a scoring system or a numeric measure.

| Property | Type | Description |
| --- | --- | --- |
| metric | [PerformanceMetric](#performancemetric) | The metric (eg material emissions intensity CO2e/Kg or percentage of young workers) that is measured. |
| measure | [Measure](#measure) | The measured performance value |
| score | [Score](#score) | A performance score (eg "AA") drawn from a scoring framework defined by the scheme or criterion. |

### PerformanceMetric

A standardised data point for performance reporting (eg product carbon footprint)

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this reporting metric. |
| name | string | A human readable name for this metric (for example "water usage per Kg of material") |
| description | string | A rich description of this reporting metric. |
| improvementDirection | [ImprovementIndicator](#improvementindicator) | Indicator of whether conforming performance is greater than or less than the defined threshold. |
| aggregationMethod | [AggregationType](#aggregationtype) | Indicates how to aggregate multiple values to report a single performance metric. |
| allowedUnit | [UnitOfMeasure](#unitofmeasure) | The allowed units for value reporting against this metric (eg cubic meters) |

### Period

A period of time, typically a month, quarter or a year, which defines the context boundary for reported facts.

| Property | Type | Description |
| --- | --- | --- |
| startDate | date | The period start date |
| endDate | date | The period end date |
| periodInformation | string | Additional information relevant to this reporting period |

### Product

The ProductInformation class encapsulates detailed information regarding a specific product, including its identification details, manufacturer, and other pertinent details.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this product. Typically represented as a URI identifierScheme/Identifier URI or, if self-issued, as a did. |
| name | string | The product name as known to the market. |
| description | string | Description of the product. |
| idScheme | [IdentifierScheme](#identifierscheme) | The identifier scheme for this product.  Eg a GS1 GTIN or an AU Livestock NLIS, or similar. If self issued then use the party ID of the issuer. |
| relatedParty | [PartyRole](#partyrole) | A list of parties with a defined relationship to this product |
| relatedDocument | [Link](#link) | A list of links to documents providing additional product information. Documents that support a conformity claim (e.g. permits or certificates) SHOULD be referenced as claim evidence rather than here. |
| performanceClaim | [Claim](#claim) | A list of performance claims (eg emissions intensity) for this product. |
| modelNumber | string | Where available, the model number (for manufactured products) or material identification (for bulk materials) |
| batchNumber | string | Identifier of the specific production batch of the product.  Unique within the product class. |
| itemNumber | string | A number or code representing a specific serialised item of the product. Unique within product class. |
| idGranularity | [ProductIDGranularity](#productidgranularity) | The identification granularity for this product (item, batch, model) |
| productImage | [Link](#link) | Reference information (location, type, name) of an image of the product. |
| characteristics | [Characteristics](#characteristics) | A set of industry specific product information. |
| productCategory | [Classification](#classification) | A code representing the product's class, typically using the UN CPC (United Nations Central Product Classification) https://unstats.un.org/unsd/classifications/Econ/cpc |
| producedAtFacility | [Facility](#facility) | The Facility where the product batch was produced / manufactured. |
| productionDate | date | The ISO 8601 date on which the product batch or individual serialised item was manufactured. |
| expiryDate | date | The date at which this product is no longer fit for use. Typically used for a food product use-by date but may also represent the usable life of any product. |
| countryOfProduction | [Country](#country) | The country in which this item was produced / manufactured.using ISO-3166 code and name. |
| dimensions | [Dimension](#dimension) | The physical dimensions of the product. Not every dimension is relevant to every products.  For example bulk materials may have weight and volume but not length, width, or height."weight":\{"value":10, "unit":"KGM"\} |
| materialProvenance | [Material](#material) | A list of materials provenance objects providing details on the origin and mass fraction of materials of the product or batch. |
| packaging | [Package](#package) | The packaging for this product. |
| productLabel | [Image](#image) | An array of labels that may appear on the product such as certification marks or regulatory labels. |

### ProductVerification

The product which is the subject of this conformity assessment

| Property | Type | Description |
| --- | --- | --- |
| product | [Product](#product) | The product, serial or batch that is the subject of this assessment |
| idVerifiedByCAB | boolean | Indicates whether the conformity assessment body has verified the identity product that is the subject of the assessment. |

### RegisteredIdentity

The identity anchor is a mapping between a registry member identity and one or more decentralised identifiers owned by the member. It may also list a set of membership scopes.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | The DID that is controlled by the registered member and is linked to the registeredID through this Identity Anchor credential |
| registeredId | string | The registration number (alphanumeric) of the entity within the register. Unique within the register. |
| idScheme | [IdentifierScheme](#identifierscheme) | The identifier scheme for this registered entity ID. |
| registeredName | string | The registered name of the entity within the identifier scheme.  Examples: product - EV battery 300Ah, Party - Sample Company Pty Ltd,  Facility - Green Acres battery factory |
| registeredDate | date | The date on which this identity was first registered with the registrar. |
| publicInformation | URI | A link to further information about the registered entity on the authoritative registrar site. |
| registrar | [Party](#party) | The registrar party that operates the register. |
| registerType | [RegistryType](#registrytype) | The thematic purpose of the register - organisations, facilities, products, trademarks, etc |
| registrationScope | URI | List of URIs that represent the roles or scopes of membership. For example ["https://abr.business.gov.au/Help/EntityTypeDescription?Id=19"] |

### Regulation

A regulation (eg EU deforestation regulation) that defines the criteria for assessment.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this standard. Typically represented as a URI government/regulation URI |
| name | string | Name of this regulation as defined by the regulator. |
| description | string | Description of this regulation. |
| jurisdictionCountry | [Country](#country) | The legal jurisdiction (country) under which the regulation is issued. |
| administeredBy | [Party](#party) | the issuing body of the regulation. For example Australian Government Department of Climate Change, Energy, the Environment and Water |
| effectiveDate | date | the date at which the regulation came into effect. |

### RegulatoryAlignment

A national regulation or international treaty and an alignment level (exceeds, meets, partial).

| Property | Type | Description |
| --- | --- | --- |
| alignmentLevel | [SchemeAlignmentLevel](#schemealignmentlevel) | A level of alignment with the referenced standard (exceeds, meets, partial,..) |
| regulation | [Regulation](#regulation) | The regulation against which this alignment assessment is made. |

### RenderTemplate2024

A single template format focused render method where the content/media type decision becomes secondary (and is expressed separately).See https://github.com/w3c-ccg/vc-render-method/issues/9

| Property | Type | Description |
| --- | --- | --- |
| name | string | Human facing display name for selection |
| mediaQuery | string | Media query as defined in https://www.w3.org/TR/mediaqueries-4/ |
| template | string | An inline template field for use cases where remote retrieval of a render method is suboptimal |
| url | URI | URL for remotely hosted template |
| mediaType | string | media type of the rendered output (eg text/html) |
| digestMultibase | string | Used for resource integrity and/or validation of the inline `template` |

### Score

A single score within a scoring framework.

| Property | Type | Description |
| --- | --- | --- |
| code | string | The coded value for this score (eg "AAA") |
| definition | string | A description of the meaning of this score. |
| rank | integer | The ranking of this score within the scoring framework - using an integer where "1" is the highest rank. |

### ScoringFramework

A scoring framework used for performance level assessments against a criteria or scheme. For example forced labour performance might score A to D depending on the percentage of workforce subject to recruitment fees.

| Property | Type | Description |
| --- | --- | --- |
| name | string | A name for this scoring framework.  Must be unique within a scheme. |
| description | string | A full text description of the criterion that clearly specifies how compliance is achieved and measured. |
| score | [Score](#score) | A list of scores and ranks associated with this scoring framework. |

### SensorData

A sensor data recording associated with this event

| Property | Type | Description |
| --- | --- | --- |
| geoLocation | [Coordinate](#coordinate) | The geolocation of this sensor data recording event. |
| metric | [PerformanceMetric](#performancemetric) | The type of measurement recorded in this sensor data event. |
| measure | [Measure](#measure) | The value measured by this sensor measurement event. |
| rawData | [Link](#link) | Link to raw data file associated with this sensor reading (eg an image). |
| sensor | [Product](#product) | The sensor device used for this sensor measurement |

### Standard

A standard (eg ISO 14000) that specifies the criteria for conformance.

| Property | Type | Description |
| --- | --- | --- |
| id | URI | Globally unique identifier of this standard. Typically represented as a URI issuer/standard URI |
| name | string | Name for this standard |
| description | string | Description of this standard. |
| issuingParty | [Party](#party) | The party that issued the standard |
| issueDate | date | The date when the standard was issued. |

### StandardAlignment

A voluntary standard and an alignment level (exceeds, meets, partial).

| Property | Type | Description |
| --- | --- | --- |
| standard | [Standard](#standard) | The standard against which this alignment assessment is made. |
| alignmentLevel | [SchemeAlignmentLevel](#schemealignmentlevel) | A level of alignment with the referenced standard (exceeds, meets, partial,..) |

## Code Lists

### AggregationType

Indicates how to aggregate multiple values to report a single performance metric.

| Value | Name | Description |
| --- | --- | --- |
| sum | sum | Values add up (e.g. total GHG emissions across all facilities = sum of each facility's emissions) |
| weighted-average | weighted-average | Values must be averaged weighted by volume/output (e.g. emissions intensity per kg across suppliers) |
| latest | latest | Only the most recent value is meaningful (e.g. a biodiversity assessment score where only the current state matters) |

### AssessmentLevel

Type of authority endorsement of the assessment process

| Value | Name | Description |
| --- | --- | --- |
| authority-benchmark | Authority-derived assurance: Recognition by approved benchmarking organisation | Benchmarking of scheme by an organization approved to UNIDO benchmarking principles and process. UNIDO Global Best Practice Framework for Organisations Performing Benchmarking Activities for Certification-related Conformity Assessment Schemes 2026 |
| authority-mandate | Authority-derived assurance: Recognition by government mandate | Government mandate for conformity assessment activity. Ownership or mandate provided by national government or intergovernmental entity. |
| authority-globalmra | Authority-derived assurance:Global accreditation mutual recognition arrangement | Accreditation of CAB under global mutual recognition arrangement by a body peer-evaluated to ISO/IEC 17011. Scheme evaluation is a prerequisite for accreditation of CABs by bodies that are signatories to the Global Accreditation Cooperation Incorporated Mutual Recognition Arrangement. |
| authority-peer | Authority-derived assurance: Recognition by a governmental peer assessment authority | Peer assessment process managed by government. Ownership or mandate provided by national government or intergovernmental entity. |
| authority-extended-mra | Authority- derived assurance: Peer assessment body recognition for accredited CAB | Independent peer assessment for accredited CAB. This pathway applies to CABs accredited under the Mutual Recognition Arrangement of the Global Accreditation Cooperation Incorporated. Schemes used by CABs may be owned by the peer assessment body but the CAB itself shall not be owned by or otherwise related to the peer assessment body. |
| scheme-self | Scheme-derived assurance: Self-declaration by registered scheme | Scheme owner directly conducting conformity assessment activities. The linked scheme self-declaration can be used to assist in judging credibility of the scheme. |
| scheme-cab | Scheme-derived assurance: Recognition of CAB by registered scheme | Scheme owner recognition of other parties assessing against the scheme standards. The linked scheme self-declaration can be used to assist in judging credibility of the scheme. Users of conformity credentials issued by a CAB recognised under a scheme may refer to the linked scheme self-declaration for details of the CAB-approval process used by the scheme owner |
| no-endorsement | No endorsement. | conformity assessment claiming no external authority or else unspecified |

### AssessmentSubjectType

The type of entity being assessed.

| Value | Name | Description |
| --- | --- | --- |
| product | Product | The conformity profile targets products — assessing characteristics, composition, performance, or safety of manufactured goods. |
| facility | Facility | The conformity profile targets facilities — assessing the operational practices, environmental performance, or working conditions at a specific site. |
| organisation | Organisation | The conformity profile targets organisations — assessing entity-level governance, policies, management systems, or corporate sustainability performance. |

### AssessorLevel

Code that describes the level of independent assurance of the specific assessment

| Value | Name | Description |
| --- | --- | --- |
| self | Self assessed | self-assessment |
| commercial | Commercial assessment | conformity assessment by related body or under commercial contract |
| buyer | Buyer assessment | conformity assessment by potential purchaser |
| membership | Industry body assessment | conformity assessment by industry representative body or membership body |
| unspecified | No independent assessment | conformity assessment by party with unspecified relationship |
| 3rdParty | Independent third party assessment | 3rd party (independent) conformity assessment |
| hybrid | Input from self-declaring parties | 2nd or 3rd party conformity assessment that is dependent on the accuracy of information provided by self-declaring parties |

### AttestationType

A code for the type of the attestation credential

| Value | Name | Description |
| --- | --- | --- |
| certification | certification | A formal third party certification of conformity |
| declaration | declaration | A self assessed declaration of conformity |
| inspection | inspection | An Inspection report |
| testing | testing | A test report |
| verification | verification | A verification report |
| validation | validation | A validation report |
| calibration | calibration | An equipment calibration report |

### CredentialStatus

The status purpose of a credential status entry within a W3C Verifiable Credential, indicating the type of status check that can be performed (e.g. revocation, suspension, refresh, or message).

| Value | Name | Description |
| --- | --- | --- |
| refresh | refresh | Used to signal that an updated verifiable credential is available via the credential's refresh service feature. This status does not invalidate the verifiable credential and is not reversible. |
| revocation | revocation | Used to cancel the validity of a verifiable credential. This status is not reversible. |
| suspension | suspension | Used to temporarily prevent the acceptance of a verifiable credential. This status is reversible. |
| message | message | Used to indicate a ussuer specified flexible status message associated with a verifiable credential. The status message descriptions MUST be defined in credentialSubject.statusMessages. credentialSubject.statusSize MUST be specified when this statusPurpose value is used. |

### CriterionStatus

The status of the conformity profile or criterion

| Value | Name | Description |
| --- | --- | --- |
| proposed | Proposed | The criterion is proposed |
| active | Active | The criterion is in active use. |
| deprecated | Deprecated | The criterion is deprecated. |

### ImprovementIndicator

Indicator of whether conforming performance is greater than or less than the defined threshold.

| Value | Name | Description |
| --- | --- | --- |
| higher | higher | Performance improves with a higher measured value |
| lower | lower | Performance improves with a lower measured value |

### LicenseType

The license type of the published vocabulary

| Value | Name | Description |
| --- | --- | --- |
| proprietary-Code | Proprietary | Commercial software, internal docs. Restrictiveness - Very high |
| proprietary-Document | Documentation licenses | Manuals, standards. Restrictiveness - Medium |
| permissive-OpenSource | Permissive open source | Libraries, frameworks. Restrictiveness - Low |
| copyleft | Copyleft | Platforms, infrastructure. Restrictiveness - Medium–high |
| creative-Commons | Creative Commons | Media, publications. Restrictiveness - Variable |
| source-Available | Source-available | Commercial SaaS vendors. Restrictiveness - Medium–high |
| public | Public domain | Data, examples. Restrictiveness - None |

### PartyRole

A party with a defined relationship to the referencing entity

| Value | Name |
| --- | --- |
| owner | Party that owns the product or asset |
| producer | Party that extracts, grows, or produces raw materials |
| manufacturer | Party that manufactures or assembles the product |
| processor | Party that processes or transforms materials |
| remanufacturer | Party that remanufactures or refurbishes products |
| recycler | Party that recovers materials from products |
| operator | Party operating a facility or process |
| serviceProvider | Party providing maintenance or servicing |
| inspector | Party performing inspection or testing |
| certifier | Party issuing certification or conformity assessment |
| logisticsProvider | Party responsible for logistics operations |
| carrier | Party physically transporting the goods |
| consignor | Party sending the goods |
| consignee | Party receiving the goods |
| importer | Party importing the goods into a jurisdiction |
| exporter | Party exporting the goods from a jurisdiction |
| distributor | Party distributing goods in the supply chain |
| retailer | Party selling goods to end users |
| brandOwner | Party responsible for the brand or product specification |
| regulator | Authority responsible for regulatory oversight |

### ProductIDGranularity

Product identification granularity

| Value | Name |
| --- | --- |
| model | product model level ID |
| batch | product manufactured batch level ID |
| item | serialised item level ID |

### ProductStatus

The lifecycle status of a product, describing its current state from initial production through to eventual disposal or recycling. Used as the value of the disposition property on EventProduct in traceability events.

| Value | Name | Description |
| --- | --- | --- |
| new | New | Product has been newly manufactured or produced and has not yet entered service. Equivalent to GS1 CBV Disp-active. |
| inTransit | In Transit | Product has been shipped and is in transit between facilities. Equivalent to GS1 CBV Disp-in_transit. |
| active | Active | Product is in active service or use by the end customer or a downstream manufacturer. Equivalent to GS1 CBV Disp-retail_sold. |
| repaired | Repaired | Product has been repaired or refurbished to restore functionality and returned to service. Equivalent to GS1 CBV Disp-available (after a repairing step). |
| recalled | Recalled | Product has been withdrawn from the market or service due to a safety, quality, or compliance issue. Equivalent to GS1 CBV Disp-recalled. |
| expired | Expired | Product has passed its use-by, certification, or regulatory expiration date. Equivalent to GS1 CBV Disp-expired. |
| consumed | Consumed | Product has been consumed as an input to a manufacturing process and no longer exists as a separate item. No direct GS1 CBV equivalent. |
| recycled | Recycled | Product has been processed to recover constituent materials for reuse in new products. No direct GS1 CBV equivalent. |
| disposed | Disposed | Product has reached end of life and has been disposed of or destroyed without material recovery. Equivalent to GS1 CBV Disp-disposed and Disp-destroyed. |

### RegistryType

A registry category code.

| Value | Name | Description |
| --- | --- | --- |
| product | Product | A register of products or product classes, such as a national product catalogue or a GS1 GTIN registry. |
| facility | Facility | A register of facilities or sites, such as a mining cadastre, environmental permit register, or industrial facility directory. |
| business | Business | A register of business entities or legal persons, such as a national company register, VAT register, or LEI registry. |
| trademark | Trademark | A register of trademarks, certification marks, or other intellectual property identifiers maintained by a national or international IP office. |
| land | Land | A register of land titles, parcels, or cadastral boundaries, such as a national land registry or territorial cadastre. |
| accreditation | Accreditation | A register of accredited conformity assessment bodies, maintained by a national or regional accreditation authority. |

### SchemeAlignmentLevel

Alignment level of a scheme profile or criterion against a reference standard or regulation

| Value | Name | Description |
| --- | --- | --- |
| meets | Meets | The scheme profile or criterion fully satisfies the requirements of the referenced standard or regulation. |
| exceeds | Exceeds | The scheme profile or criterion goes beyond the requirements of the referenced standard or regulation, imposing stricter thresholds or broader scope. |
| partial | Partially meets | The scheme profile or criterion addresses some but not all requirements of the referenced standard or regulation. |

### SchemeEndorsementLevel

The level of endorsement or recognition that a conformity scheme has received from authoritative bodies, indicating the degree of independent assurance over the scheme's credibility and rigour.

| Value | Name | Description |
| --- | --- | --- |
| endorsed_self | Self-declaration by scheme owner | Scheme owner self-declaration using the UNTP scheme declaration template |
| endorsed_mandate | Government owned or mandated scheme | Ownership of scheme or mandate for adoption of scheme by national government or intergovernmental entity. |
| endorsed_accreditation | Accreditation authority endorsement of scheme suitability | Scheme evaluated for suitability by the Global Accreditation Cooperation Incorporated, or by an accreditation body member of the Global Mutual Recognition Arrangement for such scope, or by a Regional Accreditation Cooperation member. |
| endorsed_benchmarked | Scheme recognition by a benchmarking organisation approved to UNIDO principles and process | Benchmarking of scheme by an organization approved to UNIDO benchmarking principles and process. UNIDO Global Best Practice Framework for Organisations Performing Benchmarking Activities for Certification-related Conformity Assessment Schemes 2026 |

### CountryCode

ISO 2 letter country code

Values are drawn from an external vocabulary: [ISO 3166-1 alpha-2](https://www.iso.org/iso-3166-country-codes.html)

### MimeType

IANA multipart media encoding type

Values are drawn from an external vocabulary: [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml)

### UnitOfMeasure

UNECE Recommendation 20 Unit of Measure codelist

Values are drawn from an external vocabulary: [UNECE Recommendation 20](https://unece.org/trade/uncefact/cl-recommendations)

## Property Index

Alphabetical listing of all properties defined in the UNTP core vocabulary.

| Property | Domain(s) | Range | Description |
| --- | --- | --- | --- |
| activityType | [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent) | [Classification](#classification) | The business activity that this event represents (eg shipping, repair, etc) using a standard classification scheme - eg https://ref.gs1.org/cbv/BizStep. This may be replaced with industry specific vocabularies (ginning, spinning, weaving, dyeing, etc in textiles) |
| address | [Facility](#facility) | [Address](#address) | The Postal address of the location. |
| addressCountry | [Address](#address) | [Country](#country) | The address country as an ISO-3166 two letter country code and name. |
| administeredBy | [Regulation](#regulation) | [Party](#party) | the issuing body of the regulation. For example Australian Government Department of Climate Change, Energy, the Environment and Water |
| aggregationMethod | [PerformanceMetric](#performancemetric) | [AggregationType](#aggregationtype) | Indicates how to aggregate multiple values to report a single performance metric. |
| alignmentLevel | [StandardAlignment](#standardalignment), [RegulatoryAlignment](#regulatoryalignment) | [SchemeAlignmentLevel](#schemealignmentlevel) | A level of alignment with the referenced standard (exceeds, meets, partial,..) |
| allowedUnit | [PerformanceMetric](#performancemetric) | [UnitOfMeasure](#unitofmeasure) | The allowed units for value reporting against this metric (eg cubic meters) |
| applicablePeriod | [MaterialUsage](#materialusage), [Claim](#claim) | [Period](#period) | The period over which this material consumption is reported |
| assessedFacility | [ConformityAssessment](#conformityassessment) | [FacilityVerification](#facilityverification) | The facility which is the subject of this assessment. |
| assessedOrganisation | [ConformityAssessment](#conformityassessment) | [Party](#party) | An organisation that is the subject of this assessment. |
| assessedPerformance | [ConformityAssessment](#conformityassessment) | [Performance](#performance) | The assessed performance against criteria. |
| assessedProduct | [ConformityAssessment](#conformityassessment) | [ProductVerification](#productverification) | The product which is the subject of this assessment. |
| assessmentCriteria | [ConformityAssessment](#conformityassessment) | [Criterion](#criterion) | The specification against which the assessment is made. |
| assessmentDate | [ConformityAssessment](#conformityassessment) | date | The date on which this assessment was made. |
| assessmentLevel | [ConformityAttestation](#conformityattestation) | [AssessmentLevel](#assessmentlevel) | Assurance pertaining to assessment (any authority or support for the assessment process) |
| assessorLevel | [ConformityAttestation](#conformityattestation) | [AssessorLevel](#assessorlevel) | Assurance code pertaining to assessor (relation to the object under assessment) |
| attestationType | [ConformityAttestation](#conformityattestation) | [AttestationType](#attestationtype) | The type of criterion (optional or mandatory). |
| auditableEvidence | [ConformityAttestation](#conformityattestation) | [Link](#link) | Auditable evidence supporting this assessment such as raw measurements, supporting documents. This is usually private data and would normally be encrypted. |
| authorisation | [ConformityAttestation](#conformityattestation) | [Endorsement](#endorsement) | The authority under which a conformity claim is issued.  For example a national accreditation authority may authorise a test lab to issue test certificates about a product against a standard. |
| batchNumber | [Product](#product) | string | Identifier of the specific production batch of the product.  Unique within the product class. |
| characteristics | [Product](#product) | [Characteristics](#characteristics) | A set of industry specific product information. |
| claimDate | [Claim](#claim) | date | That date on which the claimed performance is applicable. |
| claimedPerformance | [Claim](#claim) | [Performance](#performance) | The claimed performance level |
| code | [Classification](#classification), [Score](#score) | string | classification code within the scheme |
| conformance | [ConformityAssessment](#conformityassessment) | boolean | An indicator (true / false) whether the outcome of this assessment is conformant to the requirements defined by the standard or criterion. |
| conformityAssessment | [ConformityAttestation](#conformityattestation) | [ConformityAssessment](#conformityassessment) | A list of individual assessment made under this attestation. |
| conformityCertificate | [ConformityAttestation](#conformityattestation) | [Link](#link) | A reference to the human / printable version of this conformity attestation - typically represented as a PDF document. The document may have more details than are represented in the digital attestation. |
| conformityTopic | [Claim](#claim), [Criterion](#criterion), [ConformityAssessment](#conformityassessment) | [ConformityTopic](#conformitytopic) | The conformity topic category for this assessment |
| conformsTo | [ConformityScheme](#conformityscheme) | [Link](#link) | The name and URI of the vocabulary standard (eg UNTP CVC) that the machine readable version of this sceme conforms to. |
| consignmentId | [MoveEvent](#moveevent) | URI | The consignment ID related to this movement of products. Ideally this is a resolvable URL but if not available then use a URN notation such as urn:carrier:waybillNumber. |
| countryCode | [Country](#country) | [CountryCode](#countrycode) | ISO 3166 country code |
| countryName | [Country](#country) | string | Country Name as defined in ISO 3166 |
| countryOfOperation | [Facility](#facility) | [Country](#country) | The country in which this facility is operating.using ISO-3166 code and name. |
| countryOfProduction | [Product](#product) | [Country](#country) | The country in which this item was produced / manufactured.using ISO-3166 code and name. |
| credentialSubjectType | [DigitalProductPassport](#digitalproductpassport), [DigitalFacilityRecord](#digitalfacilityrecord), [DigitalConformityCredential](#digitalconformitycredential), [DigitalTraceabilityEvent](#digitaltraceabilityevent), [DigitalIdentityAnchor](#digitalidentityanchor) | Class | The expected type of the credentialSubject for this credential class. Used to connect UNTP credential types to the UNTP domain classes that populate the W3C VCDM credentialSubject property, without redefining the W3C property itself. |
| criterion | [ConformityProfile](#conformityprofile) | [Criterion](#criterion) | A list of criterion that are included in this conformity profile. |
| criterionScoringFramework | [ConformityProfile](#conformityprofile) | [ScoringFramework](#scoringframework) | A list of named scoring frameworks that are applied by criterion within this profile. |
| definition | [Classification](#classification), [ConformityTopic](#conformitytopic), [Score](#score) | string | A rich definition of this classification code. |
| description | [Party](#party), [Entity](#entity), [Facility](#facility), [Image](#image), [Claim](#claim), [Criterion](#criterion), [Regulation](#regulation), [Standard](#standard), [ConformityAttestation](#conformityattestation), [ConformityScheme](#conformityscheme), [ScoringFramework](#scoringframework), [ConformityProfile](#conformityprofile), [ConformityAssessment](#conformityassessment), [Product](#product), [Package](#package), [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent), [PerformanceMetric](#performancemetric) | string | Description of the party including function and other names. |
| digestMultibase | [RenderTemplate2024](#rendertemplate2024), [Link](#link) | string | Used for resource integrity and/or validation of the inline `template` |
| dimensions | [Product](#product), [Package](#package) | [Dimension](#dimension) | The physical dimensions of the product. Not every dimension is relevant to every products.  For example bulk materials may have weight and volume but not length, width, or height."weight":\{"value":10, "unit":"KGM"\} |
| disposition | [EventProduct](#eventproduct) | [ProductStatus](#productstatus) | The status of the product after the event has happened. |
| documentation | [Criterion](#criterion), [ConformityScheme](#conformityscheme), [ConformityProfile](#conformityprofile) | URI | A web page carrying detailed information about this criterion. |
| effectiveDate | [Regulation](#regulation) | date | the date at which the regulation came into effect. |
| endDate | [Period](#period) | date | The period end date |
| endorsement | [ConformityScheme](#conformityscheme) | [Endorsement](#endorsement) | The endorsement provided to the scheme by an external authority such as a regulator, an accreditaiton authority, or a benchmarking scheme. |
| endorsementEvidence | [Endorsement](#endorsement) | [Link](#link) | The evidence that supports the authority under which the attestation is issued - for an example an accreditation certificate. |
| endorsementLevel | [ConformityScheme](#conformityscheme) | [SchemeEndorsementLevel](#schemeendorsementlevel) | The scheme assurance type. |
| establishedDate | [ConformityScheme](#conformityscheme) | date | The date when this scheme was first established. |
| eventDate | [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent) | dateTime | The date and time at which this lifecycle event occurs. use 00:00 for time if only a date is required. |
| evidence | [Claim](#claim), [ConformityAssessment](#conformityassessment) | [Link](#link) | A URI pointing to the evidence supporting the claim. SHOULD be a URL to a UNTP Digital Conformity Credential (DCC) |
| expiryDate | [Product](#product) | date | The date at which this product is no longer fit for use. Typically used for a food product use-by date but may also represent the usable life of any product. |
| extendsModel | [VerifiableCredential](#verifiablecredential), [Address](#address) | Class | Indicates that this UNTP class reuses and extends a class defined in an external vocabulary (e.g. W3C VCDM, schema.org). The external class defines the envelope or base properties; UNTP defines only the extensions. This annotation enables human-readable renderings to display or link to the inherited properties without redefining them. |
| facility | [FacilityVerification](#facilityverification) | [Facility](#facility) | The facility which is the subject of this assessment |
| facilityAlsoKnownAs | [Facility](#facility) | [Facility](#facility) | An optional list of other registered identifiers for this facility - eg GLNs or other schemes. |
| fromFacility | [MoveEvent](#moveevent) | [Facility](#facility) | The source facility for this movement / shipment of products |
| geoBoundary | [Location](#location) | [Coordinate](#coordinate) | The list of ordered coordinates that define a closed area polygon as a location boundary. The first and last coordinates in the array must match - thereby defining a closed boundary. |
| geographicScope | [ConformityScheme](#conformityscheme) | [Classification](#classification) | The geographic scope of this scheme as a list of ISO-3166 countries, regions, or code=001, name=Worldwide to indicate global coverage. |
| geoLocation | [Location](#location), [SensorData](#sensordata) | [Coordinate](#coordinate) | The latitude and longitude coordinates that best represent the specified location. |
| hazardous | [Material](#material) | boolean | Indicates whether this material is hazardous. If true then the materialSafetyInformation property must be present |
| height | [Dimension](#dimension) | [Measure](#measure) | The height of the product or packaging. eg \{"value":220, "unit":"MMT"\} |
| id | [CredentialIssuer](#credentialissuer), [Party](#party), [Entity](#entity), [IdentifierScheme](#identifierscheme), [BitstringStatusListEntry](#bitstringstatuslistentry), [Facility](#facility), [Claim](#claim), [Criterion](#criterion), [ConformityTopic](#conformitytopic), [PerformanceMetric](#performancemetric), [Regulation](#regulation), [Standard](#standard), [ConformityAttestation](#conformityattestation), [ConformityScheme](#conformityscheme), [ConformityProfile](#conformityprofile), [ConformityAssessment](#conformityassessment), [Product](#product), [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent), [RegisteredIdentity](#registeredidentity) | URI | The W3C DID of the issuer - should be a did:web or did:webvh |
| idGranularity | [Product](#product) | [ProductIDGranularity](#productidgranularity) | The identification granularity for this product (item, batch, model) |
| idScheme | [Party](#party), [Facility](#facility), [Product](#product), [RegisteredIdentity](#registeredidentity) | [IdentifierScheme](#identifierscheme) | The identifier scheme of the party.  Typically a national business register or a global scheme such as GLEIF. |
| idVerifiedByCAB | [ProductVerification](#productverification), [FacilityVerification](#facilityverification) | boolean | Indicates whether the conformity assessment body has verified the identity product that is the subject of the assessment. |
| imageData | [Image](#image) | string | The image data encoded as a base64 string. |
| improvementDirection | [PerformanceMetric](#performancemetric) | [ImprovementIndicator](#improvementindicator) | Indicator of whether conforming performance is greater than or less than the defined threshold. |
| includedProfile | [ConformityScheme](#conformityscheme) | [ConformityProfile](#conformityprofile) | The list of versioned conformity profiles included in this scheme |
| industryCategory | [Party](#party) | [Classification](#classification) | The industry categories for this organisation.  Recommend use of UNCPC as the category scheme. for example - unstats.un.org/isic/1030 |
| industryScope | [ConformityScheme](#conformityscheme) | [Classification](#classification) | A list of UN ISIC code & name indicating the industry scope for this scheme. |
| inputProduct | [MakeEvent](#makeevent) | [EventProduct](#eventproduct) | An array of input products and quantities for this production or manufacturing process |
| issueDate | [Standard](#standard) | date | The date when the standard was issued. |
| issuedToParty | [ConformityAttestation](#conformityattestation) | [Party](#party) | The party to whom the conformity attestation was issued. |
| issuerAlsoKnownAs | [CredentialIssuer](#credentialissuer) | [Party](#party) | An optional list of other registered identifiers for this credential issuer |
| issuingAuthority | [Endorsement](#endorsement) | [Party](#party) | The competent authority that issued the accreditation. |
| issuingParty | [Standard](#standard) | [Party](#party) | The party that issued the standard |
| itemNumber | [Product](#product) | string | A number or code representing a specific serialised item of the product. Unique within product class. |
| jurisdictionCountry | [Regulation](#regulation) | [Country](#country) | The legal jurisdiction (country) under which the regulation is issued. |
| latitude | [Coordinate](#coordinate) | number | latitude: Angular distance north or south of the equator, expressed in decimal degrees.Valid range: −90.0 to +90.0. |
| length | [Dimension](#dimension) | [Measure](#measure) | The length of the product or packaging eg \{"value":840, "unit":"MMT"\} |
| licenseType | [ConformityScheme](#conformityscheme) | [LicenseType](#licensetype) | Descriptive name and URL link to the license conditions associated with this scheme. |
| linkName | [Link](#link) | string | Display name for this link. |
| linkType | [Link](#link) | string | The type of the target resource - drawn from a controlled vocabulary |
| linkURL | [Link](#link) | URI | The URL of the target resource. |
| locationInformation | [Facility](#facility) | [Location](#location) | Geo-location information for this facility as a resolvable geographic area (a Plus Code), and/or a geo-located point (latitude / longitude), and/or a defined boundary (GeoJSON Polygon). |
| longitude | [Coordinate](#coordinate) | number | longitude: Angular distance east or west of the Prime Meridian, expressed in decimal degrees.Valid range: −180.0 to +180.0. |
| lowerTolerance | [Measure](#measure) | number | The lower tolerance associated with this measure expressed in the same units as the measure.  For example value=10, lowerTolerance=0.1, unit=KGM would mean that this measure is 10kg - 0.1kg |
| madeAtFacility | [MakeEvent](#makeevent) | [Facility](#facility) | The facility at which this production / manufacturing event happens. |
| mass | [Material](#material) | [Measure](#measure) | The mass of the material component. |
| massFraction | [Material](#material) | number | The mass fraction as a decimal of the product (or facility reporting period)  represented by this material. |
| materialConsumed | [MaterialUsage](#materialusage) | [Material](#material) | An list of materials consumed during the usage period. |
| materialProvenance | [Product](#product) | [Material](#material) | A list of materials provenance objects providing details on the origin and mass fraction of materials of the product or batch. |
| materialSafetyInformation | [Material](#material) | [Link](#link) | Reference to further information about safe handling of this hazardous material (for example a link to a material safety data sheet) |
| materialType | [Material](#material) | [Classification](#classification) | The type of this material - as a value drawn from a controlled vocabulary eg from UN Framework Classification for Resources (UNFC). |
| materialUsage | [Facility](#facility) | [MaterialUsage](#materialusage) | The type and provenance of materials consumed by the facility during the reporting period. |
| materialUsed | [Package](#package) | [Material](#material) | materials used for the packaging. |
| measure | [Performance](#performance), [SensorData](#sensordata) | [Measure](#measure) | The measured performance value |
| mediaQuery | [RenderTemplate2024](#rendertemplate2024) | string | Media query as defined in https://www.w3.org/TR/mediaqueries-4/ |
| mediaType | [RenderTemplate2024](#rendertemplate2024), [Link](#link), [Image](#image) | string | media type of the rendered output (eg text/html) |
| metric | [Performance](#performance), [SensorData](#sensordata) | [PerformanceMetric](#performancemetric) | The metric (eg material emissions intensity CO2e/Kg or percentage of young workers) that is measured. |
| modelNumber | [Product](#product) | string | Where available, the model number (for manufactured products) or material identification (for bulk materials) |
| modifiedAtFacility | [ModifyEvent](#modifyevent) | [Facility](#facility) | The facility at which this intervention event happens. |
| modifiedProduct | [ModifyEvent](#modifyevent) | [EventProduct](#eventproduct) | An array of products and quantities for this intervention (repair, inspection, etc) |
| movedProduct | [MoveEvent](#moveevent) | [EventProduct](#eventproduct) | An array of products and quantities for this movement / shipment process |
| name | [CredentialIssuer](#credentialissuer), [Party](#party), [Entity](#entity), [IdentifierScheme](#identifierscheme), [Classification](#classification), [RenderTemplate2024](#rendertemplate2024), [Facility](#facility), [Material](#material), [Image](#image), [Claim](#claim), [Criterion](#criterion), [ConformityTopic](#conformitytopic), [PerformanceMetric](#performancemetric), [Regulation](#regulation), [Standard](#standard), [ConformityAttestation](#conformityattestation), [Endorsement](#endorsement), [ConformityScheme](#conformityscheme), [ScoringFramework](#scoringframework), [ConformityProfile](#conformityprofile), [ConformityAssessment](#conformityassessment), [Product](#product), [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent) | string | The name of the issuer person or organisation |
| organisationWebsite | [Party](#party) | URI | Website for this organisation |
| originCountry | [Material](#material) | [Country](#country) | A ISO 3166-1 code representing the country of origin of the component or ingredient. |
| outputProduct | [MakeEvent](#makeevent) | [EventProduct](#eventproduct) | An array of output products and quantities for this produciton or manufacturing process |
| owner | [ConformityScheme](#conformityscheme) | [Party](#party) | The party that is the owner / maintainer of this conformity scheme. |
| packageLabel | [Package](#package) | [Image](#image) | An array of package labels that may appear on the packaging together with their meaning. Use for small images that represent certification marks or regulatory requirements. Large images should be linked as evidence to claims. |
| packaging | [Product](#product) | [Package](#package) | The packaging for this product. |
| party | [PartyRole](#partyrole) | [Party](#party) | The party that has the specified role. |
| partyAddress | [Party](#party) | [Address](#address) | The address of the party |
| partyAlsoKnownAs | [Party](#party) | [Party](#party) | An optional list of other registered identifiers for this organisation. For example DUNS, GLN, LEI, etc |
| performanceClaim | [Facility](#facility), [Product](#product), [Package](#package) | [Claim](#claim) | A list of performance claims (eg deforestation status) for this facility. |
| periodInformation | [Period](#period) | string | Additional information relevant to this reporting period |
| plusCode | [Location](#location) | URI | An open location code (https://maps.google.com/pluscodes/) representing this geographic location or region. Open location codes can represent any sized area from a point to a large region and are easily resolved to a visual map location. |
| processCategory | [Facility](#facility) | [Classification](#classification) | The industrial or production processes performed by this facility. Example unstats.un.org/isic/1030. |
| producedAtFacility | [Product](#product) | [Facility](#facility) | The Facility where the product batch was produced / manufactured. |
| product | [ProductVerification](#productverification), [EventProduct](#eventproduct) | [Product](#product) | The product, serial or batch that is the subject of this assessment |
| productCategory | [Product](#product) | [Classification](#classification) | A code representing the product's class, typically using the UN CPC (United Nations Central Product Classification) https://unstats.un.org/unsd/classifications/Econ/cpc |
| productImage | [Product](#product) | [Link](#link) | Reference information (location, type, name) of an image of the product. |
| productionDate | [Product](#product) | date | The ISO 8601 date on which the product batch or individual serialised item was manufactured. |
| productLabel | [Product](#product) | [Image](#image) | An array of labels that may appear on the product such as certification marks or regulatory labels. |
| profileScore | [ConformityAttestation](#conformityattestation) | [Score](#score) | The overall performance against a scheme level performance measurement framework for the referenced profile or scheme. |
| publicInformation | [RegisteredIdentity](#registeredidentity) | URI | A link to further information about the registered entity on the authoritative registrar site. |
| quantity | [EventProduct](#eventproduct) | [Measure](#measure) | The quantity of product subject to this lifecycle event.  Not needed for serialised items. |
| rank | [Score](#score) | integer | The ranking of this score within the scoring framework - using an integer where "1" is the highest rank. |
| rawData | [SensorData](#sensordata) | [Link](#link) | Link to raw data file associated with this sensor reading (eg an image). |
| recycledMassFraction | [Material](#material) | number | Mass fraction of this material that is recycled (eg 50% recycled Lithium) |
| referenceCriteria | [Claim](#claim) | [Criterion](#criterion) | The criterion against which the claim is made. |
| referenceProfile | [ConformityAttestation](#conformityattestation) | [ConformityProfile](#conformityprofile) | The specific versioned conformity profile (comprising a set of versioned criteria) against which this conformity attestation is made. |
| referenceRegulation | [Claim](#claim), [ConformityAssessment](#conformityassessment) | [Regulation](#regulation) | List of references to regulation to which conformity is claimed claimed for this product |
| referenceScheme | [ConformityAttestation](#conformityattestation) | [ConformityScheme](#conformityscheme) | The conformity scheme under which this attestation is made. |
| referenceStandard | [Claim](#claim), [ConformityAssessment](#conformityassessment) | [Standard](#standard) | List of references to standards to which conformity is claimed claimed for this product |
| registeredDate | [RegisteredIdentity](#registeredidentity) | date | The date on which this identity was first registered with the registrar. |
| registeredId | [Party](#party), [Facility](#facility), [RegisteredIdentity](#registeredidentity) | string | The registration number (alphanumeric) of the Party within the register. Unique within the register. |
| registeredName | [RegisteredIdentity](#registeredidentity) | string | The registered name of the entity within the identifier scheme.  Examples: product - EV battery 300Ah, Party - Sample Company Pty Ltd,  Facility - Green Acres battery factory |
| registerType | [RegisteredIdentity](#registeredidentity) | [RegistryType](#registrytype) | The thematic purpose of the register - organisations, facilities, products, trademarks, etc |
| registrar | [RegisteredIdentity](#registeredidentity) | [Party](#party) | The registrar party that operates the register. |
| registrationCountry | [Party](#party) | [Country](#country) | the country in which this organisation is registered - using ISO-3166 code and name. |
| registrationScope | [RegisteredIdentity](#registeredidentity) | URI | List of URIs that represent the roles or scopes of membership. For example ["https://abr.business.gov.au/Help/EntityTypeDescription?Id=19"] |
| regulation | [RegulatoryAlignment](#regulatoryalignment) | [Regulation](#regulation) | The regulation against which this alignment assessment is made. |
| regulatoryAlignment | [ConformityProfile](#conformityprofile) | [RegulatoryAlignment](#regulatoryalignment) | A list of regulations or legally binding conventions referenced by this conformity profile and against which some level of compliance can be inferred for subjects that pass an assessment. |
| relatedDocument | [Facility](#facility), [Product](#product), [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent) | [Link](#link) | A list of links to documents providing additional facility information. Documents that support a conformity claim (e.g. permits or certificates) SHOULD be referenced as claim evidence rather than here. |
| relatedParty | [Facility](#facility), [Product](#product), [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent) | [PartyRole](#partyrole) | A list of parties with a specified role relationship to this facility |
| requiredPerformance | [Criterion](#criterion) | [Performance](#performance) | The required performance level as one or more score and/or a metric that represents compliance defined by the criteria |
| role | [PartyRole](#partyrole) | [PartyRole](#partyrole) | The role played by the party in this relationship |
| scheme | [ConformityProfile](#conformityprofile) | [ConformityScheme](#conformityscheme) | The conformity scheme under which this versioned profile is maintained. |
| schemeId | [Classification](#classification) | URI | Classification scheme ID |
| schemeName | [Classification](#classification) | string | The name of the classification scheme |
| schemeScoringFramework | [ConformityScheme](#conformityscheme) | [ScoringFramework](#scoringframework) | The scheme level overall scoring framework that represents the achievement levels (AA, A, B etc) that maybe be awarded to the subject of an independent assessment under the scheme. |
| scope | [ConformityProfile](#conformityprofile) | [Classification](#classification) | A set of classification codes that may be used to categorize the applicability of this criteria - for example industry sector, jurisdiction or commodity type - based on a formal vocabulary. |
| score | [Performance](#performance), [ScoringFramework](#scoringframework) | [Score](#score) | A performance score (eg "AA") drawn from a scoring framework defined by the scheme or criterion. |
| sensor | [SensorData](#sensordata) | [Product](#product) | The sensor device used for this sensor measurement |
| sensorData | [LifecycleEvent](#lifecycleevent), [MakeEvent](#makeevent), [MoveEvent](#moveevent), [ModifyEvent](#modifyevent) | [SensorData](#sensordata) | A sensor data set associated with this lifecycle event. |
| specifiedCondition | [ConformityAssessment](#conformityassessment) | string | A list of specific conditions that constrain this conformity assessment. For example a specific jurisdiction, material type, or test method. |
| standard | [StandardAlignment](#standardalignment) | [Standard](#standard) | The standard against which this alignment assessment is made. |
| standardAlignment | [ConformityProfile](#conformityprofile) | [StandardAlignment](#standardalignment) | A list of voluntary standards referenced by this conformity profile and against which some level of compliance can be inferred for subjects that pass an assessment. |
| startDate | [Period](#period) | date | The period start date |
| status | [Criterion](#criterion), [ConformityProfile](#conformityprofile) | [CriterionStatus](#criterionstatus) | The lifecycle status of this criterion. |
| statusListCredential | [BitstringStatusListEntry](#bitstringstatuslistentry) | URI | The statusListCredential property MUST be a URL to a verifiable credential. When the URL is dereferenced, the resulting verifiable credential MUST have type property that includes the BitstringStatusListCredential value. |
| statusListIndex | [BitstringStatusListEntry](#bitstringstatuslistentry) | integer | The statusListIndex property MUST be an arbitrary size integer greater than or equal to 0, expressed as a string in base 10. The value identifies the position of the status of the verifiable credential. |
| statusPurpose | [BitstringStatusListEntry](#bitstringstatuslistentry) | [CredentialStatus](#credentialstatus) | Status purpose drawn from a standard list but extensible as per w3c bitstring status list specification. |
| subjectType | [ConformityProfile](#conformityprofile) | [AssessmentSubjectType](#assessmentsubjecttype) | The type of the subject of assessments made under this conformity profile (eg product, facility, organisation) |
| symbol | [Material](#material) | [Image](#image) | Based 64 encoded binary used to represent a visual symbol for a given material. |
| tag | [Criterion](#criterion) | string | A set of tags that can be used by the scheme owner to be able to filter or group criterion in a large vocabulary for specific use cases. |
| template | [RenderTemplate2024](#rendertemplate2024) | string | An inline template field for use cases where remote retrieval of a render method is suboptimal |
| toFacility | [MoveEvent](#moveevent) | [Facility](#facility) | The destination facility for this movement / shipment of products |
| trustmark | [ConformityAttestation](#conformityattestation), [Endorsement](#endorsement), [ConformityScheme](#conformityscheme) | [Image](#image) | A trust mark as a small binary image encoded as base64 with a description.  Maye be displayed on the conformity credential rendering. |
| type | [BitstringStatusListEntry](#bitstringstatuslistentry) | string | The type of status list - must be set to "The type property MUST be BitstringStatusListEntry." |
| unit | [Measure](#measure) | [UnitOfMeasure](#unitofmeasure) | Unit of measure drawn from the UNECE Rec20 measure code list. |
| upperTolerance | [Measure](#measure) | number | The upper tolerance associated with this measure expressed in the same units as the measure.  For example value=10, upperTolerance=0.1, unit=KGM would mean that this measure is 10kg + 0.1kg |
| url | [RenderTemplate2024](#rendertemplate2024) | URI | URL for remotely hosted template |
| validFrom | [ConformityProfile](#conformityprofile) | date | The data from which this scheme version is valid. |
| value | [Measure](#measure) | number | The numeric value of the measure |
| version | [Criterion](#criterion), [ConformityProfile](#conformityprofile) | string | The major.minor version of the criterion. Minor versions represent changes that would not invalidate an assessment made under a previous version. |
| volume | [Dimension](#dimension) | [Measure](#measure) | The displacement volume of the product. eg \{"value":7.5, "unit":"LTR"\} |
| weight | [Dimension](#dimension) | [Measure](#measure) | the weight of the product. EG \{"value":10, "unit":"KGM"\} |
| width | [Dimension](#dimension) | [Measure](#measure) | The width of the product or packaging. eg \{"value":150, "unit":"MMT"\} |
<!-- GENERATED:END ontology -->

---

## Decentralised Access Control

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview

There is a balance between the demands of transparency (more supply chain visibility means it's harder to hide green-washing) and confidentiality (share too much data and you risk exposing commercial secrets). A key UNTP principle is that every supply chain actor should be able to choose their own balance between transparency and confidentiality. To achieve this, UNTP defines data confidentiality patterns with different degrees of data protection so that they can be appropriately combined to meet the confidentiality goals of each party. 

The ability to enforce access control to read and write non-public data is a critical capability for any traceability and transparency framework. But when the non-public data is distributed across thousands of different systems and needs to be accessed by authorised parties previously unknown to the holder of the data, traditional access control systems will not work. A decentralised data architecture also needs a decentralised access control mechanism. 

## Conceptual Model

The conceptual model for decentralised access control is relatively simple. All non-public credentials are encrypted with a unique key for each credential. **Read access** to encrypted data then boils down to the mechanism by which authorised parties acquire decryption keys from a data holder that may not know the requestor. **Write access** (e.g., adding links to an Identity Resolver, or submitting lifecycle/update events) is performed via authenticated update endpoints, typically advertised as link targets. There are only two broad ways to prove rights to non-public data.

1. **You already have the key:** The key is passed by the data holder to the data requestor by a separate channel. For example, to empower access to non-public data by the legitimate purchaser of the goods, the key could be located inside the packaging of the product. 
2. **You have a right to the key:** The key is made available to any data requestor that can prove their authorised role to the data holder via an authentication mechanism such as [DID Authentication](https://w3c-ccg.github.io/vp-request-spec/#did-authentication). 

Each uniquely identified item will have a unique encryption key. Therefore the keys provided by either of the above methods is usable only to decrypt the data about a single item. Similarly, for confidential data about products or facilities each will have its own unique encryption key. 

Shared secrets and DID Authentication can be used in conjunction - for example a data holder may allow anonymous users to read non-public data with just a secret but may require both the secret (to prove item ownership) and DID Authentication (to confirm identity or role of the data requestor) to update item data.

![DAC Concept Model](../assets/images/dac-DecentralisedAccessControl.png)

For read access, the decryption of previously issued and encrypted verifiable credentials is preferred over any dynamic service because 

* The same encrypted UNTP credential is used for both the shared secret and DID authentication access models.
* The access control is easily delegated to Identity Provider services and can continue to work even after the original issuer is no longer in business.

## Requirements

* **data holder** is the party that created and maintains the information about a product or facility. Typically the product manufacturer or brand. The holder maintains both public and non-public data about the product or facility.
* **data requestor** is the party seeking access to product data held and maintained by the data holder. 

| ID    | Name                            | Requirement                                                                                                                                                                                                                                                                                          | Solution Mapping                                                                                                                                           |
| ----- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DAC-1 | Anonymous access                | As a data requestor that requires access to public product information, I should be able to access the information without any registration or identification - so that my privacy remains protected.                                                                                                | [Anonymous public access](#anonymous-public-access)                                                                                                        |
| DAC-2 | Access by legitimate owner      | As the legitimate owner or user of a specific serialised item, I should be able to access non-public information such as usage and maintenance history about my item and also be able to update post-sale life-cycle events without any need to register or identify myself to the data holder.      | [Anonymous access with secret](#shared-secrets)                                                                                                            |
| DAC-3 | Access with verifiable role     | As an authorised actor such as an accredited recycling plant or a government authority, I should be able to access and update non-public product information according to my authorised role even if I am otherwise unknown to the data holder.                                                      | [Decentralised authentication - role](#decentralised-authentication) `registrationScopeList` property                                                      |
| DAC-4 | Access with verifiable identity | As a known and trusted data requestor party I should be able to prove my identity to the data holder and be granted access according to my permissions.                                                                                                                                              | [Decentralised authentication - ID](#decentralised-authentication) `registeredId` property or any [federated identity](#federated-authentication) protocol |
| DAC-5 | Confidential supply             | As a buyer who received credentials from my suppliers that provide confidence in the sustainability or quality of my upstream supply chain, I would like to pass on the sustainability or quality confidence to my customers without revealing the identity of my suppliers.                         | [N-tier supplier visibility](#n-tier-supplier-visibility)                                                                                                  |
| DAC-6 | Discoverability                 | As any data requestor that queries available data about a product or facility from an identity resolver service, I would like to understand not only what public data is available but also what confidential data is available and what evidence I need to provide to access the confidential data. | [Discoverability of encrypted content](#confidential-data-discovery)                                                                                       |
| DAC-7 | Durability                      | As a data requestor seeking information about a product or facility, I want to access the necessary data according to my role even if the original manufacturer is no longer in business and whether or not the data is open or confidential.                                                        | [Durable storage options](#durable-storage)                                                                                                                |
| DAC-8 | Limit impact                    | The confidential data access scope associated with a specific secret key should be limited to one product or item so that the consequence of un-authorised access to confidential data is minimised                                                                                                  | [Encryption granularity](#encrypted-content)                                                                                                               |
| DAC-9 | Small footprint                 | Where space is tight (eg under a wine bottle cap) then a small format secret key option is available.                                                                                                                                                                                                | [Secret key carrier](#small-footprint-codes)                                                                                                               |

## Decentralised Access Control

UNTP defines six access control patterns that can be combined to balance transparency and confidentiality for both read and write access:

1. **Anonymous Public Access** - No encryption, publicly discoverable via Identity Resolver
2. **Unguessable Identifiers** - Security through high-entropy random IDs (128-bit minimum)
3. **Encrypted Content** - Encryption with unique keys per entity
4. **Shared Secrets** - Decryption keys embedded in data carriers with products
5. **Federated Authentication** - OAuth/OIDC for known parties with pre-established trust
6. **Decentralised Authentication** - DID Auth for verifiable roles/identities without prior registration

These patterns can be used independently or in combination depending on requirements. For example, Pattern 4 (shared secrets) can be combined with Pattern 6 (decentralised authentication) to require both proof of item ownership and verified role credentials for access.

The following paragraphs provide guidance on how to secure data and grant access for various scenarios. 
The same patterns can also be used to control write access (e.g., accepting lifecycle updates or allowing authorised parties to add links) via authenticated endpoints.

### Anonymous Public Access

Anonymous access to public data is the default UNTP access pattern. It is already described in the [identity resolver](IdentityResolver.md) specification. From a security and resilience perspective, the only requirements are 

* That data providers MUST NOT **require** personal identifying information from the data requestor as a condition of providing public information.
* That data SHOULD remain available for the lifetime of the product, irrespective of whether the original manufacturer still exists. 

Both of these requirements are met using the [identity resolver](IdentityResolver.md) specification. 

### Unguessable Identifiers

Most item identifiers are relatively short numbers and are issued sequentially. So, for example, if `https://example.com/product/11223/serial/44556` is a known product and serial identifier then it is likely that the next serialised item ID could be `https://example.com/product/11223/serial/44557` or that the next product and serial in the range could be `https://example.com/product/11224/serial/00001`. When identifiers are easily guessed then information about the products is easily discovered even when the data requestor is not in possession of an actual product or serialised item.

However, if the product and serial numbers are issued as **genuinely random** large numbers then they become un-guessable and so any public (ie non-encrypted) data linked to the ID can be considered to be accessible only to the party in possession of the item. For example `https://example.com/product/11223/serial/44FDB2AFC91B898893CF36CB18863D26` is a product with a 32 character hexadecimal (128 bit) serial number and, provided the serial number is genuinely random, is computationally impractical to guess (1 billion guesses per second would still take many universe lifetimes). 

Large random serial numbers are not common practice in industry and so are more likely to be considered for new rather than existing identifier schemes.  However, depending on the sensitivity of the data, shorter serial numbers (eg `https://example.com/01/0952400005919/21/419A2845FD8050A0DD56`) may provide adequate confidentiality provided they are issued randomly and not sequentially. For example, if serial number `419A2845FD8050A0DD56` were one of a million serialised items of product ID `0952400005919` then it would still take a few years to guess one matching serial number at 1 billion guesses per second.

When non-guessable large identifiers are used as a security mechanism to access non-encrypted sensitive data, then;

* the access mechanism is no different to [anonymous public access](#anonymous-public-access). 
* the identifiers MUST be **genuinely random** strings 
* the data MUST NOT be index-able by search engines.
* the web repository that holds the data MUST NOT be searchable or expose lists of stored files.

### Encrypted Content

In many cases, relying on an un-guessable identifier is not possible or not sufficiently secure. In such cases, confidential data SHOULD be encrypted.

* Encryption MUST be done with a symmetric encryption algorithm such as [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) with a minimum of 128 bit key length.
* Each distinct identified entity (i.e. facility, product, product batch, or serialised item with a unique IDR path) MUST use a separate and unique encryption key.  
* Where there are multiple different authorised roles that require access to different non-public data then a unique encryption key SHOULD be used for each role.
* Where there are multiple non-public documents or credentials for a given unique entity and authorised role then they SHOULD be encrypted with the same key.

These encryption requirements will result in an optimal granularity of encryption where one or more encrypted objects about a specific item and for access by a specific authorised role are all encrypted with the same key. But data for other roles or other items are not accessible with the given key. 

### Shared Secrets

:::note Terminology Note
This specification uses the term **"secret"** for consistency with established cryptographic standards (e.g., **"shared secret"** in key exchange protocols). In business contexts, implementers may find terms like **"access code"** or **"decryption key"** more user-friendly when communicating with non-technical stakeholders. The technical meaning remains the same regardless of terminology choice.
:::

When confidential data about serialised items is encrypted then decryption keys SHOULD be included with the product and be optimised for easy use. 

* The key SHOULD be presented as a QR code (either included with the product or, for bulk/raw materials, sent separately)
* The code MUST resolve to an [Identity Resolver](IdentityResolver.md) query URL for the given item and with the symmetric key secret as a `decryptionKey` parameter.
* For cases with limited space such as a QR under a wine bottle cap, implementers MAY use a shorter URL that redirects to the same full identity resolver URL. The short URL SHOULD include 128 bit entropy so that it is sufficiently un-guessable.

For example, for a 128 bit AES key in a query to a resolver about product ID 90664869327 that returns only encrypted link targets for anonymous access the resolver URL would be `https://resolver.product-register.com/01/90664869327?decryptionKey=2b7e151628aed2a6abf7158809cf4f3c&accessRole=untp%3AaccessRole%23Anonymous`

#### Small footprint codes

A 128 bit short redirect URL (in capitals because that creates smaller QR codes) can be used for cases where there is limited space for QR codes.  For example `HTTPS://REDIRECT.IO/E05778C659733E222758AC5179AE4611` could redirect to the same full URL `https://resolver.product-register.com/01/90664869327?decryptionKey=2b7e151628aed2a6abf7158809cf4f3c&accessRole=untp%3AaccessRole%23Anonymous`

The full and short URLs would produce the following QR codes

| Full resolver URL                    | Short redirect URL                   |
| ------------------------------------ | ------------------------------------ |
| ![Full](../assets/images/dac-QR-DACcomplexURLwithKey.png) | ![Short](../assets/images/dac-QR-DACshortRedirectURL.png) |

### Federated Authentication

In some cases access to (and update of) confidential data requires more than a shared secret that proves ownership of a serialised item but also requires evidence that the data requestor has an authorised role such as a competent authority, a recycling plant, or accredited auditor. When the data requestor is already known and registered with the data provider then a conventional "sign-in-with" federated authentication and authorisation mechanism such as [OAuth 2.0](https://oauth.net/2/) or [OIDC](https://openid.net/specs/openid-connect-core-1_0.html) can be used. UNTP does not impose any restrictions on how a data provider authenticates and authorises access to protected data for users that are already known to the provider. 

However, these kind of protocols require a relying-party relationship between the data provider that requires evidence of identity (eg a product passport issuer) and an identity provider that is the manager of the identity (eg a regulatory authority). Although this "sign-in-with" protocol is easy to implement with social network identity providers who deliberately place low barriers to relying parties, more authoritative registers such as national business registers, land registers, trademark registers, and so on are much more conservative. They mostly either don't offer federated identity or even if they do, they are very restrictive about allowed relying parties. 

### Decentralised Authentication

Decentralised protocols provide a much simpler and more scalable authentication and authorisation approach for decentralised architectures that avoids any need for direct collaboration or dependencies between data providers and identity providers. For example, consider an access rule defined by a China based battery manufacturer that says "to update battery status to `recycled` the requestor must be an accredited recycling establishment operating in a recognized jurisdiction (eg Australia). The workflow would be 

* Australian recycling plant "Sample Recyclers" is accredited under the Australian Government Department of Environment [stewardship scheme](https://www.dcceew.gov.au/environment/protection/waste/product-stewardship/product-schemes/voluntary-product-stewardship) and has obtained a [Digital Identity Anchor](DigitalIdentityAnchor.md) credential that links their DID to their government accreditation status.
* Sample Recyclers receives a battery for recycling after 7 years of use that was originally made by "China Batteries Sample Co".  It has a serialised item specific QR secret printed on the battery.
* Sample Recyclers scans the QR (which includes presentation of the secret), receives an IDR link-set response that includes a UNTP standard link that defines an authenticated method and URL to add a recycled event to the battery history that requires evidence of accredited recycler status.
* Sample Recyclers authenticates to the specified endpoint using DID-Authentication and presents their Australian Government issued DIA credential as a verifiable presentation.
* China Sample Batteries Co verifies the presentation (which confirms DID control) and checks that the issuer (AU government) is on their trusted white-list, and then adds the recycled event to the item history. 

#### Decentralised authentication protocol options.

UNTP does not define any new protocols for decentralised authentication but rather supports the use of any of the existing standards listed below.

* [DID Auth specification](https://w3c-ccg.github.io/vp-request-spec/#did-authentication)
* [DID SIOP specification](https://openid.net/specs/openid-connect-self-issued-v2-1_0.html)
* [OID4VP specification](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) 

| Aspect                  | DID Authentication                                   | DID-SIOP                       | OpenID4VP                           |
| ----------------------- | ---------------------------------------------------- | ------------------------------ | ----------------------------------- |
| **Primary Purpose**     | DID-based authentication with credential integration | Decentralized login using OIDC | Credential presentation in OIDC     |
| **Workflow Complexity** | Moderate                                             | Moderate                       | Complex                             |
| **OIDC Integration**    | No                                                   | Yes                            | Yes                                 |
| **Use Case Focus**      | Proving DID control with credential attachment       | Decentralized login            | Claim verification and presentation |

The best choice will eventually be the specification(s) that demonstrate the widest market implementation. At this time, the UNTP recommendation is that implementers SHOULD use **DID-Authentication** but MAY also use either **DID-SIOP** or **OpenID4VP**.

### Confidential data discovery

Identity resolvers MUST include information to indicate when a link target is encrypted. Resolvers MUST also provide information about how to POST update events, where appropriate.

* When a link target is encrypted, the `encryptionMethod` custom property MUST be included with a value drawn from the [UNTP encryption method code list](https://test.uncefact.org/vocabulary/untp/core/0/encryptionMethodCode).
* When a link target is encrypted, the `accessRole` custom property MUST be included. The allowed values are an array of URIs that will be used to match against `registrationScopeList` in digital identity anchor credentials. 
* To indicate that access is allowed by any party that holds a secret key, the accessRole `untp:accessRole#Anonymous` MUST be included.
* To indicate that the link target is an update service, the `"method": "POST"` property is required, together with the `accessRole` needed for the update to be accepted. 

For example 

```json
{
    "linkset": [
        {
            "anchor": "https://resolver.product-register.com/01/90664869327",
            "dte": [
                {
                    "href": "https://sample-credential-store.com/credentials/dte-90664869327.json",
                    "title": "Battery maintenance event",
                    "type": "application/ld+json",
                    "hreflang": ["en"],
                    "encryptionMethod": "AES-128",
                    "accessRole":["untp:accessRole#Anonymous"]
                 },
                {
                    "href": "https://api.sample-credential-store.com/credentials",
                    "title": "Battery recycling event",
                    "type": "application/ld+json",
                    "hreflang": ["en"],
                    "method": ["POST"],
                    "accessRole":["untp:accessRole#Recycler"]
                 }
            ]
        }
    ]
} 
```

## Implementation Considerations

To do - add guidance relevant to decentralised access control for common concerns and use-cases.

### Linked confidential data

Data about a value chain comprises multiple credentials about products and facilities in a linked-data graph. Any of the credentials in the graph may be considered confidential and therefore be protected by an appropriate access control method. This will present challenges for verifiers such as supply chain traceability systems that need to traverse long graphs for their customers. A typical scenario might work as follows:

* A verifier encounters a serialised product ID and performs an IDR lookup which returns a link-set which contains:
	* link to an un-encrypted Digital Product Passport (DPP) which also contains an ID of the facility that manufactured the item
	* links to an encrypted Digital Traceability Event (DTE) with `"encryptionMethod": "AES-128"` and `"accessRole":["untp:accessRole#Anonymous"]` properties.
* The verifier has the secret key for the given item and so decrypts the DTE to find that it is a transformation event that lists the identifiers and quantities of input products. 
	* For some of the input product ID, the verifier is able to resolve link-sets from relevant IDRs and access public data (eg DPPs) about the input products.
	* The input product IDR process also returns encrypted links but they cannot be decrypted because the verifier has no access to the secret key for supplier input products.
* The verifier resolves the facility ID found in the DPP to a new link-set that contains links to both public and private data about the facility.
	* A link to a public digital facility record (DFR) includes precise geo-location information as well as some public sustainability claims.
	* A set of links to facility level conformity credentials (DCC) that are encrypted and have `"accessRole":["untp:accessRole#Customer"]` property. The verifier uses DID-Authentication to connect to the DCC end points and presents a Digital Identity Anchor (DIA) that proves the verifier ID which matches a facility customer list. Decryption keys are provided with a new link-set of the authorised customer.

In general, when a verifier hits a graph node that is encrypted and does not have access keys, then graph traversal cannot proceed beyond that node. Perhaps the most common scenario will be transformation events that reveal the input products (and suppliers) in a manufacturing process. 

### N-tier supplier visibility

To do - guidance about how to handle upstream product / supplier data that is considered sensitive. There are likely to be four "levels" of transparency that implementers may choose:

* Make it all public
* Make your suppliers visible only to your direct customers (eg if the ID in your DIA matches the destination party ID in a transaction event)
* Use a trusted third party to assess your supply chain sustainability without revealing supplier identities - and issue a more public digital conformity credential that attests to qualities without identities.
* Make it all private and never share anything.

### Durable storage

Managing protected data durability is important to ensure that product and facility information remains accessible even after the original supplier or publisher is no longer in business. For detailed guidance on storage patterns, redundancy strategies, and credential lifecycle management, see the [Durable Storage](../design-patterns/DurableStorage.md) design pattern.

---

## Digital Facility Record

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

### V0.7.0 Schema and Samples

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

- **JSON Schema:**

| Schema | Description |
| --- | --- |
| [DigitalFacilityRecord.json](pathname:///artefacts/schema/v0.7.0/dfr/DigitalFacilityRecord.json) | Full credential schema including the W3C VC envelope and Facility subject |
| [Facility.json](pathname:///artefacts/schema/v0.7.0/dfr/Facility.json) | Standalone schema for the Facility credential subject |

- **Sample Instances:**

| Sample | Description |
| --- | --- |
| [DigitalFacilityRecord_instance.json](pathname:///artefacts/samples/v0.7.0/dfr/DigitalFacilityRecord_instance.json) | Copper mine in Zambia |
| [DigitalFacilityRecord_smelter_instance.json](pathname:///artefacts/samples/v0.7.0/dfr/DigitalFacilityRecord_smelter_instance.json) | Copper refinery in Japan |
| [DigitalFacilityRecord_battery_instance.json](pathname:///artefacts/samples/v0.7.0/dfr/DigitalFacilityRecord_battery_instance.json) | Battery factory in Germany |

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

### Vocabulary and Context

The DFR is built on the [UNTP Core Vocabulary](CoreVocabulary.md), which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published at [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/).

### Sample Credential

| URL | QR | Description |
| --- | --- | --- |
| [Sample Digital Facility Record](https://untp.showthething.com/verify?uri=https%3A%2F%2Funtp-storage.s3.ap-southeast-2.amazonaws.com%2Fcf923006-89e6-4490-9f96-67e9453b7295.json) | ![Sample Digital Facility Record](../assets/images/sample-dfr-qrcode-v0.7.0.jpg) | A sample digital facility record as a signed Verifiable Credential. The URL (or QR scan) resolves to a hosted verifier that displays a human-readable version. Raw JSON data can be viewed via the `JSON` tab and the full credential can be downloaded via the download button. |

## Overview

The digital facility record (DFR) is issued by the owner or operator of a production or manufacturing facility and is the carrier of **facility data and sustainability information** for an identified facility in the value chain. It describes the facility's identity, location, ownership, material consumption, and sustainability performance over a defined reporting period. Because facilities are long-lived assets, DFRs are designed to be **re-issued periodically** (e.g. quarterly or annually) to provide an up-to-date picture of facility operations.

A facility typically has **multiple identifiers** issued by different organisations — a national environmental register, a mining cadastre, an industry membership number. The DFR architecture allows each of these identifiers to resolve to the **same facility record** maintained by the facility operator, restoring data ownership to the natural owner while enabling discovery from any register. The DFR is discoverable in the same way as a DPP — by resolving a facility identifier to an [Identity Resolver](IdentityResolver.md) service that returns links to the facility record.

The DFR tracks **material usage** — the raw materials consumed by the facility, their origin countries, mass fractions, recycled content, and hazardous indicators — as well as **performance claims** at the facility's annual total level (e.g. total Scope 1 emissions in tonnes) rather than at the per-product level. In many value chains, facility-level information may be sufficient to meet the due diligence requirements of buyers, and so the DFR can be used independently of product passports. However, product passports SHOULD reference the facility at which the product was produced. Where both facility and product information are available, verifiers can perform an approximate **mass-balance cross-check** — for example, the total emissions recorded across all products shipped from a facility should approximately equal the reported annual emissions of the facility.

## Conceptual Model

![Digital Facility Record conceptual model](../assets/images/dfr-concept.png)

A Digital Facility Record answers six key questions about a production or manufacturing facility:

- **WHO** owns or operates the facility — identified by a registered business entity with a verifiable identifier.
- **WHAT** is the facility — its identity, name, address, and registration details.
- **WHERE** is it located — using point coordinates, boundary polygons, or Plus Codes.
- **SCOPE** of operations — classified by industry process categories (e.g. UN CPC).
- **MATERIAL** usage — what raw materials are consumed, their origin countries, volumes, and recycled content over a reporting period.
- **CLAIMS** about facility performance — conformity claims against recognised standards or regulations, each quantified by specific performance metrics such as GHG emissions intensity or water consumption.

## Requirements

The digital facility record is designed to meet the following detailed requirements as well as the more general [UNTP Requirements](https://untp.unece.org/docs/about/Requirements)

| ID | Name | Requirement Statement | Solution Mapping |
| --- | --- | --- | --- |
| DFR-01 | Resolvable ID | Each facility must have at least one resolvable identifier that can be used in digital product passports and other data exchanges so that verifiers can always access the latest facility data. | `Facility.id` and `Facility.registeredId` with `Facility.idScheme` |
| DFR-02 | Process categories | The DFR should support any number of industry process classifications using codes from a defined classification scheme (eg UN CPC). | The `Facility.processCategory` array of `Classification` objects |
| DFR-03 | Geo-Location | The DFR should provide a means to specify a geo-location point, a boundary geometry, and/or a variable-precision area code so that verifiers can geo-locate supplier facilities. | `Facility.locationInformation` with `geoLocation`, `geoBoundary`, and `plusCode` |
| DFR-04 | Related parties | The DFR should specify the owner and/or operator of the facility using one or more globally unique and resolvable entity identifiers, each in a defined role. | The `Facility.relatedParty` array of `PartyRole` objects, each linking to a `Party` with verifiable identifiers |
| DFR-05 | Claims | The DFR MUST provide a means to include any number of performance claims so that it can provide a single point to aggregate all claims about the facility in one place. | The `Facility.performanceClaim` array of `Claim` objects |
| DFR-06 | Conformity Topic | The DFR 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](CoreTaxonomies.md) taxonomy |
| DFR-07 | Metrics | The DFR MUST provide a simple mechanism to quantify a performance 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](CoreTaxonomies.md) taxonomy), `measure` (value + unit), and `score` (code + rank) |
| DFR-08 | Criteria | The DFR 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` |
| DFR-09 | Evidence | The DFR 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](ConformityCredential.md) (DCC) or other supporting document |
| DFR-10 | Material usage | The DFR should provide a structure to describe the raw materials consumed by the facility over a reporting period, including origin country, mass fraction, recycled content, and hazardous material indicators. | The `Facility.materialUsage` property with `MaterialUsage.materialConsumed` array of `Material` objects |
| DFR-11 | Reporting period | The DFR should support time-bounded reporting so that claims and material consumption can be attributed to a specific period, even when different data sources follow different reporting cycles. | The `applicablePeriod` property on both `Claim` and `MaterialUsage`, independent of the credential-level `validFrom` / `validUntil` |
| DFR-12 | Address | The DFR should provide a structured postal address for the facility, distinct from its geographic coordinates. | The `Facility.address` property using the `Address` class |
| DFR-13 | Alternative identifiers | The DFR should support listing additional facility identifiers from other schemes so that multiple registers and directories can resolve to the same facility record. | The `Facility.facilityAlsoKnownAs` array of identifier objects |
| DFR-14 | Related documents | The DFR should provide a means to link to supporting documents such as environmental permits, site plans, or conformity credentials that are relevant to the facility but are not structured data within the credential. | The `Facility.relatedDocument` array of `Link` objects |

## Logical Model

The Digital Facility Record is an assembly of re-usable components from the UNTP core vocabulary.

![Digital Facility Record data model](../assets/images/dfr-model.svg)

The DFR credential wraps a `Facility` as its credential subject. The facility carries identification, classification, and descriptive information alongside the following key structures:

- **Ownership and operation** — related parties in defined roles via `PartyRole`, each linking to a `Party` with verifiable identifiers, registration country, address, and industry classification.
- **Location** — the `Location` of the facility using Plus Codes, point coordinates (`Coordinate`), or boundary polygons, plus a structured `Address`.
- **Material usage** — a `MaterialUsage` object describing the `Material` inputs consumed over a reporting period, each with origin country, mass fraction, recycled content, and hazardous indicators.
- **Performance claims** — an array of `Claim` objects, each referencing a `Criterion` from a standard or regulation, classified by `ConformityTopic`, and carrying quantified `Performance` measures classified by `PerformanceMetric`. Claims link to supporting evidence such as conformity credentials.

For detailed class and property definitions, see the [Core Vocabulary](CoreVocabulary.md) reference.

## Implementation Guidance

### Reporting Periods

Unlike a DPP, which is a performance snapshot of a specific product model, batch, or item, the DFR describes a **long-lived facility**. Facility operators are expected to issue DFRs on a regular basis (e.g. quarterly or annually) to describe the performance of a facility over a defined period. The `performanceClaim` array carries claims for the current reporting period, and each claim includes an `applicablePeriod` to make the time range explicit.

In practice, reporting periods do not always align neatly across all data sources. Bulk material consumption may be reported on a calendar-year basis while a third-party conformity attestation covers a different audit cycle. For this reason, both `MaterialUsage` and `Claim` include an `applicablePeriod` property that can specify a precise date range, allowing each component to declare its own time boundaries independently of the credential's overall `validFrom` / `validUntil` dates.

### Facility Identifiers

A DFR is discovered by downstream customers by resolving the facility identifier — for example, scanning a facility ID or looking it up in a register — to find the DFR via an [Identity Resolver](IdentityResolver.md). Most facilities have **multiple identifiers** issued by different organisations: a national environmental register, a mining cadastre, an industry association membership number, and so on. The key insight is that each of these identifiers can resolve to the **same DFR** that the facility owner maintains and controls.

This architecture restores ownership of facility data to the natural owner — the facility operator — while allowing multiple registers and directories to link to it, like many different road signs pointing at the same city. In the DFR, the primary identifier is carried by `Facility.id` and `Facility.registeredId`, while additional identifiers are listed in the `facilityAlsoKnownAs` array.

### Data Mapping

Implementers should map their existing facility data to a UNTP DFR following a similar approach to [DPP data mapping](DigitalProductPassport.md#implementation-guidance):

| Mapping Type | UNTP Pattern | When to use |
| --- | --- | --- |
| **Direct property** | Named properties on `Facility` (e.g. `id`, `countryOfOperation`, `processCategory`, `address`, `locationInformation`, `relatedParty`) | The source attribute has a direct equivalent in the UNTP core vocabulary |
| **Related document** | `Facility.relatedDocument` — a `Link` to an external resource | Supporting documents such as environmental permits, site plans, or conformity credentials |
| **Performance claim** | `Facility.performanceClaim` — a `Claim` referencing a `ConformityTopic`, a `PerformanceMetric`, and optionally linked to a scheme criterion, an external standard, and/or relevant national regulations | Quantified sustainability metrics such as annual GHG emissions, water consumption, or recycled content |
| **Separate credential** | A UNTP [Digital Traceability Event](DigitalTraceabilityEvents.md) (DTE) or [Digital Conformity Credential](ConformityCredential.md) (DCC) linked from the DFR | Detailed mass-balance stocks and flows (DTEs) and independent third-party audits of those flows (DCCs) — data that UNTP recommends managing outside the DFR |
| **No mapping** | — | If you find a facility data requirement that cannot be mapped, please contact our [mailing list](/) so we can address it |

### Geographic Anchoring

Every DFR should be geographically anchored via the `locationInformation` property, which supports three representations that can be used individually or in combination:

- A single **coordinate** (`geoLocation`) — a latitude/longitude point marking the facility location.
- A **boundary** (`geoBoundary`) — a sequence of coordinates defining the facility perimeter.
- A **Plus Code** (`plusCode`) — a [Plus Code](https://maps.google.com/pluscodes/) grid reference that can define areas at varying precision, from a precise point (e.g. `8Q7Q5G22+22`) to a larger region by removing trailing digits.

## The components of a DFR

This section provides sample JSON-LD snippets for each DFR component, drawn from the [copper refinery sample credential](pathname:///artefacts/samples/v0.7.0/dfr/DigitalFacilityRecord_smelter_instance.json).

### Credential Envelope

All DFRs are issued as [W3C Verifiable Credentials (VCDM 2.0)](https://www.w3.org/TR/vc-data-model-2.0/). The credential `type` includes both `VerifiableCredential` and `DigitalFacilityRecord`, and the `@context` references both the W3C VCDM and UNTP context URIs. The issuer `id` SHOULD be a DID using a supported [DID method](VerifiableCredentials.md#did-methods), with `issuerAlsoKnownAs` linking to authoritative business register identifiers. The issuing party should be the facility owner or operator.

```json
{
  "type": ["DigitalFacilityRecord", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/"
  ],
  "id": "https://credentials.sample-refinery.example.com/dfr/smelter-002",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd",
    "issuerAlsoKnownAs": [
      {
        "id": "https://www.sample-register.example.com/henkorireki-johoto.html?selHouzinNo=REF-001",
        "name": "Sample Copper Refinery Co. Ltd",
        "registeredId": "REF-001",
        "idScheme": {
          "id": "https://www.sample-register.example.com",
          "name": "Japan Corporate Number (Houjin Bangou)"
        }
      }
    ]
  },
  "validFrom": "2025-01-15T00:00:00Z",
  "validUntil": "2028-01-15T00:00:00Z",
  "name": "Digital Facility Record — Sample Copper Refinery",
  "credentialSubject": { "type": ["Facility"], "..." : "..." }
}
```

### Facility Identification

The `Facility` credential subject identifies the facility via a resolvable URI (`id`), a registered identifier (`registeredId`), and an identifier scheme (`idScheme`). The facility `id` should be resolvable via an [Identity Resolver](IdentityResolver.md) that returns links to the DFR. The `countryOfOperation` carries the ISO 3166 country, and `processCategory` classifies operations using schemes such as [UN CPC](https://unstats.un.org/unsd/classifications/Econ/cpc). Additional identifiers from other schemes can be listed in `facilityAlsoKnownAs`.

```json
"credentialSubject": {
  "type": ["Facility"],
  "id": "https://facility-register.example.com/fac-002",
  "name": "Sample Copper Refinery",
  "description": "Copper smelting and electrolytic refining facility in Sample, Oita Prefecture, Japan.",
  "registeredId": "fac-002",
  "idScheme": {
    "id": "https://facility-register.example.com",
    "name": "UNTP Sample Facility Register"
  },
  "countryOfOperation": { "countryCode": "JP", "countryName": "Japan" },
  "processCategory": [
    {
      "code": "41521",
      "name": "Unwrought copper",
      "schemeId": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
      "schemeName": "UN Central Product Classification (CPC)"
    }
  ],
  "facilityAlsoKnownAs": [
    {
      "id": "https://prtr.example.go.jp/facilities/JP-44-SM-0021",
      "name": "Sample Copper Refinery",
      "registeredId": "JP-44-SM-0021",
      "idScheme": {
        "id": "https://prtr.example.go.jp",
        "name": "Japan PRTR Facility Register"
      }
    }
  ]
}
```

### Related Parties

The `relatedParty` array identifies organisations associated with the facility in defined roles (e.g. owner, operator). Each `PartyRole` links to a `Party` with verifiable identifiers, registration country, address, and industry classification.

```json
"relatedParty": [
  {
    "role": "owner",
    "party": {
      "type": ["Party"],
      "id": "did:web:sample-refinery.example.com",
      "name": "Sample Copper Refinery Co. Ltd",
      "registeredId": "REF-001",
      "idScheme": {
        "id": "https://www.sample-register.example.com",
        "name": "Japan Corporate Number (Houjin Bangou)"
      },
      "registrationCountry": { "countryCode": "JP", "countryName": "Japan" },
      "partyAddress": {
        "streetAddress": "3-1 Sample, Usuki",
        "postalCode": "879-2201",
        "addressLocality": "Oita",
        "addressRegion": "Oita Prefecture",
        "addressCountry": { "countryCode": "JP", "countryName": "Japan" }
      },
      "organisationWebsite": "https://sample-refinery.example.com"
    }
  }
]
```

### Related Documents

The `relatedDocument` array provides links to supporting resources such as conformity credentials, environmental reports, or permits. Each `Link` includes a URL, human-readable name, media type, and a link type from a controlled vocabulary.

```json
"relatedDocument": [
  {
    "linkURL": "https://credentials.sample-cab.example.com/dcc/smelter-002",
    "linkName": "Coppermark Certification — Sample Copper Refinery",
    "mediaType": "application/ld+json",
    "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dcc"
  }
]
```

### Location

The `locationInformation` property locates the facility geographically. It supports three representations, at least one of which should be provided:

- A [Plus Code](https://maps.google.com/pluscodes/) — a grid reference that can define areas from a precise point to a large region.
- A `geoLocation` as a decimal latitude/longitude point.
- A `geoBoundary` as a sequence of latitude/longitude pairs defining the facility boundary.

The `address` property provides a structured postal address.

```json
"locationInformation": {
  "plusCode": "https://plus.codes/8Q7Q5G22+22",
  "geoLocation": { "latitude": 33.25, "longitude": 131.88 },
  "geoBoundary": [
    { "latitude": 33.24, "longitude": 131.87 },
    { "latitude": 33.26, "longitude": 131.89 }
  ]
},
"address": {
  "streetAddress": "3-1 Sample, Usuki",
  "postalCode": "879-2201",
  "addressLocality": "Oita",
  "addressRegion": "Oita Prefecture",
  "addressCountry": { "countryCode": "JP", "countryName": "Japan" }
}
```

### Material Usage

The `materialUsage` property describes the raw materials consumed by the facility over a reporting period. Each `Material` includes its origin country, classification, mass fraction of total input, absolute mass, recycled content fraction, and hazardous indicator.

```json
"materialUsage": {
  "applicablePeriod": {
    "startDate": "2024-01-01",
    "endDate": "2024-12-31",
    "periodInformation": "Calendar year 2024 reporting period."
  },
  "materialConsumed": [
    {
      "name": "Copper concentrate",
      "originCountry": { "countryCode": "ZM", "countryName": "Zambia" },
      "materialType": {
        "code": "14110",
        "name": "Copper ores and concentrates",
        "schemeId": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
        "schemeName": "UN Central Product Classification (CPC)"
      },
      "massFraction": 0.85,
      "mass": { "value": 420000000, "unit": "KGM" },
      "recycledMassFraction": 0,
      "hazardous": false
    },
    {
      "name": "Coke (reducing agent)",
      "originCountry": { "countryCode": "AU", "countryName": "Australia" },
      "materialType": {
        "code": "33100",
        "name": "Coke and semi-coke",
        "schemeId": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
        "schemeName": "UN Central Product Classification (CPC)"
      },
      "massFraction": 0.10,
      "mass": { "value": 50000000, "unit": "KGM" },
      "recycledMassFraction": 0,
      "hazardous": false
    }
  ]
}
```

### Performance Claims

The `performanceClaim` array carries the facility operator's self-declared sustainability claims for a reporting period. Each `Claim` references criteria classified by a `ConformityTopic` from the [Conformity Topics taxonomy](CoreTaxonomies.md) and carries quantified performance using a `PerformanceMetric` from the [Performance Metrics taxonomy](CoreTaxonomies.md). Unlike product-level claims, facility claims typically report annual totals (e.g. total Scope 1 emissions in tonnes) rather than per-unit intensities. Claims SHOULD link to independent [conformity assessments](ConformityCredential.md) as `evidence`.

```json
"performanceClaim": [
  {
    "type": ["Claim"],
    "id": "https://sample-refinery.example.com/claims/ghg-2024",
    "name": "GHG Emissions — Scope 1",
    "description": "Annual Scope 1 greenhouse gas emissions from the Sample Copper Refinery for the 2024 reporting year.",
    "referenceCriteria": [
      {
        "id": "https://sample-scheme.coppermark.org/criteria/ghg-management/v3",
        "name": "GHG Emissions Management (Coppermark RRA Criterion 26)",
        "conformityTopic": [
          {
            "type": ["ConformityTopic"],
            "id": "https://vocabulary.uncefact.org/conformity-topic/greenhouse-gas-emissions",
            "name": "Greenhouse Gas Emissions"
          }
        ]
      }
    ],
    "claimDate": "2025-03-01",
    "applicablePeriod": {
      "startDate": "2024-01-01",
      "endDate": "2024-12-31"
    },
    "claimedPerformance": [
      {
        "metric": {
          "id": "https://vocabulary.uncefact.org/performance-metric/scope-1-ghg-emissions",
          "name": "Scope 1 GHG Emissions"
        },
        "measure": { "value": 120000, "unit": "TNE" }
      }
    ],
    "conformityTopic": [
      {
        "type": ["ConformityTopic"],
        "id": "https://vocabulary.uncefact.org/conformity-topic/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 facility operator claims — both reference the same criterion. Issuers can discover the right criterion URIs via the UNTP [Conformity Vocabulary Catalog](ConformityVocabularyCatalog.md).

---

## Digital Identity Anchor

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

### V0.7.0 Schema and Samples

The JSON schema and sample credential instance for the Digital Identity Anchor are maintained in this repository.

- **JSON Schema:**

| Schema | Description |
| --- | --- |
| [DigitalIdentityAnchor.json](pathname:///artefacts/schema/v0.7.0/dia/DigitalIdentityAnchor.json) | Full credential schema including the W3C VC envelope and RegisteredIdentity subject |
| [RegisteredIdentity.json](pathname:///artefacts/schema/v0.7.0/dia/RegisteredIdentity.json) | Standalone schema for the RegisteredIdentity credential subject |

- **Sample Instances:**

| Sample | Description |
| --- | --- |
| [DigitalIdentityAnchor_smelter_instance.json](pathname:///artefacts/samples/v0.7.0/dia/DigitalIdentityAnchor_smelter_instance.json) | Business register anchors the smelter owner DID to a corporate number |
| [DigitalIdentityAnchor_mine_instance.json](pathname:///artefacts/samples/v0.7.0/dia/DigitalIdentityAnchor_mine_instance.json) | Mining cadastre anchors the mine operator DID to a facility registration |
| [DigitalIdentityAnchor_battery_instance.json](pathname:///artefacts/samples/v0.7.0/dia/DigitalIdentityAnchor_battery_instance.json) | Trademark register anchors the battery manufacturer DID to a registered trademark |

The three samples illustrate different register types — business, facility, and trademark — each anchoring a DID from the copper-to-battery supply chain to an authoritative registered identity.

### Vocabulary and Context

The DIA is built on the [UNTP Core Vocabulary](CoreVocabulary.md), which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published at [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/).

### Sample Credential

| URL | QR | Description |
| --- | --- | --- |
| [Sample Digital Identity Anchor](https://untp.showthething.com/verify?uri=https%3A%2F%2Funtp-storage.s3.ap-southeast-2.amazonaws.com%2Fb04ba610-d71f-42dc-8429-b066b5ff471b.json) | ![Sample Digital Identity Anchor](../assets/images/sample-dia-qrcode-v0.7.0.jpg) | A sample digital identity anchor as a signed Verifiable Credential. The URL (or QR scan) resolves to a hosted verifier that displays a human-readable version. Raw JSON data can be viewed via the `JSON` tab and the full credential can be downloaded via the download button. |

## Overview

The Digital Identity Anchor (DIA) credential provides a means to verify the real-world identity of UNTP credential issuers. The `issuer.id` property of all UNTP credentials is a W3C decentralized identifier (DID), which allows credentials such as Digital Product Passports (DPPs) to be cryptographically verified as genuinely issued by the entity that controls that DID. However, as a self-issued identity, the DID alone does not provide confidence that the issuer is really who they claim to be.

Authoritative identity registers — national business registers, trademark registers, mining cadastres, and similar institutions — exist in most countries and have well-established registration and verification processes. Unfortunately, most of these registers only issue paper or PDF registration certificates that are easily faked and cannot be used for digitally verifiable proof of identity.

The UNTP DIA bridges this gap. It is essentially a digitally verifiable version of a registration certificate, issued by the authoritative register to authenticated members after the member proves ownership of their DID. When a DIA accompanies a UNTP credential such as a DPP, a verifier can confirm not only that the DPP was issued by the holder of the DID, but also that the controller of the DID is the holder of an authoritative registered identity.

## Conceptual Model

The Digital Identity Anchor (DIA) is a verifiable credential that is issued by a trusted authority and asserts an equivalence between a member identity as known to the authority (eg a VAT number) and one or more decentralised identifiers (DIDs) held by the member. Before issuing the DIA, the authority MUST verify DID ownership (eg using [DID Auth](https://w3c-ccg.github.io/vp-request-spec/#did-authentication)).

![Digital Identity Anchor Concept](../assets/images/dia-concept.png)

The outcome is that the subject of the DIA (eg the VAT registered business) can prove that they are the registered identity to any other party. In the UNTP context the DIA provides assurance that a DPP (or DCC/DFR/DTE) issuer really is who they say they are. The verification workflow is as follows

- A verifier (eg buyer of an identified product) discovers a DPP for the product and verifies the credential - confirming that the DPP has not been tampered-with, is genuinely issued by party identified by the issuer DID.
- The DID is resolvable to the DID document which contains a link to the DIA in the DID document `service` endpoint.
- The verifier verifies the DIA credential and confirms that the DPP issuer DID matches the `credentialSubject.id` of the DIA.
- The verifier confirms that the DID of the issuing authority (the authoritative registrar for the jurisdiction) is on the trusted register list.

The DIA can also be used for similar trust anchoring purposes such as:

- Accreditation authorities issue DIA to assert that a conformity assessment body is accredited against a given scheme.
- IP Offices issue DIA to assert that a registered party is the genuine owner of a trademark.
- Land registers issue DIA to assert that a regulated party is the owner of a geo-located property.

## Requirements

The digital identity anchor is designed to meet the following detailed requirements as well as the more general [UNTP Requirements](https://untp.unece.org/docs/about/Requirements)

| ID     | Name                | Requirement Statement                                                                                                                                                                                                                                    | Solution Mapping                                                                                                    |
| ------ | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| DIA-01 | DID Verification    | The DIA issuer (registrar) MUST confirm that the registered member (subject) is the legitimate controller of a DID before issuing a DIA credential so that the registrar is protected against members falsely claiming ownership of well known DIDs      | SHOULD use the [DID Auth](https://w3c-ccg.github.io/vp-request-spec/#did-authentication) protocol for this purpose. |
| DIA-02 | DIA Issuer DID      | The DIA issuer MUST use a supported DID method (see [DID Methods](VerifiableCredentials.md#did-methods)) as the DIA issuer and the domain MUST match the well known domain of the issuing authority so that verifiers can confirm authority identity via public records.        | `CredentialIssuer.id` — the issuer DID in the [Credential Envelope](#credential-envelope) |
| DIA-03 | Scheme registration | The DIA issuing authority SHOULD register the identity scheme (including the trusted issuer DIDs) with the UN/CEFACT identifier scheme registry so that verifiers can leverage UN maintained scheme metadata to simplify DIA discovery and verification. | [UN GRID](#authoritative-registers-and-the-un-grid) for authoritative registers; UNTP [implementation registers](#non-authoritative-registers) for others |
| DIA-04 | Multiple DIDs       | A registered member may need to link multiple DIDs to one registered ID, either because there is a need to transition between DID service providers or because an organisation may choose to use different DIDs for different purposes.                  | Issue multiple DIAs                                                                                                 |
| DIA-05 | Scope List          | The DIA MUST include a list of scope URIs that unambiguously define the authorised role(s) of the member in the register so that verifiers can confirm the scope of the membership.                                                                      | `RegisteredIdentity.registrationScope` |
| DIA-06 | Register Type       | The DIA MUST specify the register type so that verifiers can understand the context of the `registrationScope`                                                                                                                                       | `RegisteredIdentity.registerType` |
| DIA-07 | DIA Discovery       | The DIA SHOULD be discoverable given either the DID or the registeredID                                                                                                                                                                                  | [DIA Discovery](#dia-discovery)                                                                                     |
| DIA-08 | White list          | The DIA should include a mechanism to avoid malicious actors who are not the registrar from issuing DIAs that claim links to authoritative registered IDs                                                                                                | [UN GRID](#authoritative-registers-and-the-un-grid) and UNTP [implementation registers](#non-authoritative-registers) maintain trusted issuer lists |

The examples below help to clarify the application of DIA-05 and DIA-06.

## Logical Model

The Digital Identity Anchor is a simple credential that binds a DID to a registered identity in an authoritative register.

![Digital Identity Anchor data model](../assets/images/dia-model.svg)

For detailed class and property definitions, see the [Core Vocabulary](CoreVocabulary.md) reference. For implementation details, sample JSON-LD snippets, and register-specific use cases, see [The Components of a DIA](#the-components-of-a-dia) below.

## Implementation Guidance

### Who Issues DIAs?

DIAs are issued by authorities that already operate authoritative identity registers — national business registers, mining cadastres, trademark offices, accreditation bodies, and similar institutions. These authorities have well-established registration and verification processes. The DIA simply extends their existing function by issuing a digitally verifiable credential that binds a member's DID to their registered identity, rather than only issuing paper or PDF registration certificates.

The critical trust question for a verifier is: *how do I know that the DIA issuer is genuinely the authority it claims to be, and not a fraudulent actor masquerading as an authoritative register?*

### Authoritative Registers and the UN GRID

The UN/CEFACT [Global Registrar Information Directory (GRID)](https://un.opensource.unicc.org/unece/uncefact/gtr/) is designed to address this trust question for authoritative registers operated by regulatory authorities in UN member states. Registers listed on the GRID — such as national business registers, land registries, and government-operated accreditation bodies — are maintained by recognised sovereign authorities. When a DIA issuer DID appears on the GRID, a verifier can have high confidence that the issuer is the legitimate authority for that identity scheme.

Register operators that wish to issue DIAs should:

1. Register their identity scheme on the UN GRID, including their trusted issuer DID(s).
2. Implement [DID Auth](https://w3c-ccg.github.io/vp-request-spec/#did-authentication) or equivalent DID ownership verification before issuing DIAs to registered members.
3. Make DIAs [discoverable](#dia-discovery) from both the member's DID document and the register's identity resolver service.

### Non-Authoritative Registers

UNTP recognises that trust in the supply chain ecosystem is also supported by identity assertions from registers that are not operated by sovereign regulatory authorities. These include product registers (e.g. GS1 GTIN), industry association membership registers, facility registers operated by industry bodies, and similar non-governmental schemes. While these registers may not carry the same sovereign authority as government registers, they are nonetheless well-established and trusted within their respective domains.

Because the UN GRID is designed to list only registers operated by regulatory authorities in member states, these non-authoritative registers are not eligible for GRID listing. Instead, UNTP maintains lists of recognised non-authoritative registers in its [implementations register pages](../implementations/cvc/), providing a similar level of register identity assurance. Verifiers can consult both the UN GRID (for authoritative registers) and the UNTP register pages (for non-authoritative registers) to determine whether a DIA issuer is a recognised register operator.

## The Components of a DIA

This section provides sample JSON-LD snippets for each DIA component, drawn from the [smelter identity anchor sample](pathname:///artefacts/samples/v0.7.0/dia/DigitalIdentityAnchor_smelter_instance.json).

### Credential Envelope

All DIAs are issued as [W3C Verifiable Credentials (VCDM 2.0)](https://www.w3.org/TR/vc-data-model-2.0/). The credential `type` includes both `VerifiableCredential` and `DigitalIdentityAnchor`, and the `@context` references both the W3C VCDM and UNTP context URIs. Critically, the issuer MUST be the authoritative register itself — not the entity whose identity is being anchored. The issuer `id` SHOULD be a DID using a supported [DID method](VerifiableCredentials.md#did-methods), and the domain MUST match the well-known domain of the issuing authority so that verifiers can confirm registry identity via public records. Please refer to [DPP VC Guidance](DigitalProductPassport.md#credential-envelope) for further information about the use of the verifiable credentials data model for UNTP.

```json
{
  "type": ["DigitalIdentityAnchor", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/"
  ],
  "id": "https://credentials.houjin-register.example.com/dia/ref-001",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:houjin-register.example.com",
    "name": "Sample National Tax Agency — Corporate Number System",
    "issuerAlsoKnownAs": [
      {
        "id": "https://www.houjin-register.example.com",
        "name": "Sample National Tax Agency"
      }
    ]
  },
  "validFrom": "2025-04-01T00:00:00Z",
  "validUntil": "2027-03-31T00:00:00Z",
  "name": "Corporate Identity Anchor — Sample Copper Refinery Co. Ltd",
  "credentialSubject": { "type": ["RegisteredIdentity"], "...": "..." }
}
```

### Registered Identity

The `RegisteredIdentity` is the `credentialSubject` of the DIA. It establishes the binding between a DID controlled by the subject and a registered identity in the authoritative register.

- `id` MUST be the DID of the registered member. The registrar MUST verify DID ownership (e.g. using [DID Auth](https://w3c-ccg.github.io/vp-request-spec/#did-authentication)) before issuing the DIA.
- `registeredName` is the entity name as it appears in the authoritative register.
- `registeredId` is the identifier value that is unique within the register (but may not be globally unique), for example a corporate number, facility licence number, or trademark registration number.
- `registeredDate` is the date the entity was first registered.
- `publicInformation` links to the public record on the registrar's site.
- `schemeId` identifies the identifier scheme operated by the registrar. If the scheme is registered with UN/CEFACT then `schemeId.id` MUST match the `identityRegister.id` in the UN/CEFACT scheme register.
- `registrar` identifies the authority that operates the register.
- `registerType` classifies the register (one of `business`, `facility`, `product`, `trademark`, `land`, `accreditation`), allowing verifiers to distinguish between different DIA use cases.
- `registrationScope` is an array of URIs that define the scope of the registration. The values are specific to the register — for example, a business register might reference entity types, a mining register might reference licence categories.

```json
"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-refinery.example.com",
  "registeredName": "Sample Copper Refinery Co. Ltd",
  "registeredId": "REF-001",
  "registeredDate": "1985-06-15",
  "publicInformation": "https://www.houjin-register.example.com/henkorireki-johoto.html?selHouzinNo=REF-001",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://www.houjin-register.example.com",
    "name": "Japan Corporate Number (Houjin Bangou)"
  },
  "registrar": {
    "id": "https://www.houjin-register.example.com",
    "name": "Sample National Tax Agency"
  },
  "registerType": "business",
  "registrationScope": [
    "https://www.houjin-register.example.com/EntityType?Id=kabushiki-kaisha"
  ]
}
```

### Use Case: Business Register

A national business register issues a DIA to anchor a company's DID to its registered corporate identity. This is the most common DIA use case — it allows a verifier who receives a DPP, DFR, or DCC issued by the company to confirm that the issuer DID is controlled by a legitimately registered business entity. In this example, the Japanese corporate number register anchors the copper refinery's DID to its corporate number.

```json
"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-refinery.example.com",
  "registeredName": "Sample Copper Refinery Co. Ltd",
  "registeredId": "REF-001",
  "registeredDate": "1985-06-15",
  "publicInformation": "https://www.houjin-register.example.com/henkorireki-johoto.html?selHouzinNo=REF-001",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://www.houjin-register.example.com",
    "name": "Japan Corporate Number (Houjin Bangou)"
  },
  "registrar": {
    "id": "https://www.houjin-register.example.com",
    "name": "Sample National Tax Agency"
  },
  "registerType": "business",
  "registrationScope": [
    "https://www.houjin-register.example.com/EntityType?Id=kabushiki-kaisha"
  ]
}
```

### Use Case: Facility Register

A national mining cadastre or environmental register issues a DIA to anchor a facility operator's DID to a registered mine site or production facility. This allows verifiers to confirm that the operator of a facility — as identified by their DID in a Digital Facility Record — is the legitimate holder of the facility licence. In this example, the Zambia Mining Cadastre anchors the mine operator's DID to its large-scale mining licence.

```json
"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-mine.example.com",
  "registeredName": "Sample Copper Mine",
  "registeredId": "ZM-NW-CU-0012",
  "registeredDate": "2003-09-22",
  "publicInformation": "https://mining-register.gov.zm/facilities/ZM-NW-CU-0012",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://mining-register.gov.zm",
    "name": "Zambia Mining Cadastre"
  },
  "registrar": {
    "id": "https://mining-register.gov.zm",
    "name": "Zambia Ministry of Mines"
  },
  "registerType": "facility",
  "registrationScope": [
    "https://mining-register.gov.zm/LicenceType?Id=large-scale-mining"
  ]
}
```

### Use Case: Trademark Register

A national intellectual property office issues a DIA to anchor a trademark owner's DID to a registered trademark. This allows verifiers to confirm that the entity using a brand name on product passports is the legitimate owner of that trademark. In this example, a national patent and trademark office anchors the battery manufacturer's DID to its registered "VoltCell" trademark under Nice Classification class 9 (batteries and electrical apparatus).

```json
"credentialSubject": {
  "type": ["RegisteredIdentity"],
  "id": "did:web:sample-battery.example.com",
  "registeredName": "VoltCell",
  "registeredId": "302024001234",
  "registeredDate": "2022-03-10",
  "publicInformation": "https://dpma.example.com/trademarks/302024001234",
  "schemeId": {
    "type": ["IdentifierScheme"],
    "id": "https://dpma.example.com",
    "name": "Sample National Trademark Register"
  },
  "registrar": {
    "id": "https://dpma.example.com",
    "name": "Sample Patent and Trademark Office"
  },
  "registerType": "trademark",
  "registrationScope": [
    "https://dpma.example.com/NiceClassification?Id=9"
  ]
}
```

## DIA Discovery

DIA credentials SHOULD be discoverable from either identifier:

- Given a DID (eg as the issuer of a DPP) via DID document `service` endpoint.
- Given a registered identifier (eg a VAT registration number) via the ID scheme resolver service.

### Via DID Service Endpoint

As described in the [W3C Decentralized Identifiers](https://www.w3.org/TR/did-core/) specification, DIDs are resolvable to a DID document. The `service` property of a DID document contains an array of typed `serviceEndpoint` which can point to services or credentials relevant to the DID. A DID document may also contain an "alsoKownAs" property which is typically used to reference other identifiers. Controllers of DIDs that are linked to authoritative register SHOULD

- Include the URI of registered identifier in the `alsoKnownAs` property of the DID document to establish a bidirectional link. In the snippet below `https://sample-register.gov/90664869327` has been added.
- Add proof that the relationship is reciprocal by adding a `service` object that references the DIA credential. In the example below, the DIA credential URL is `https://sample-credential-store.com/credentials/dia-90664869327.json`

```json
{
  "id": "did:method:sample-business.com:123456789",
  "authentication": [{..}],
  ..
  "alsoKnownAs": ["https://sample-register.gov/90664869327"],
  "service": [{
    "id":"did:method:sample-business.com:123456789#90664869327",
    "type":"untp:dia"
    "serviceEndpoint": {
        "href":"https://sample-credential-store.com/credentials/dia-90664869327.json",
        "title":"Digital Identity Anchor",
        "type": "application/vc+jwt"
    }
  }]
}
```

### Via Identity Resolver

As described in the UNTP [Identity Resolver](IdentityResolver.md) specification, existing identity registers are encouraged to make their registered identities _resolvable_ and _verifiable_.

- Identifiers are made _resolvable_ by implementing [ISO-18975](https://www.iso.org/standard/85540.html) to encode IDs as URLs and returning an IETF [rfc-9264](https://datatracker.ietf.org/doc/rfc9264/) link-set with links to relevant further data about the ID.
- Identifiers are made _verifiable_ by issuing DIAs per this specification.

This presents the opportunity to make the DIA discoverable by returning an appropriate link in the link-set. For example, given a VAT registration number `90664869327` issued under scheme `https://sample-register.gov` and applying the scheme resolver template may yield a resolver service URL of `https://resolver.sample-register.gov/vatNumber/90664869327`

The resolver service may be called with parameters that define which link-types to return. `https://resolver.sample-register.gov/vatNumber/90664869327?linkType=all` will return a linkset that SHOULD contain the DIA credential link (among other links such as the registration history) as follows.

```json
{
  "linkset": [
    {
      "anchor": "https://resolver.sample-register.gov/vatNumber/90664869327",
      "untp:dia": [
        {
          "href": "https://sample-credential-store.com/credentials/dia-90664869327.json",
          "title": "Digital Identity Anchor",
          "type": "application/vc+jwt"
        }
      ]
    },
    {
      "anchor": "https://resolver.sample-register.gov/vatNumber/90664869327",
      "about": [
        {
          "href": "https://sample-register.gov/registrationHistory?id=90664869327",
          "title": "Registration History",
          "type": "text/html"
        }
      ]
    }
  ]
}
```

Alternatively, invoking the resolver service with the DIA specific link type `https://resolver.sample-register.gov/vatNumber/90664869327?linkType=untp:digitalIdentityAnchor` would redirect directly to the matching link

```json
   https://sample-credential-store.com/credentials/dia-90664869327.json
```

---

## Digital Product Passport

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

### V0.7.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](pathname:///artefacts/schema/v0.7.0/dpp/DigitalProductPassport.json) | Full credential schema including the W3C VC envelope and Product subject |
| [Product.json](pathname:///artefacts/schema/v0.7.0/dpp/Product.json) | Standalone schema for the Product credential subject |

- **Sample Instances:**

| Sample | Description |
| --- | --- |
| [DigitalProductPassport_instance.json](pathname:///artefacts/samples/v0.7.0/dpp/DigitalProductPassport_instance.json) | Copper concentrate from a sample mine in Zambia |
| [DigitalProductPassport_cathode_instance.json](pathname:///artefacts/samples/v0.7.0/dpp/DigitalProductPassport_cathode_instance.json) | Refined copper cathode from a sample refinery in Japan |
| [DigitalProductPassport_battery_instance.json](pathname:///artefacts/samples/v0.7.0/dpp/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](CoreVocabulary.md), which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published at [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/).

### Sample Credential

| URL | QR | Description |
| --- | --- | --- |
| [Sample Digital Product Passport](https://untp.showthething.com/verify?uri=https%3A%2F%2Funtp-storage.s3.ap-southeast-2.amazonaws.com%2Fde0ef9bd-f1b1-4804-88cb-fadda5b7dd51.json) | ![Sample Digital Product Passport](../assets/images/sample-dpp-qrcode-v0.7.0.jpeg) | A sample digital product passport as a signed Verifiable Credential. The URL (or QR scan) resolves to a hosted verifier that displays a human-readable version. Raw JSON data can be viewed via the `JSON` tab and the full credential can be downloaded via the download button. |

## Overview

The digital product passport (DPP) is issued by the shipper of goods and is the carrier of **product and sustainability information** 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 - such as the scope 3 emissions in a product shipment. 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.

## Conceptual Model

![Digital Product passport conceptual model](../assets/images/dpp-concept.png)

## Requirements

The digital product passport is designed to meet the following detailed requirements as well as the more general [UNTP Requirements](https://untp.unece.org/docs/about/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 (eg UN-CPC). | The `productCategory` array of `Classification` objects |
| 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](IdentityResolver.md) 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](CoreTaxonomies.md) 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](CoreTaxonomies.md) 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](ConformityCredential.md) (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](DigitalTraceabilityEvents.md) (`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` |

## Logical Model

The Digital Product Passport is an assembly of re-usable components from the UNTP core vocabulary.

![Digital Product Passport data model](../assets/images/dpp-model.svg)

The DPP credential wraps a `Product` as its credential subject. The product carries identification (model, batch, or serialised item level), classification, and descriptive information alongside the following key structures:

- **Manufacturing context** — the `Facility` where the product was made, the country of production, and related parties in defined roles.
- **Material provenance** — a breakdown of `Material` composition by origin country, mass fraction, recycled content, and hazardous material indicators.
- **Dimensions and packaging** — physical `Dimension` (weight, length, width, height, volume) for the product and its `Package`, supporting unit-level calculations such as emissions intensity per kilogram.
- **Performance claims** — an array of `Claim` objects, each referencing a `Criterion` from a standard or regulation, classified by `ConformityTopic`, and carrying quantified `Performance` measures classified by `PerformanceMetric`. Claims link to supporting evidence such as conformity credentials.
- **Characteristics** — an open extension point for industry-specific product attributes not covered by the core model.

For detailed class and property definitions, see the [Core Vocabulary](CoreVocabulary.md) 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**.

### Example: EU Battery Passport (DIN DKE SPEC 99100)

The [DIN DKE SPEC 99100](https://www.dinmedia.de/en/technical-rule/din-dke-spec-99100/385692321) is the German standard implementing the EU Battery Regulation (EU 2023/1542) battery passport data requirements. It defines 88 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 |
| --- | --- | --- |
| Direct property | 14 | Identifiers, classification, facility, mass, labels |
| Characteristic | 22 | Battery-specific technical specifications (voltage, capacity, resistance, lifetime, temperature) |
| Performance claim | 21 | Carbon footprint, recycled content, energy efficiency, durability metrics |
| Lifecycle event (DTE) | 19 | Dynamic in-use data (remaining capacity, charge cycles, temperature exposure, negative events) |
| Related document | 12 | Dismantling manuals, due diligence reports, safety measures, end-of-life guidance |
| **Total** | **88** | |

The full attribute-by-attribute mapping is available as a [CSV download](../assets/files/din99100-untp-mapping.csv). The [battery sample credential](pathname:///artefacts/samples/v0.7.0/dpp/DigitalProductPassport_battery_instance.json) demonstrates the static mappings (direct properties, characteristics, performance claims, related documents, and labels) 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](pathname:///artefacts/samples/v0.7.0/dpp/DigitalProductPassport_battery_instance.json).

### Credential Envelope

All DPPs are issued as [W3C Verifiable Credentials (VCDM 2.0)](https://www.w3.org/TR/vc-data-model-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](VerifiableCredentials.md#did-methods), with `issuerAlsoKnownAs` linking to authoritative business register identifiers.

```json
{
  "type": ["DigitalProductPassport", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/"
  ],
  "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](IdentityResolver.md). Classification uses `productCategory` with schemes such as [UN CPC](https://unstats.un.org/unsd/classifications/Econ/cpc).

```json
"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": [
    {
      "code": "46410",
      "name": "Primary cells and primary batteries",
      "schemeId": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
      "schemeName": "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.

```json
"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](https://vocabulary.uncefact.org/UnitMeasureCode). Include only the dimensions relevant to the product.

```json
"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 constituent materials by origin, mass fraction, recycled content, and hazard status. Each `Material` includes a `materialType` classification and an `originCountry`.

```json
"materialProvenance": [
  {
    "name": "Copper cathode",
    "originCountry": { "countryCode": "JP", "countryName": "Japan" },
    "materialType": {
      "code": "41521",
      "name": "Unwrought copper",
      "schemeId": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
      "schemeName": "UN Central Product Classification (CPC)"
    },
    "massFraction": 0.08,
    "mass": { "value": 36, "unit": "KGM" },
    "recycledMassFraction": 0.12,
    "hazardous": false
  }
]
```

### 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.

```json
"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.

```json
"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](CoreTaxonomies.md) and carries quantified performance using a `PerformanceMetric` from the [Performance Metrics taxonomy](CoreTaxonomies.md). Claims can reference applicable regulations and standards, and SHOULD link to independent [conformity assessments](ConformityCredential.md) as `evidence`. Performance can be expressed as a numeric `measure`, a categorical `score`, or both.

```json
"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-metric/battery-carbon-footprint",
          "name": "Battery 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/linkTypes/dcc"
      }
    ],
    "conformityTopic": [
      {
        "type": ["ConformityTopic"],
        "id": "https://vocabulary.uncefact.org/conformity-topic/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](ConformityVocabularyCatalog.md).

---

## Digital Traceability Events

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

A Digital Traceability Event may be implemented in either of two equivalent ways:

1. **UNTP-native** — using the `MakeEvent`, `MoveEvent`, and `ModifyEvent` schemas defined in this specification.
2. **EPCIS Profile** — using [GS1 EPCIS 2.0](https://ref.gs1.org/epcis/) events that conform to the constrained profile in [EPCIS Profile](#epcis-profile) below.

Both paths express the same supply chain semantics, are issued as [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/), and interoperate with the rest of the UNTP credential suite. Implementers without existing EPCIS infrastructure should adopt the UNTP-native schemas; implementers operating an EPCIS 2.0 capture/query interface should follow the EPCIS Profile.

## Artifacts

### V0.7.0 Schema and Samples

The JSON schema and sample credential instances for Digital Traceability Events are maintained in this repository.

- **JSON Schema:**

| Schema | Description |
| --- | --- |
| [DigitalTraceabilityEvent.json](pathname:///artefacts/schema/v0.7.0/dte/DigitalTraceabilityEvent.json) | Full credential schema including the W3C VC envelope and event subjects |
| [MakeEvent.json](pathname:///artefacts/schema/v0.7.0/dte/MakeEvent.json) | Schema for manufacturing events (input products consumed to create output products) |
| [ModifyEvent.json](pathname:///artefacts/schema/v0.7.0/dte/ModifyEvent.json) | Schema for modification events (test, repair, repurpose, or consume a product) |
| [MoveEvent.json](pathname:///artefacts/schema/v0.7.0/dte/MoveEvent.json) | Schema for movement events (ship products between facilities) |

- **Sample Instances:**

| Sample | Description |
| --- | --- |
| [DigitalTraceabilityEvent_instance.json](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_instance.json) | Copper concentrate production at a sample mine in Zambia |
| [DigitalTraceabilityEvent_smelter_make_instance.json](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_smelter_make_instance.json) | Copper cathode smelting at a sample refinery in Japan |
| [DigitalTraceabilityEvent_cathode_move_instance.json](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_cathode_move_instance.json) | Copper cathode shipment from refinery to battery factory |
| [DigitalTraceabilityEvent_battery_make_instance.json](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_battery_make_instance.json) | Battery pack assembly at a sample factory in Germany |

The samples trace the copper-to-battery supply chain through make and move events.

### Vocabulary and Context

The DTE is built on the [UNTP Core Vocabulary](CoreVocabulary.md), which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published at [https://vocabulary.uncefact.org/untp/](https://vocabulary.uncefact.org/untp/).

### Sample Credential

| URL | QR | Description |
| --- | --- | --- |
| [Sample Digital Traceability Event](https://untp.showthething.com/verify?uri=https%3A%2F%2Funtp-storage.s3.ap-southeast-2.amazonaws.com%2F2a7fda44-6a6a-452c-af7e-ae2b2aaf1b24.json) | ![Sample Digital Traceability Event](../assets/images/sample-dte-qrcode-v0.7.0.jpg) | A sample digital traceability event as a signed Verifiable Credential. The URL (or QR scan) resolves to a hosted verifier that displays a human-readable version. Raw JSON data can be viewed via the `JSON` tab and the full credential can be downloaded via the download button. |

## Overview

Digital Traceability Events (DTEs) are lightweight verifiable credentials that record the “what, when, where, who, and how” of product lifecycle activities across a value chain. Any supply chain, regardless of complexity, can be accurately modelled using a combination of three event types. A **make** event records a manufacturing or processing step that consumes input products to create output products at a facility. A **move** event records the shipment of products from one facility to another. A **modify** event records a post-market action on an existing product such as inspection, repair, refurbishment, or recycling. Together, make and move events model the stocks and flows through each facility, enabling facility-level [mass-balance assessment](../design-patterns/MassBalance.md) of sustainability claims. Each DTE is issued as a [W3C Verifiable Credential](https://www.w3.org/TR/vc-data-model-2.0/) so that it can be independently verified and linked to other credentials such as [Digital Product Passports](DigitalProductPassport.md) and [Digital Conformity Credentials](ConformityCredential.md). DTEs are discoverable from [identity resolvers](IdentityResolver.md) using the product identifier, subject to [access control](DecentralisedAccessControl.md) where commercially sensitive data needs protection.

## Conceptual Model

![Traceability events conceptual model](../assets/images/dte-concept.png)

The conceptual model answers six key questions about every lifecycle event:

- **WHAT** — what product lifecycle event happened, including a timestamp and business process category. Any product lifecycle can be constructed from three event types: **Make** (produce output products from input products at a facility), **Modify** (test, repair, repurpose, or consume a product at a facility), and **Move** (ship a quantity of products from source to destination facility).
- **WHICH** — which physical products are impacted by the event, expressed as a list of specific serialised item or batch identifiers, or as a measured quantity of a product class.
- **WHERE** — all events occur at a specific identified facility whose location identifiers must be resolvable to location metadata and geolocation.
- **WHO** — events are created by an identified party, establishing accountability for the recorded information.
- **EVIDENCE** — sensor data such as GPS location, camera images, or physical measurements can be attached to any event, including metadata about the sensor device itself.
- **REFERENCE** — supporting documents such as repair records, shipping manifests, or production records can be attached to the event.

## Requirements

The traceability event is designed to meet the following detailed requirements as well as the more general [UNTP Requirements](https://untp.unece.org/docs/about/Requirements)

| ID | Name | Requirement Statement | Solution Mapping |
| --- | --- | --- | --- |
| TEV-01 | Sub-components | The traceability event MUST provide a mechanism to trace from a DPP representing a product assembly to the individual DPPs of each sub-assembly component part. | [MakeEvent](#make-event) — component parts are `inputProduct` items, the assembled product is the `outputProduct`. |
| TEV-02 | Consumed materials | The traceability event MUST provide a mechanism to trace a manufactured product DPP back to the DPPs representing batches of input materials that are consumed in manufacturing one or more output products. | [MakeEvent](#make-event) — `inputProduct` and `outputProduct` arrays with product identifiers and quantities. |
| TEV-03 | Aggregated bundles | When a DPP represents an aggregated bundle of similar items (e.g. a pallet of cotton bales) then the traceability event MUST provide a means to allocate the aggregate measures to each individual item (i.e. each bale). | [MakeEvent](#make-event) — individual items are `inputProduct` entries, the aggregated bundle is the `outputProduct` (or vice versa for disaggregation). |
| TEV-04 | Transportation | When a product (or consolidated consignment) is shipped from one physical location to another, the traceability event MUST provide a means to record the movement and associate sustainability measures such as transport emissions to the shipped bundle. | [MoveEvent](#move-event) — `movedProduct`, `fromFacility`, `toFacility`, and `consignmentId`. Sensor data can capture transport emissions. |
| TEV-05 | Items or quantities | Traceability events MUST work equally well whether the input or output items are individually serialised items or measured quantities (mass or volume) of a product class. | [EventProduct](#event-products) — `product.idGranularity` distinguishes `item`, `batch`, and `model` level identification; `quantity` provides the measured amount. |
| TEV-06 | IoT sensor data | Traceability events will often be generated by or associated with physical sensor readings. In such cases, the traceability event SHOULD support the association of sensor data with the event. | [SensorData](#sensor-data) — `sensorData` array on `LifecycleEvent` with metric, measure, sensor device, and geo-location. |
| TEV-07 | Time and location | Traceability events MUST always record the timestamp and physical location of the event so that multiple events can be connected in time and space. | [LifecycleEvent](#lifecycle-event) — `eventDate` timestamp; facility references (`madeAtFacility`, `fromFacility`/`toFacility`, `modifiedAtFacility`) provide location. |
| TEV-08 | Product disposition | The traceability event MUST record the state of each product after the event has occurred (e.g. new, consumed, repaired, recycled, disposed) so that product status can be tracked through its lifecycle. | [EventProduct](#event-products) — `disposition` property using the `productStatus` code list. |
| TEV-09 | Activity classification | The traceability event MUST support industry-specific classification of the business activity (e.g. ginning, spinning, weaving in textiles) so that generic event types can carry domain-specific context. | [LifecycleEvent](#lifecycle-event) — `activityType` as a [Classification](CoreVocabulary.md) drawn from a recognised scheme such as the [GS1 CBV Business Step](https://ref.gs1.org/cbv/BizStep) vocabulary. |
| TEV-10 | Related documents | The traceability event SHOULD support links to related credentials and documents such as Digital Product Passports, Digital Conformity Credentials, test results, or shipping manifests. | [Related Documents](#related-documents) — `relatedDocument` array of [Link](CoreVocabulary.md) entries with URL, name, media type, and link type. |
| TEV-11 | Related parties | The traceability event MUST identify the parties involved in the event and their roles (e.g. manufacturer, shipper, receiver) to establish accountability. | [Related Parties](#related-parties) — `relatedParty` array of [PartyRole](CoreVocabulary.md) entries with role and party identification. |
| TEV-12 | Confidentiality | The traceability event SHOULD support access control mechanisms so that commercially sensitive data (particularly input supply sources in make events) can be selectively shared. | [Decentralised Access Control](DecentralisedAccessControl.md) — credentials may be access-restricted using decentralised access control patterns. |
| TEV-13 | Mass-balance support | The traceability event model MUST support facility-level mass-balance accounting so that a facility's claimed outputs can be verified against its documented inputs and inventory. | [MakeEvent](#make-event) and [MoveEvent](#move-event) — together they model stocks and flows through a facility as described in the [Chain of Custody](../design-patterns/MassBalance.md) design pattern. |

## Logical Model

![Data Model](../assets/images/dte-model.svg)

The `DigitalTraceabilityEvent` is a W3C Verifiable Credential whose `credentialSubject` contains one or more `LifecycleEvent` instances. The abstract [LifecycleEvent](CoreVocabulary.md) base class defines the common properties shared by all event types: an identifier, event date, activity type classification, related parties, sensor data, and related documents. Three concrete event types extend `LifecycleEvent`:

- **[MakeEvent](CoreVocabulary.md)** — represents a manufacturing or processing step that consumes `inputProduct` items to create `outputProduct` items at a `madeAtFacility`. This is the most important event type for supply chain traceability because it links output product DPPs back to their input material DPPs.
- **[MoveEvent](CoreVocabulary.md)** — represents the shipment of `movedProduct` items from a `fromFacility` to a `toFacility`, optionally referencing a `consignmentId`. Move events connect the physical locations along a supply chain.
- **[ModifyEvent](CoreVocabulary.md)** — represents an action on a `modifiedProduct` at a `modifiedAtFacility`, such as testing, repair, repurposing, or consumption.

Each event references products via [EventProduct](CoreVocabulary.md) (linking a [Product](CoreVocabulary.md) with an optional quantity and disposition), facilities via [Facility](CoreVocabulary.md), and parties via [PartyRole](CoreVocabulary.md). IoT sensor readings are captured as [SensorData](CoreVocabulary.md) and supporting documents as [Link](CoreVocabulary.md). Activity types are classified using [Classification](CoreVocabulary.md).

## Implementation Guidance

### Simplified Event Model

The UNTP make, move, and modify lifecycle events are a deliberately simplified set of event types intended to be sufficient for product lifecycle needs across any industry:

- **Make** and **Move** events are primarily targeted at facility-level mass-balance assessment as described in the [Chain of Custody](../design-patterns/MassBalance.md) design pattern. They work by modelling stocks and flows through a facility — make events record inputs consumed and outputs produced, while move events record products entering or leaving a facility. Together, they enable verifiable material accounting: confirming that a facility's claimed outputs are consistent with its documented inputs and inventory.
- **Modify** events are largely targeted at post-market-entry actions such as repair, refurbishment, observation, testing, and recycling — actions that change a product's state but retain its identity.

### Activity Type Classification

The event-level `activityType` classification is designed to provide industry-specific context to the event. While the UNTP event model is generic (make, move, modify), the `activityType` drawn from a recognised classification scheme allows implementers to express domain-specific processes. For example, a textile supply chain might use activity types such as ginning, spinning, weaving, and dyeing to distinguish different manufacturing steps, all of which are structurally `MakeEvent` instances.

### Discoverability

Like all UNTP credential types, DTEs are discoverable from link resolvers using the product identifier — subject to confidentiality constraints. When a product's DPP is resolved via its identifier, the associated traceability events can also be discovered, enabling downstream actors to traverse the supply chain graph.

### Supporting Evidence

Sensor data and related documents associated with any lifecycle event provide additional information and evidence to support the event. For example, a move event might include GPS tracking data from a transport sensor, or a modify event might link to a test result document. These attachments strengthen the evidentiary basis of the event without changing its core structure.

### Confidentiality

The data in lifecycle events — particularly make events, which reveal input supply sources for output products — may be considered commercially sensitive. Implementers may choose to restrict access to these credentials following the [Decentralised Access Control](DecentralisedAccessControl.md) guidance, which allows credential holders to grant selective access to specific parties rather than publishing events openly.

## The components of a DTE

This section walks through each component of a Digital Traceability Event credential using snippets from the [sample instances](pathname:///artefacts/samples/v0.7.0/dte). The samples trace the copper-to-battery supply chain: copper concentrate is shipped from a mine in Zambia to a refinery in Japan, smelted into copper cathode, shipped to a battery factory in Germany, and assembled into a battery pack.

### Credential Envelope

A DTE is issued as a W3C Verifiable Credential. The outer envelope identifies the credential, its issuer, and its validity period. The `credentialSubject` array contains one or more lifecycle events. This example is from the [smelter make event](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_smelter_make_instance.json).

```json
{
  "type": ["DigitalTraceabilityEvent", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/"
  ],
  "id": "https://credentials.sample-refinery.example.com/dte/make-cathode-2025-0305",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd",
    "issuerAlsoKnownAs": [...]
  },
  "validFrom": "2025-03-05T00:00:00Z",
  "validUntil": "2026-03-05T00:00:00Z",
  "name": "Smelting of Copper Concentrate into Copper Cathode — Sample",
  "credentialSubject": [...]
}
```

Please refer to [DPP VC Guidance](DigitalProductPassport.md#credential-envelope) for more detail about the use of the W3C verifiable credentials data model for UNTP.

### Lifecycle Event

All three event types extend the abstract `LifecycleEvent` and share a common set of properties that record what happened, when, and who was involved. This example shows the common properties from the smelter make event.

```json
{
  "type": ["MakeEvent", "LifecycleEvent"],
  "id": "https://sample-refinery.example.com/events/make-cathode-2025-0305",
  "name": "Copper smelting and electrolytic refining batch",
  "description": "Processing of 30 tonnes of copper concentrate ...",
  "eventDate": "2025-03-05T06:00:00Z",
  "activityType": {
    "code": "commissioning",
    "name": "Commissioning",
    "definition": "The process of manufacturing or assembling a product ...",
    "schemeId": "https://ref.gs1.org/cbv/BizStep",
    "schemeName": "GS1 CBV Business Step"
  },
  "relatedParty": [...],
  "relatedDocument": [...]
}
```

- **`id`** — a unique URI for this specific event instance.
- **`eventDate`** — the timestamp when the event occurred.
- **`activityType`** — a [Classification](CoreVocabulary.md) drawn from a recognised scheme such as the [GS1 CBV Business Step](https://ref.gs1.org/cbv/BizStep) vocabulary.
- **`relatedParty`** — the parties involved in the event and their roles (see [Related Parties](#related-parties) below).
- **`relatedDocument`** — links to supporting credentials or documents (see [Related Documents](#related-documents) below).

### Sensor Data

The optional `sensorData` array on any lifecycle event captures IoT sensor readings associated with the event — for example temperature during transport, GPS coordinates of a shipment, or camera images at an inspection point. Each [SensorData](CoreVocabulary.md) entry identifies the metric being measured, the sensor device, and one or more readings.

```json
"sensorData": [
  {
    "type": ["SensorData"],
    "metric": {
      "id": "https://vocabulary.uncefact.org/untp/metrics#temperature",
      "name": "Ambient Temperature"
    },
    "measure": [
      { "value": 22.5, "unit": "CEL" },
      { "value": 23.1, "unit": "CEL" }
    ],
    "sensor": {
      "id": "https://sensors.sample-refinery.example.com/temp-401",
      "name": "Furnace outlet thermocouple T-401"
    },
    "geoLocation": {
      "latitude": 35.6762,
      "longitude": 139.6503
    }
  }
]
```

- **`metric`** — identifies the type of measurement (e.g. temperature, humidity, weight) using a [PerformanceMetric](CoreVocabulary.md) reference.
- **`measure`** — one or more [Measure](CoreVocabulary.md) values with a numeric value and UN/CEFACT unit code.
- **`sensor`** — the device that captured the reading, identified by URI and name.
- **`geoLocation`** — optional GPS coordinates of the sensor at the time of the reading.
- **`rawData`** — optional links to raw data files such as images or instrument output.

### Make Event

A `MakeEvent` represents a manufacturing or processing step that consumes input products to create output products at a facility. This is the most important event type for supply chain traceability because it links output product DPPs back to their input material DPPs. This example shows the smelting of copper concentrate into copper cathode at the [Sample Copper Refinery](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_smelter_make_instance.json).

```json
{
  "type": ["MakeEvent", "LifecycleEvent"],
  "id": "https://sample-refinery.example.com/events/make-cathode-2025-0305",
  "eventDate": "2025-03-05T06:00:00Z",
  "inputProduct": [
    {
      "product": {
        "id": "https://id.sample-mine.example.com/product/cu-conc-2025",
        "name": "Copper Concentrate (Cu 30%)",
        "batchNumber": "2025-Q1-4501",
        "idGranularity": "model"
      },
      "quantity": { "value": 30000, "unit": "KGM" },
      "disposition": "consumed"
    }
  ],
  "outputProduct": [
    {
      "product": {
        "id": "https://id.sample-refinery.example.com/product/cu-cathode-2025",
        "name": "LME Grade A Copper Cathode",
        "batchNumber": "2025-Q1-0812",
        "idGranularity": "model"
      },
      "quantity": { "value": 10000, "unit": "KGM" },
      "disposition": "new"
    }
  ],
  "madeAtFacility": {
    "id": "https://facility-register.example.com/fac-002",
    "name": "Sample Copper Refinery",
    "registeredId": "fac-002"
  }
}
```

- **`inputProduct`** — the products consumed in this manufacturing step, each as an [EventProduct](CoreVocabulary.md) with a product identifier, quantity, and disposition (typically `consumed`).
- **`outputProduct`** — the products created, with disposition typically `new`.
- **`madeAtFacility`** — the [Facility](CoreVocabulary.md) where manufacturing took place.

### Move Event

A `MoveEvent` represents the shipment of products from one facility to another. This example shows the shipment of copper cathode from the refinery in Japan to the [battery factory in Germany](pathname:///artefacts/samples/v0.7.0/dte/DigitalTraceabilityEvent_cathode_move_instance.json).

```json
{
  "type": ["MoveEvent", "LifecycleEvent"],
  "id": "https://sample-refinery.example.com/events/move-cathode-2025-0310",
  "eventDate": "2025-03-10T14:00:00Z",
  "movedProduct": [
    {
      "product": {
        "id": "https://id.sample-refinery.example.com/product/cu-cathode-2025",
        "name": "LME Grade A Copper Cathode",
        "batchNumber": "2025-Q1-0812",
        "idGranularity": "model"
      },
      "quantity": { "value": 2000, "unit": "KGM" },
      "disposition": "in_transit"
    }
  ],
  "fromFacility": {
    "id": "https://facility-register.example.com/fac-002",
    "name": "Sample Copper Refinery",
    "registeredId": "fac-002"
  },
  "toFacility": {
    "id": "https://facility-register.example.com/fac-003",
    "name": "Sample Battery Factory",
    "registeredId": "fac-003"
  },
  "consignmentId": "urn:carrier:sea-freight:BL-2025-SG-BG-0310"
}
```

- **`movedProduct`** — the products being shipped, with disposition typically `in_transit`.
- **`fromFacility`** and **`toFacility`** — the origin and destination [Facility](CoreVocabulary.md) for the shipment.
- **`consignmentId`** — an optional URI identifying the transport consignment (e.g. a bill of lading number).

### Modify Event

A `ModifyEvent` represents an action performed on a product at a facility — such as testing, repair, repurposing, or consumption — where the product identity is retained but its state changes. The current sample supply chain does not include a modify event, but a typical example would be a quality inspection of a battery pack.

```json
{
  "type": ["ModifyEvent", "LifecycleEvent"],
  "id": "https://sample-battery.example.com/events/inspect-battery-2025-0402",
  "eventDate": "2025-04-02T10:00:00Z",
  "activityType": {
    "code": "inspecting",
    "name": "Inspecting",
    "schemeId": "https://ref.gs1.org/cbv/BizStep",
    "schemeName": "GS1 CBV Business Step"
  },
  "modifiedProduct": [
    {
      "product": {
        "id": "https://id.sample-battery.example.com/product/bat-75kwh-2025",
        "name": "75 kWh Li-ion Battery Pack",
        "itemNumber": "BAT-75-2025-00471",
        "idGranularity": "item"
      },
      "disposition": "active"
    }
  ],
  "modifiedAtFacility": {
    "id": "https://facility-register.example.com/fac-003",
    "name": "Sample Battery Factory",
    "registeredId": "fac-003"
  }
}
```

- **`modifiedProduct`** — the products acted upon, with disposition reflecting the outcome (e.g. `active` after a successful inspection).
- **`modifiedAtFacility`** — the [Facility](CoreVocabulary.md) where the action took place.

### Event Products

Each event references products via the [EventProduct](CoreVocabulary.md) structure, which pairs a [Product](CoreVocabulary.md) identifier with an optional quantity and a disposition code indicating the product's status. Products can be identified at different levels of granularity — by `modelNumber` (product class), `batchNumber` (production batch), or `itemNumber` (individual serialised item).

```json
{
  "product": {
    "id": "https://id.sample-battery.example.com/product/bat-75kwh-2025",
    "name": "75 kWh Li-ion Battery Pack",
    "modelNumber": "BAT-NMC811-75",
    "batchNumber": "2025-SZG-0342",
    "itemNumber": "BAT-75-2025-00471",
    "idGranularity": "item"
  },
  "quantity": { "value": 450, "unit": "KGM" },
  "disposition": "new"
}
```

### Related Parties

The `relatedParty` array identifies the parties involved in an event and their roles. Move events typically have `shipper` and `receiver` roles; make events typically have a `manufacturer` role.

```json
"relatedParty": [
  {
    "role": "shipper",
    "party": {
      "type": ["Party"],
      "id": "did:web:sample-refinery.example.com",
      "name": "Sample Copper Refinery Co. Ltd",
      "registeredId": "REF-001",
      "idScheme": {
        "id": "https://www.sample-register.example.com",
        "name": "Japan Corporate Number (Houjin Bangou)"
      }
    }
  },
  {
    "role": "receiver",
    "party": {
      "type": ["Party"],
      "id": "did:web:sample-battery.example.com",
      "name": "Sample Battery Mfg GmbH",
      "registeredId": "BAT-001"
    }
  }
]
```

### Related Documents

The `relatedDocument` array links the event to supporting credentials or documents. Typical links include the Digital Product Passport for the output product and any relevant Digital Conformity Credentials.

```json
"relatedDocument": [
  {
    "linkURL": "https://credentials.sample-refinery.example.com/dpp/cu-cathode-2025",
    "linkName": "Digital Product Passport — LME Grade A Copper Cathode",
    "mediaType": "application/ld+json",
    "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dpp"
  },
  {
    "linkURL": "https://credentials.sample-cab.example.com/dcc/smelter-002",
    "linkName": "Coppermark Certification — Sample Copper Refinery",
    "mediaType": "application/ld+json",
    "linkType": "https://test.uncefact.org/vocabulary/linkTypes/dcc"
  }
]
```

## EPCIS Profile

[GS1 EPCIS 2.0](https://ref.gs1.org/epcis/) is a mature, widely deployed standard for capturing supply chain events as JSON-LD. This profile defines the constrained EPCIS usage that satisfies UNTP Digital Traceability Event requirements. Events that conform to this profile carry the same semantics as UNTP-native DTEs and can be wrapped as W3C Verifiable Credentials for inclusion in the UNTP credential graph.

The profile follows established practice in industry traceability programmes that map sector-specific tracking events onto EPCIS event types — extending the [GS1 Core Business Vocabulary (CBV)](https://ref.gs1.org/cbv/) with industry-namespaced `bizStep` URIs where the standard CBV vocabulary does not cover the activity.

### Event Type Mapping

| UNTP Event | EPCIS Event | EPCIS `action` | Typical `bizStep` | Typical `disposition` |
| --- | --- | --- | --- | --- |
| `MakeEvent` (transformation) | `TransformationEvent` | — | `commissioning`, `assembling`, `creating_class_instance` | `active` |
| `MakeEvent` (pure aggregation/disaggregation) | `AggregationEvent` | `ADD` / `DELETE` | `packing`, `unpacking` | `active`, `inactive` |
| `MoveEvent` | `ObjectEvent` | `OBSERVE` | `shipping`, `receiving`, `arriving`, `transporting` | `in_transit` |
| `ModifyEvent` | `ObjectEvent` | `OBSERVE` (or `ADD` for repair re-commissioning) | `inspecting`, `repairing`, `sampling`, `decommissioning`, `destroying` | `conformant`, `non_conformant`, `available`, `damaged`, `disposed` |

`bizStep` and `disposition` values are URIs from the CBV (e.g. `https://ref.gs1.org/cbv/BizStep-shipping`). Industry-specific activities not present in CBV are expressed as extension URIs in a sector namespace (for example `urn:gdst:bizstep:fishingEvent` in the seafood sector), following the EPCIS extension mechanism. Equivalent UNTP `activityType` classifications use the same URI as the `bizStep` so that round-tripping preserves the activity context.

### Property Mapping

| UNTP property | EPCIS property | Notes |
| --- | --- | --- |
| `id` | `eventID` | Unique event URI |
| `eventDate` | `eventTime` (+ `eventTimeZoneOffset`) | ISO 8601 timestamp |
| `activityType` | `bizStep` | CBV URI or sector-specific extension |
| `inputProduct` (Make) | `inputEPCList` and/or `inputQuantityList` | Instance vs class-level |
| `outputProduct` (Make) | `outputEPCList` and/or `outputQuantityList` | Instance vs class-level |
| `movedProduct` / `modifiedProduct` | `epcList` and/or `quantityList` | Instance vs class-level |
| `madeAtFacility` / `modifiedAtFacility` | `bizLocation` | Facility URI |
| `fromFacility` (Move) | `readPoint` and `sourceList[type=SDT-location]` | |
| `toFacility` (Move) | `destinationList[type=SDT-location]` | |
| `relatedParty[role=shipper]` | `sourceList[type=SDT-possessing_party]` | |
| `relatedParty[role=receiver]` | `destinationList[type=SDT-possessing_party]` | |
| `consignmentId` (Move) | `bizTransactionList[type=BTT-bol]` | Bill of lading reference |
| `relatedDocument` | `bizTransactionList` | DPP and DCC links use `BTT-cert`; test results `BTT-testres`; production orders `BTT-prodorder` |
| `sensorData` | `sensorElementList` | `sensorMetadata` for the device, `sensorReport[]` for measurements with `type`, `value`, `uom` |
| `disposition` (per product) | `disposition` (per event) | See [Disposition Semantics](#disposition-semantics) below |

### Identifiers

EPCIS requires URI-form identifiers. Two equally valid patterns are supported under this profile:

- **GS1 EPC URIs** — preferred where the implementer holds GS1 prefixes. Use `sgtin` for serialised items, `lgtin` for batches, `sgln` for facilities, `pgln` for parties.
- **HTTPS URLs or UUID URNs** — for implementers without GS1 prefixes. Any resolvable URL or UUID may serve as the identifier prefix, provided it is globally unique and stable.

| Object | GS1 example | Non-GS1 example |
| --- | --- | --- |
| Serialised item | `urn:epc:id:sgtin:0614141.107346.2025001` | `https://id.example.com/product/cu-cathode-2025/item/00471` |
| Batch | `urn:epc:class:lgtin:0614141.107346.2025-Q1` | `https://id.example.com/product/cu-cathode-2025/batch/Q1-0812` |
| Facility | `urn:epc:id:sgln:0614141.12345.0` | `https://facility-register.example.com/fac-002` |
| Party | `urn:epc:id:pgln:0614141.00440.0` | `did:web:sample-refinery.example.com` |

The two styles MAY be mixed within a single event — for example a non-GS1 product URI alongside a GS1 facility GLN.

### Disposition Semantics

UNTP records `disposition` per `EventProduct` (using the [productStatus](CoreVocabulary.md) code list). EPCIS records `disposition` once per event (using the CBV `Disp-*` URIs). The two are reconciled as follows:

- A **MakeEvent** maps cleanly: input products are implicitly consumed by the EPCIS `TransformationEvent`, so only the output disposition is set at the event level.
- A **MoveEvent** typically carries all products in the same `in_transit` state, matching the event-level disposition naturally.
- A **ModifyEvent** whose products carry different dispositions MUST be split into one EPCIS `ObjectEvent` per disposition.

UNTP `productStatus` to CBV `disposition` mapping:

| UNTP | CBV | CBV URI |
| --- | --- | --- |
| `new` | `active` | `https://ref.gs1.org/cbv/Disp-active` |
| `consumed` | *(implicit in `TransformationEvent`)* | — |
| `repaired` | `available` | `https://ref.gs1.org/cbv/Disp-available` |
| `recycled` | `active` | `https://ref.gs1.org/cbv/Disp-active` |
| `disposed` | `disposed` | `https://ref.gs1.org/cbv/Disp-disposed` |

EPCIS implementers MAY use additional CBV dispositions (`conformant`, `non_conformant`, `damaged`, `destroyed`, `recalled`, `expired`, `returned`, `inactive`, `container_closed`) for finer-grained semantics; when round-tripping to UNTP, map back to the closest `productStatus` value.

### Verifiable Credential Wrapping

UNTP requires every traceability event to be issued as a W3C Verifiable Credential. An EPCIS event is wrapped by placing it as the `credentialSubject` of a VC envelope. The example below shows the [smelter make event](#make-event) expressed as an EPCIS `TransformationEvent`:

```json
{
  "type": ["DigitalTraceabilityEvent", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://ref.gs1.org/epcis/"
  ],
  "id": "https://credentials.sample-refinery.example.com/dte/make-cathode-2025-0305",
  "issuer": {
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd"
  },
  "validFrom": "2025-03-05T00:00:00Z",
  "credentialSubject": {
    "type": "TransformationEvent",
    "eventTime": "2025-03-05T06:00:00Z",
    "eventTimeZoneOffset": "+09:00",
    "bizStep": "https://ref.gs1.org/cbv/BizStep-commissioning",
    "disposition": "https://ref.gs1.org/cbv/Disp-active",
    "bizLocation": { "id": "https://facility-register.example.com/fac-002" },
    "inputQuantityList": [
      {
        "epcClass": "https://id.sample-mine.example.com/product/cu-conc-2025",
        "quantity": 30000,
        "uom": "KGM"
      }
    ],
    "outputQuantityList": [
      {
        "epcClass": "https://id.sample-refinery.example.com/product/cu-cathode-2025",
        "quantity": 10000,
        "uom": "KGM"
      }
    ],
    "bizTransactionList": [
      {
        "type": "https://ref.gs1.org/cbv/BTT-cert",
        "bizTransaction": "https://credentials.sample-refinery.example.com/dpp/cu-cathode-2025"
      }
    ]
  }
}
```

Both this credential and the equivalent [UNTP-native make event](#make-event) reference the same product, facility, and linked DPP identifiers, and convey the same supply chain semantics.

---

## Identity Resolver

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Artifacts

### Linkset Schema

The UNTP linkset schema defines the structure of linkset responses returned by identity resolvers. It is aligned with and extends the [GS1 resolver linkset schema](https://ref.gs1.org/standards/resolver/1.2.0/linkset-schema) which implements [RFC 9264](https://datatracker.ietf.org/doc/rfc9264/). A UNTP linkset that omits the UNTP extension properties (`rel`, `method`, `encryptionMethod`, `accessRole`) will also validate against the GS1 schema.

| Artifact | Link | See also |
| -------- | ---- | -------- |
| Linkset JSON Schema | [LinksetSchema.json](/artefacts/schema/v0.7.0/idr/LinksetSchema.json) | [GS1 linkset-schema](https://ref.gs1.org/standards/resolver/1.2.0/linkset-schema) |
| IDR API Specification (OpenAPI) | [idr-api.json](/artefacts/schema/v0.7.0/idr/idr-api.json) | |
| IDR API Documentation | idr-api.html | |

### Link Relations

The following link relation types are submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry [[RFC8288](https://datatracker.ietf.org/doc/html/rfc8288)].

| Relation | Description | Reference | See also |
| -------- | ----------- | --------- | -------- |
| `dpp` | A link from a context URI that identifies a product to its **digital product passport** | [IdentityResolver#lr-dpp](https://untp.unece.org/docs/specification/IdentityResolver#lr-dpp) | [GS1 dpp](https://ref.gs1.org/voc/dpp) |
| `dcc` | A link from a context URI that identifies a product, manufacturer or facility to an applicable **digital conformance credential** | [IdentityResolver#lr-dcc](https://untp.unece.org/docs/specification/IdentityResolver#lr-dcc) | |
| `dfr` | A link from a context URI that identifies a facility to an applicable **digital facility record** | [IdentityResolver#lr-dfr](https://untp.unece.org/docs/specification/IdentityResolver#lr-dfr) | |

## Overview

Supply chains rely on many types of identifiers for **businesses**, **locations**, and **products** of which each are governed by distinct schemas. These identifiers are essential for maintaining integrity and trust by enabling systems to trace, verify, and link data about physical or digital entities.

UNTP does not attempt to replace these existing identifier systems. Instead, it builds upon them by allowing high-integrity registries and sector-specific schemas to be reused while also supporting self-issued identifiers under the control of the entity itself.

To accommodate this variety, UNTP implementations work with two broad **classes of identifiers**

* **Registry-managed identifiers** are issued or recognized by an authoritative register (e.g., national business registry, product catalogue, or sector-specific scheme). The register defines the rules for identifier issuance and for authorizing identifier usage and management. Implementations can therefore rely on the register as the authoritative source for discovery and verification.

* **Self-assigned identifiers** created and controlled by the entity itself. In UNTP this is achieved with [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DIDs), where the controller publishes the resolver information directly via DID Documents. The [DID method](VerifiableCredentials.md#did-methods) specifies how identifiers are created, updated, and revoked. The DID Document exposes service endpoints that behave like link-sets and contains cryptographic material that supports proof of control.

| Characteristic   | Registry-managed                             | Self-assigned identifiers                 |
| ---------------- | -------------------------------------------- | ----------------------------------------- |
| **Issuance**     | Assigned by an authority or registry         | Created and controlled by the entity      |
| **Governance**   | Central registry or scheme operator          | Decentralized, method-specific rules      |
| **Discovery**    | Resolver templates from the registry         | DID resolution via DID methods            |
| **Resolution**   | Scanner/system maps ID to resolver URL using scheme rules (registry templates, ISO/IEC 18975) | DID string is resolved per DID method, returns DID Document |
| **Verification** | Trust anchored in the registry (issuance + authorization rules) | Trust anchored in cryptographic keys inside the DID Document |
| **Use cases**    | Leverages existing schemes, interoperability | Autonomy, no reliance on central registry |

The Identity Resolver (IDR) defines how both classes can participate in a consistent discovery and verification workflow.

## Conceptual Model

Regardless of identifier class, the UNTP applies a shared workflow:

> *"Given an ID of a thing, I can find verifiable data about that thing."*

![Identity Resolver Overview](../assets/images/idr-IdentityResolverOverview.png)

This workflow is described in terms of **Discover-Resolve-Verify (D-R-V)**

* Registry-managed identifiers delegate resolution rules to the registry, which may be governed or audited by a third party.
* Self-issued identifiers (DIDs) embed resolution logic within the DID method and DID Document, giving the controller direct control but also the responsibility to ensure availability.

Implementors should select the approach that best fits their governance model, subject to existing identification schemas and identity resolver capabilities for their sector or geography.

To fulfill the D–R–V workflow, all identifiers in UNTP MUST support four essential features. Where an existing scheme lacks one or more, UNTP provides a framework to uplift it:

* **Unique** - no risk of collision across schemas. See [Identifier Representation](#identifier-representation) for identifier representation conventions.
* **Discoverable** — retrievable as structured data in documents, or machine-readable (barcode, QR, RFID). See the implementation guidance for [Registry-Managed](#implementation-guidance-registry-managed-identifiers) and [Self-Issued](#implementation-guidance-self-issued-identifiers-dids) identifiers.
* **Resolvable** — dereferencing an identifier to obtain structured data. See [Resolution and Linksets](#resolution-and-linksets) for the shared resolution model.
* **Verifiable** — claims made by the identifier's controller can be distinguished from third-party statements. See [Verification](#verification) for verification processes.

## Requirements

This section defines the formal requirement statements for Identity Resolver implementations.

* **Scheme** means an identifier scheme such as a national business identifier scheme.
* **Carrier** means a machine readable device such as a barcode, QR code, RAIN or NFC tag that encodes an identifier issued under a scheme.
* **Link** means a URL that points to a page or document or credential that contains further information related to the identifier.
* **Target** means the document or credential that the link references.
* **link-set** means a collection of links with meta-data that describe each link.
* **Resolver** means an implementation of this specification that returns a link-set about a given identifier.

| ID     | Short name                      | Requirement                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | Solution Mapping                                                                                                                         |
| ------ | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| IDR-01 | Global uniqueness               | All identifiers, whether for products, assets, facilities, or businesses used in UNTP credentials MUST be globally unique so that they can be unambiguously referenced and resolved.                                                                                                                                                                                                                                                                                                                                                                              | [Identifier Representation](#identifier-representation)                                                                                  |
| IDR-02 | One carrier, many links         | One data carrier on a physical product or asset MUST be able to reference any amount of linked data or documents so that user or system confusion from multiple carriers on products can be avoided                                                                                                                                                                                                                                                                                                                                                               | [Linkset Format](#linkset-format)                                                                                                        |
| IDR-03 | Leverage existing schemes       | Existing identifier schemes MUST be usable for UNTP IDR functions so that existing investments can be leveraged and UNTP rollout can be accelerated because there is no need to re-tool existing identifier infrastructure.                                                                                                                                                                                                                                                                                                                                       | This specification supports any identifier scheme.                                                                                       |
| IDR-04 | Leverage existing carriers      | Existing data carriers, whether 1D barcodes on products or RFID tags on livestock are entrenched and unlikely to change quickly. Therefore identity resolvers MUST be able to work with existing carriers so that digitalisation can proceed at pace without the need to re-tool existing physical scanning infrastructure.                                                                                                                                                                                                                                       | [Data Carriers](#data-carriers)                                                                                                          |
| IDR-05 | Seamless transition to 2D       | As industry transitions from 1D barcodes to 2D/QR codes, the UNTP identity resolver process MUST work equally well with either so that implementers can transition at their own pace                                                                                                                                                                                                                                                                                                                                                                              | [Mapping Carriers to URIs](#mapping-carriers-to-uris) - either create a resolver query from a 1D barcode / 2D matrix or embed the query into a QR. |
| IDR-06 | Understanding link-sets         | When a link-set is returned by a resolver, each link MUST include sufficient meta-data so that user systems can understand the purpose and usage of each link as well as the relationship between links                                                                                                                                                                                                                                                                                                                                                           | [Linkset Format](#linkset-format)                                                                                                        |
| IDR-07 | Filtering link-sets             | Resolvers MUST allow users to request specific links, all links, or (if unspecified) then receive a default link - so that user experience can be optimised.                                                                                                                                                                                                                                                                                                                                                                                                      | [IDR Query URL](#idr-query-url)                                                                                                          |
| IDR-08 | Responsive links                | Resolvers SHOULD leverage available user information such as language preferences to return tailored link-sets and default links - so that user experience is optimised.                                                                                                                                                                                                                                                                                                                                                                                          | [Defaults](#defaults) and [Automatically returning the right language](#automatically-returning-the-right-language)                      |
| IDR-09 | Logical grouping of links       | Link-set meta-data SHOULD provide an ability to group related link targets such as a product passport and related traceability events - so that user experience can be optimised.                                                                                                                                                                                                                                                                                                                                                                                 |                                                                                                                                          |
| IDR-10 | Versioning of link targets      | When multiple version of link targets exist (eg multiple version of a product passport) then resolvers MUST include version information in link metadata and MUST ensure that any defaults reference the latest version - so that users receive current information and can audit historical data                                                                                                                                                                                                                                                                 | [Versioned targets](#versioned-targets)                                                                                                  |
| IDR-11 | Resolver redirection            | Resolvers SHOULD, where available, include links that reference secondary resolvers so that product/facility owners can maintain additional document and credential links in their own resolvers. A typical example is the case where a global scheme maintains identifiers only at product class level but the manufacturer manages identifiers and related data at serialised item level. In such cases the primary resolver would say "here's what I know about the product and here's a link to another resolver that can tell you about the serialised item" | [Secondary resolvers](#secondary-resolvers)                                                                                              |
| IDR-12 | Self-issued product identifiers | This specification MUST support self-issued identifiers so long as they are equally discoverable, resolvable, and verifiable - so that each value chain actor is free to make their own choice between third party product registers and self-managed product registers without any lock-in.                                                                                                                                                                                                                                                                      | [DID Documents as Resolvers](#did-documents-as-resolvers) and [DID Discovery](#did-discovery)                                            |
| IDR-13 | Existing standards              | This specification SHOULD use existing standards such as [ISO/IEC 18975](https://www.iso.org/standard/85540.html) and [IETF RFC 9264](https://www.rfc-editor.org/rfc/rfc9264.html) so that implementers can maximise re-use of existing infrastructure and maintain interoperability.                                                                                                                                                                                                                                                                             | ISO/IEC 18975 is the basis for mapping an ID to a query. IETF RFC 9264 is the bases for the structure of the linkset response.           |
| IDR-14 | Domain sovereignty awareness    | Implementers MUST recognize that domain owners have complete authority over their URI space (IETF BCP 190). Clients MUST validate actual content after dereferencing and MUST NOT assume URL patterns guarantee specific services or content types. Resolver operators SHOULD declare services via `/.well-known/resolver` per ISO/IEC 18975.                                                                                                                                                                                                                     | [Domain Sovereignty](#domain-sovereignty)                                                                                                |

## Identifier Representation

Linked data architectures, of which UNTP is an example, depend on unique and consistent identifiers of entities such as products and facilities so that they can be matched across different credentials. For this reason [URIs](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) are heavily used as identifiers of entities throughout UNTP credential types. But without consistency in the way globally unique identifiers are constructed, there is a high risk that valuable links are not made. For example, consider the same product identified in two credentials:

* A digital product passport issued by a manufacturer with a sustainability claim about product `http://product.sample-register.example/123456789`
* A digital conformity credential with a third party sustainability assessment about product `urn:example:sample-register:product:123456789`

Although these are the same product, the construction of the ID is different and so a validation that attempts to confirm that a product passport claim is genuinely supported by third party assessment may fail.

There are thousands of identifier schemes in active use around the world and only a few have well defined conventions for consistent representation of their identifiers as globally unique URIs. To address these challenges, in this section, we define conventions for the consistent representation of identifiers that can be leveraged by any existing or new identifier scheme, whether the identifiers are managed by an issuing authority or self-managed.

These conventions support the [D-R-V workflow](#conceptual-model) by ensuring identifiers can be consistently discovered, resolved, and verified across different schemes.

### Uniform Resource Name (URN)

[URNs](https://en.wikipedia.org/wiki/Uniform_Resource_Name) are a type of URI that are designed to be used as globally unique and persistent identifiers that remain available long after a specific resource that they identify ceases to exist or becomes unavailable. URNs MAY be used for any identifier and SHOULD be used as persistent identifiers for long lived entities such as organisations, facilities and long-lived products.

In patterns below:

* `{identifier-scheme}` is any string of characters permitted in URN Namespace Specific Scheme (alphanumeric characters, hyphen, period, underscore, colon).
* `{identifier-value}` is the string of characters after the last colon (limited to alphanumeric characters, hyphen, period, underscore).

#### For existing IANA registered URN namespaces

Use your IANA registered [URN namespace](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml).

* pattern: `urn:{ns}:{identifier-scheme}:{identifier-value}`

#### For all other schemes

Either register your own scheme with IANA or use the UN global trust register `gtr` URN namespace (IANA registration pending).

* pattern: `urn:gtr:{identifier-scheme}:{identifier-value}` where `gtr` represents the UN global trust register namespace.
* examples:
  * `urn:gtr:register.business.gov.xx:90664869327` - representing any typical national business registration number
  * `urn:gtr:nlis.com.au:QDBH0132XBS01234` - representing an Australian livestock identifier

The `gtr` namespace represents identifier schemes that are listed in the UN global trust register (GTR). When the `gtr` namespace is used, the `{identifier-scheme}` MUST be a DNS domain name comprising URN allowed or percent-encoded characters (i.e. no `/` unless encoded as `%2F`).

### Uniform Resource Locator (URL)

[URLs](https://en.wikipedia.org/wiki/URL) are a type of URI that represent addressable web locations. URLs as identifiers have the advantage that they are immediately resolvable but the disadvantage that they may become dead/broken links whenever a document is moved or a web site is restructured or a domain name changes.

#### IDR URLs as identifiers

When URLs are used as identifiers in UNTP credentials they SHOULD be Identity Resolver URLs that conform to the ISO/IEC 18975 *structured path syntax* without parameters.

* pattern: `https://{identifier-scheme}/{identifier-value}` where `{identifier-scheme}` is a DNS domain name (without `/` characters unless `%2F` encoded) and `{identifier-value}` is a valid ISO/IEC 18975 path (which can include `/` characters to separate class, sub-class, and instance id as defined in ISO-18975)
* examples:
  * `https://products.sample-company.example/1234567`
  * `https://facilities-register.example/ABC123456`
  * `https://example.com/01/733240226591`
  * `https://example.com/01/733240226591/21/1234`

When a given identifier scheme uses both URN and URL mechanisms to represent identifiers as URIs then the `{identifier-scheme}` part SHOULD be the same for both. If the identifier scheme is registered in the UN global trust register then the `{identifier-scheme}` MUST match the corresponding scheme ID in the trust register.

### Universally Unique Identifier (UUID)

As an alternative to being issued by an issuing agency, identifiers can be algorithm-generated. The best-known example of this is the Universally-Unique Identifier (UUID). This relies on it being *extremely* unlikely, but not impossible, that the same identifier will be generated twice. For many practical applications, that can be "good enough" although there are some instances where duplicates have arisen (known as "collisions").

#### UUIDs as the complete identifier

When using a UUID as the identifier for an entity, the syntax would be

* pattern: `uuid:{UUID}`
* example: `uuid:709f3df6-4cdf-4bda-94d9-ce0ec9428616`

Such identifiers have no scheme information which could be used for resolvability and verifiability. Therefore usage SHOULD be limited to cases where there is no need for discovery of further data.

#### UUIDs as the scheme specific identifier value

UUIDs can be useful as scheme specific identifiers, particularly when there is value in the identifier being un-guessable. For example as a means to limit visibility of item specific data to the genuine holder of the goods - as described in the [UNTP Decentralised Access Control](DecentralisedAccessControl#shared-secrets) specification.

* pattern: `{uri-scheme}:{identifier-scheme}[:or/]{UUID}`
* examples:
  * `urn:gtr:products.sample-register.example:709f3df6-4cdf-4bda-94d9-ce0ec9428616`
  * `https://products.sample-register.example/709f3df6-4cdf-4bda-94d9-ce0ec9428616`

### Decentralised Identifiers (DID)

[Decentralised Identifiers (DIDs)](https://www.w3.org/TR/did-core/) are a type of URI that are resolvable and verifiable by design. They are self-issued by any party and do not depend on any central register or issuing authority. The general structure of a DID is defined by the [W3C Decentralised Identifiers recommendation](https://www.w3.org/TR/did-core/).

DIDs are particularly suited for self-issued identifiers and provide a different approach to global uniqueness compared to URNs and URLs. They achieve uniqueness through cryptographic methods and decentralized resolution rather than centralized registry management.

**Important:** DIDs do not require any specific path structure or hierarchical organization. While examples in this specification may show organizational path components (such as `:products:` or `:facilities:`), these are purely illustrative. Organizations are free to structure their DIDs in any way that ensures global uniqueness and complies with their chosen DID method specification. Simple flat structures (e.g., `did:web:example.com:ABCD1234`) are equally valid as hierarchical structures (e.g., `did:web:example.com:products:123456789`).

For DID-specific resolution processes and implementation examples, see [Implementation Guidance: Self-Issued Identifiers (DIDs)](#implementation-guidance-self-issued-identifiers-dids).

## Resolution and Linksets

Once an identifier has been normalized to a URI, the next step is **resolution**: dereferencing the URI to obtain structured data describing the identified entity and related resources. This section covers the shared resolution model that applies to both registry-managed and self-issued identifiers.

### IDR Query URL

IDR queries are URLs that take the general form:

`https://{domain}/{path}?{query}` where

- `domain` is the web domain of the resolver service, usually operated by the identifier scheme register (e.g., `resolver.sample-register.example`)
- `path` carries the specific ID of the product or facility being queried and may include qualifiers (e.g., `products/ABCD9876/items/1234`)
- `query` contains a list of URL parameters that are used to filter the response (e.g., `linkType=dpp&language=en` to override the HTTP client's Accept-Language header)

A typical IDR query might be:

`https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset`

which is requesting:
- the complete link-set
- about a product class `ABCD9876`
- issued using an identifier scheme supported by `sample-register.example`
- with specific serial number `1234`

To get a different response, the query might be modified as follows:
- `https://resolver.sample-register.example/products/ABCD9876?linkType=linkset` → get data about the product class only, not a specific serialized item
- `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=dpp` → get only the DPP for the item
- `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=all&language=de` → get all links to German language targets
- `https://resolver.sample-register.example/products/ABCD9876/items/1234` → get a redirect to the target of the default link

### Linkset Format

The response to an IDR query is an [IETF linkset](https://datatracker.ietf.org/doc/rfc9264/) which contains one or more `contexts`, each of which contain one or more `targets`.

- A **context** describes what the links are about using the `anchor` property. Often there is only one anchor that represents the requested identifier. But as described in the resolver workflow, a resolver may return links about related entities. For example, a query about a specific serialized item may return some links about the item, and some links about the product class, and even some links about the manufacturer or brand that sells the product.
- A **target** describes a specific link identified with the `href` property together with other properties that provide useful meta-data about the link.

A typical response to the sample query `https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset` might be as shown below:

- There are two contexts: one at serialized item level `"anchor": "https://resolver.sample-register.example/products/ABCD9876/items/1234"` and one at product class level `"anchor": "https://resolver.sample-register.example/products/ABCD9876"`
- The first context has two targets, both of which have a linkType `"dpp"` (UNTP digital product passports) and MIME type `application/vc+jwt` but one is rendered in German and the other in English
- The second context is at product level and has one target which points to the manufacturer's product information web page. This highlights that link resolvers can return all kinds of relevant links, only some of which point to UNTP credentials

```json
{
    "linkset": [
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876/items/1234",
            "dpp": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "type": "application/vc+jwt",
                    "title": "Digital Product Passport",
                    "hreflang":["en"]
                 },
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869311.json",
                    "title": "Digitaler Produktpass",
                    "hreflang":["de"],
                    "type": "application/vc+jwt"
                 }
            ]
        },
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "pip": [
                {
                    "href": "https://sample-company.example/productInformation/ABCD9876",
                    "type": "text/html",
                    "title": "Product Information"
                 }
            ]
        }
    ]
}
```

Linksets MUST use [IANA-registered link relation types](https://www.iana.org/assignments/link-relations/link-relations.xhtml), UNTP-defined link relation types, or link types that, as defined in [RFC 8288](https://www.rfc-editor.org/rfc/rfc8288.html), can be expressed as URLs; and [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml) to describe the semantics and formats of linked resources.

Link type (e.g., `dpp`) and media type (e.g., `application/vc+jwt`) indicate the *intended* content. However, due to [domain sovereignty](#domain-sovereignty) principles, actual content can only be verified by dereferencing and validating.

### Linkset Response Patterns

This section covers specific linkset use cases that SHOULD be supported by conforming link resolvers. The general approach to solving linkset specific needs is:

* Where possible, always use IETF linkset standard properties and IANA standard link types.
* Where necessary, use custom link types and linkset properties but always define them in a public vocabulary and reference them using a profile link type.

#### Defaults

Default link types allow a resolver to return just the target URL of the default link - which means that client applications (including just a camera on a mobile phone) need not have any knowledge of link resolvers and how they work.

Link resolver services SHOULD define DEFAULT link type for each anchor which defines the href target to which a client will be redirected when no linkType is specified in the matching query URL. In the previous IDR example, calling the resolver URL without a linkType parameter:

`https://resolver.sample-register.example/products/ABCD9876/items/1234?linkType=linkset`

Would redirect the client directly to the target href of the default link type:

`https://sample-credential-store.example/credentials/dpp-90664869327.json`

#### Automatically Returning The Right Language

HTTP headers often contain accept header properties that can be useful hints for link resolver behaviour. For example browsers will normally include a language accept header that matches the users configured preference. This can be used to return only those links that match the users language even if the IDR query string does not specify a preference. For example, consider an IDR that:

* defines a default link type as `dpp`
* maintains DPP links in a dozen languages
* and receives the following HTTP query URL

```
GET /products/123456789 HTTP/1.1
Host: resolver.sample-company.example
Accept-Language: de
```

Even though there are a dozen DPP links maintained by the IDR service, only one of them is in German and so the IDR can again redirect the client to the specific target URL of the German language DPP:

`https://sample-credential-store.example/credentials/dpp-90664869311.json`

#### Secondary Resolvers

There are some cases where an identifier scheme owner manages identifiers at a coarse granularity by issuing globally unique prefixes but allows the subject to manage more fine grained identifiers themselves. For example:

* A product register maintains product identifiers in a single global register but management of serialised items is left to the owner of the GTIN.
* IATA issues 3 character carrier identifiers but allows each carrier to add the 7 digit suffix for each cargo consignment to make a globally unique 11 digit consignment number.
* Australian government manages 8 alpha-numeric character farm identifications codes such as `QDBH0132` and allows each farmer to add a unique suffix to identify each unique livestock animal born on the farm.

and many more examples exist.

The result is that a client may construct an IDR query to the genuine scheme operator's IDR service but that service may not hold information at the requested granularity. In such cases, a conformant IDR SHOULD return links relevant to the more coarse grained item and, if available, a link to a secondary resolver service (eg hosted by the serialised product manufacturer) that can return more fine grained information. For example the following query to a link resolver about a serialised item:

`https://resolver.sample-register.example/products/ABCD9876/items/1234`

May return a link to a secondary resolver that maintains data at serialised item level as well as a link to a DPP at product class level.

```json
{
    "linkset": [
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876/items/1234",
            "idr": [
                {
                    "href": "https://resolver.sample-company.example/products/ABCD9876/items/1234",
                    "title": "Secondary Identity Resolver",
                    "hreflang":["en"],
                    "type": "application/linkset+json"
                 }
            ]
        },
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "dpp": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "title": "Digital Product Passport",
                    "hreflang":["en"],
                    "type": "application/vc+jwt"
                 }
            ]
        }
    ]
}
```

#### Versioned Targets

In some cases, a publisher may wish to maintain multiple versions of a credential as available links in a linkset. The recommended method is to add the relevant IANA version link relation to the rel value array as shown in the example below. In this case there are two links for the same anchor, both include `dpp` as a link relation value but one also has the IANA link relation `predecessor-version`:

```json
{
    "linkset": [
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "dpp": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "title": "Digital Product Passport",
                    "hreflang":["en"],
                    "type": "application/vc+jwt"
                 },
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869111.json",
                    "rel":["predecessor-version"],
                    "title": "Digital Product Passport",
                    "hreflang":["en"],
                    "type": "application/vc+jwt"
                 }
            ]
        }
    ]
}
```

#### Creating New Links

In some cases, an identity resolver service may wish to accept updates such as creation of new links from appropriately authorised users. For example, adding a maintenance event to a battery passport record after the battery has been sold into the market. An identity resolver SHOULD accommodate this possibility by including a link in the linkset for the given product that specifies how to POST an event to the resolver. In the example below, an anchor representing product `https://resolver.sample-register.example/products/ABCD9876` has two links. The first is a simple link to a DPP describing the product. The second describes a method to create a new maintenance event.

* The standard IANA link relation `edit` indicates that the target resource is used to edit the link's context.
* The custom link relation `dte` indicates that the target expects a digital traceability event.
* The custom property `method` indicates that the HTTP header requires a POST method and a secret key in the X-API-Key HTTP header property.

```json
{
    "linkset": [
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "dpp": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "title": "Digital Product Passport",
                    "hreflang":["en"],
                    "type": "application/vc+jwt"
                 }],
            "dte": [
                {
                    "href": "https://sample-credential-store.example/credentials/dte",
                    "rel":["edit"],
                    "title": "Create Maintenance Event",
                    "method":["POST","X-API-Key"],
                    "type": "application/vc+jwt"
                 }
            ]
        }
    ]
}
```

#### Secure Targets

In some cases the target of a link contains sensitive data that is not generally accessible to the public. In such cases, as described by the decentralised access control specification, the target of the link is encrypted and requires a decryption key or proof of authorised role to decrypt. The corresponding link in the resolver linkset SHOULD specify the encryption method and allowed list of access roles.

```json
{
    "linkset": [
        {
            "anchor": "https://resolver.sample-register.example/products/ABCD9876",
            "dte": [
                {
                    "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
                    "title": "Product Traceability",
                    "encryptionMethod": "AES-128",
                    "accessRole":["untp:accessRole#Owner"],
                    "hreflang":["en"],
                    "type": "application/vc+jwt"
                 }
            ]
        }
    ]
}
```

### Resolver Workflow

The internal workflow of an identity resolver service is not defined by this specification. However, there are some common conditions that a link resolver service SHOULD manage consistently. For example

* When a query URL is not valid
* When there is no data for the requested entity ID.
* When there is no data for an item level ID but there are available links for product class level ID
* When a requested link type does not exist.

These cases are shown in the example resolver workflow diagram below.
```mermaid
flowchart
    A[Start] --> B{valid element string?}
    B -- No --> C[error 400]
    B -- Yes --> D{identifier record found?}
    D -- No --> E{redirection possible?}
    D -- Yes --> F{link type requested?}
    E -- No --> G[not found 404]
    E -- Yes --> H[redirect to external resolver 307]
    F -- No --> I[redirect to default link 307]
    F -- Yes --> K{linktypes=linkset?}
    K -- Yes --> L[create/append list of links]
    L --> J{is there a less granular identifier?}
    J -- Yes --> L
    J -- No --> X[return list of links 200]
    K -- No --> M{matching link available?}
    M -- Yes --> N[redirect to matching link 307]
    M -- No --> O{matching link at next level?}
    O -- Yes --> P[redirect to requested link type at next level up 307]
    O -- No --> Q[redirect to default 307]
```

### Creating the IDR Query URL

There are several forms in which an identifier might be discovered (e.g., as a data carrier on a physical product or as a URI in a structured document). The identifier representation format is often not an IDR query URL and so may need to be translated into an IDR URL query format. The generalized process to derive an IDR query URL has two steps:

1. **Map the native format** found in a data carrier to a consistent global URI as described in the [Identifier Representation](#identifier-representation) section
2. **Map the global URI** to an IDR query string as described in the following paragraphs

This mapping architecture is designed to ensure that UNTP can accommodate any new or existing identifier scheme and any data carrier and still maintain linked data consistency (i.e., consistent URI representation) as well as resolvability and verifiability of identifiers.

**From a URN to IDR linkset:**

The UN global trust register will include resolver templates for each scheme and so the UNTP requirement that identifiers be resolvable is met by substituting the URN `{identifier-value}` into the `{id}` placeholder in the resolver template related to the matching `{identifier-scheme}`. For example:

- Given a URN ID of `urn:gtr:example.com:ABC123`, the `{identifier-scheme}` is `example.com`
- And a resolver template of `https://resolver.example/{id}` is registered for scheme `example.com`
- Then the resolver URL would be `https://resolver.example.com/ABC123` which would return an IDR LinkSet

**From a URL to IDR linkset:**

As described in [IDR URLs as identifiers](#idr-urls-as-identifiers), URL identifiers SHOULD already be Identity Resolver URLs that conform to the ISO/IEC 18975 structured path syntax without parameters. Client applications may of course add parameters to the URL before calling the resolver service to get more specific link sets.

## Verification

Once an identifier has been discovered and resolved to a linkset, the next step is **verifying the information linked from that identifier**. This stage is common to both registry-managed and self-issued identifiers.

The Identity Resolver itself does **not** perform verification of credentials or content. Its role is to:

- Provide a consistent, machine-readable **linkset** for any supported identifier.
- Use **typed links** (e.g. `dpp`, `dcc`) and **media type declarations** (e.g. `application/vc+ld+json`) to clearly signal when a linked resource is expected to be a verifiable credential.
- Enable client systems and verifiers to **retrieve and independently verify** the linked resources.

### Trust Models

Although the verification step is external to the resolver, the underlying trust anchors differ:

- **Registry-managed identifiers**: verifiers may rely on the registry's governance (identifier issuance rules, who is authorised to publish linksets) as part of their trust decision.
- **Self-issued identifiers (DIDs)**: verifiers rely on cryptographic proof of control (DID method rules, signatures) to ensure the identifier holder really controls the linked resources.

### Relationship to UNTP Credential Verification

Linked resources such as Digital Product Passports (DPPs) or Digital Conformity Credentials (DCCs) are expected to be expressed as [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/). These credentials can be validated independently using the mechanisms defined in the [UNTP Verifiable Credential Profile](../specification/VerifiableCredentials.md).

By separating **resolution** from **verification**, the Identity Resolver stays lightweight and interoperable, while implementers remain free to apply the appropriate trust model and verification rules for their sector or geography.

## Domain Sovereignty

This specification acknowledges the fundamental principle of **domain sovereignty** as codified in [IETF Best Current Practice 190 (BCP 190)](https://www.rfc-editor.org/info/bcp190): domain owners have complete authority over their URI space and can define any URL structure they choose.

:::warning Important: Domain Sovereignty

While this specification describes how identifiers *should* resolve and what link types *should* indicate, domain owners have complete authority over their URI space (IETF BCP 190). URL patterns, link types, and media types are hints about intended content—not guarantees. Clients must always validate actual content after dereferencing.

:::

**Critical implications for implementers:**

- A URL that *appears* to conform to ISO/IEC 18975 structure does **not** guarantee it resolves to an Identity Resolver service
- A link with type `dpp` does **not** guarantee it points to a UNTP-conformant Digital Product Passport
- A link with media type `application/vc+jwt` does **not** guarantee the content is a UNTP credential—it could be any verifiable credential format
- Even when link type, media type, and URL structure all match expectations, **the actual content can only be determined by dereferencing the URL** (performing an HTTP GET request)
- Different DPP implementations, standards, or formats may use the same link types and media types

**Real-world scenarios:**

**Scenario 1: Same link type, different DPP standards**
```json
{
  "linkset": [{
    "anchor": "https://resolver.example.com/products/ABC123",
    "dpp": [
      {
        "href": "https://manufacturer-a.example/dpp/ABC123",
        "type": "application/vc+jwt",
        "title": "Digital Product Passport"
      },
      {
        "href": "https://manufacturer-b.example/dpp/XYZ789",
        "type": "application/vc+jwt",
        "title": "Digital Product Passport"
      }
    ]
  }]
}
```

Both links use `dpp` and `application/vc+jwt`, but one could be UNTP-conformant while the other implements a different DPP standard entirely. Only dereferencing and validating reveals the truth.

**Scenario 2: ISO/IEC 18975-like URL without IDR service**

The URL `https://example.com/01/1234567890` *appears* to follow ISO/IEC 18975 Digital Link structure, but:
- Without a Resolver Description File at `https://example.com/.well-known/resolver`, there's no declaration this is an IDR
- The domain owner (per IETF BCP 190) could use this URL pattern for any purpose: a product catalog, an internal tracking system, or even unrelated content

**Scenario 3: Link rot and URL reuse**

Even if a URL *currently* points to a UNTP DPP, domains may:
- Restructure their website, breaking the link
- Repurpose the URL for different content
- Change ownership, with new owners using the same URL structure differently

**Verification approach for clients:**

1. ISO/IEC 18975 provides the **[/.well-known/ method (RFC 8615)](https://www.rfc-editor.org/rfc/rfc8615.html)** for domains to declare resolver services
2. Before assuming a domain hosts an IDR service, clients **SHOULD** verify that `{domain}/.well-known/resolver` exists and contains a valid Resolver Description File
3. Services expecting specific URL patterns SHOULD process them optimistically while being prepared for:
   - Non-conformant responses
   - Different standards using similar link types
   - URLs that appear conformant but return unexpected content
4. Always validate the actual content after dereferencing—do not rely solely on URL patterns, link types, or media types
5. Implement robust error handling for cases where responses do not match expectations

**Best practices:**

- **For resolver operators**: Publish a Resolver Description File at `/.well-known/resolver` to declare your service per ISO/IEC 18975
- **For clients**: Treat link type and media type as *hints* about intended content, not guarantees. Validation occurs after retrieval.

## Implementation Guidance: Registry-Managed Identifiers

This section is for operators of centralised identifier registries (e.g., GS1, national business registers, sector schemes). Registry-managed identifiers are issued or recognized by an authoritative register, which defines the rules for **identifier issuance** and for **authorizing who may add links** against the identifier.

The diagram below illustrates identifier schemas across three entity types: businesses, locations, and products. It demonstrates how existing identification systems can be made interoperable through the UNTP Identity Resolver.

![Identifier examples](../assets/images/idr-IdentityResolverIdentifiers.png)

### Data Carriers

UNTP supports any standard data carrier. Recommended are those defined in [ISO/IEC JTC 1/SC 31](https://www.iso.org/committee/45332.html), such as linear barcodes, [Data Matrix](https://www.iso.org/standard/80926.html), [QR Codes](https://www.iso.org/standard/83389.html), and RFID.

- Carriers differ in scanning needs: RFID requires specialist readers; barcodes require optical scanners with software able to interpret identifiers.
- Smartphones can read most barcodes and NFC tags, with QR Codes carrying URLs the most broadly accessible. Risks (e.g. link rot) are mitigated by encoding identifiers that are globally unique online and offline within URLs as defined in [ISO/IEC 18975](https://www.iso.org/standard/83389.html) Information technology — Automatic identification and data capture techniques — Encoding and resolving identifiers over HTTP.

:::info Offline use cases
Some use cases require identifiers to work offline. A common example is retail, where QR codes (or other data carriers) encode GS1 application identifiers such as expiration dates; scanning may happen without network access. Implementers should consider both online resolution and offline interpretation of encoded data where applicable.
:::

:::tip QR Code Size Optimization
QR code physical size is determined by the number of **modules** (cells), which depends on
both data length and the **character set** used. QR encoders use Numeric mode (digits only),
Alphanumeric mode (uppercase + digits + 9 symbols), or Byte mode (any character, least
efficient). Because the URL scheme (`https`) and host are case-insensitive (RFC 3986 §3.1,
RFC 4343), implementers encoding resolver URLs in QR codes **SHOULD** use uppercase for the
scheme and host components (e.g., `HTTPS://ID.EXAMPLE.COM/...`) to allow the QR encoder to
use the more compact Alphanumeric mode, resulting in a smaller QR code at no cost to
interoperability.

Where identifier path and query values are also uppercase (e.g., GS1 Application Identifier
syntax), the entire URL can be encoded in Alphanumeric mode. Scheme-specific compression
algorithms (such as GS1 Digital Link compression) may provide further size reductions when
many query parameters are present, but are outside the scope of this specification;
implementers should follow the relevant scheme standard.
:::

In **Automatic Identification and Data Capture (AIDC)**, the ISO/IEC 15459 series establishes a registry for short codes in data carriers. Organizations issuing barcode and RFID identifiers receive a unique **Issuing Agency Code** to prevent conflicts. ISO/IEC 15418 defines **Data Identifiers (DIs)** and **Application Identifiers (AIs)**, which qualify identifiers, ensuring globally unique encoding in optical and RFID data carriers.

For example:
- **DI `2B`** identifies gas cylinders per U.S. D.O.T. standards.
- **AI `01`** represents a **Global Trade Item Number (GTIN)**.

#### Examples of carrier encodings

The same identifier may appear in multiple carrier forms but must normalize to a consistent URI:
- **2D Matrix barcode**: `0107332402265910211234567890…`
- **RFID (EPC tag URI)**: `urn:epc:tag:sgtin-96:1.7332402.026591.1234567890`
- **QR Code (with ISO/IEC 18975-compliant payload)**: `https://id.resolver.example/01/733240226591/21/1234567890`

Scanners are expected to apply scheme-specific logic to normalize these carrier data forms into UNTP URNs/URIs that align with identifiers used in credentials (e.g., DPPs). For detailed identifier representation conventions, see [Identifier Representation](#identifier-representation).

### Mapping Carriers to URIs

A key challenge is to ensure that all these different data carrier representations are mapped to a consistent globally unique identifier when building value chain transparency graphs.

- A **2D Matrix code** might yield the string `0107332402265910211234567890240+A01=442.001-UP001T91456498765498765465432132168753` where `733240226591` is the product ID (with company prefix) and `1234567890` is the serial number
- An **RFID Tag** for the same product might yield a string like `urn:epc:tag:sgtin-96:1.7332402.026591.1234567890` where `7332402.026591` is the product ID and `1234567890` is the serial number.
- A **QR code** may yield `https://id.resolver.example/01/733240226591/21/1234567890` where `733240226591` is the product ID (with company prefix) and `1234567890` is the serial number.

![ID mapping](../assets/images/idr-IdentityResolverMapping.png)

Existing data carrier schemes are very varied but usually well documented. Therefore it is reasonable to expect that scanners will be aware of the context and will include scheme specific logic to read the data carriers and construct UNTP standard URNs or URIs to match against identifiers used in credentials such as digital product passports.

For new identifier schemes or existing schemes that have not already defined data carrier specifications, UNTP implementers SHOULD

- directly encode the UNTP URN structure into 2D matrix codes and RFID tags.
- directly encode the UNTP URL structure into QR codes.

### Registry Resolver Configuration

Resolution for registry-managed identifiers is typically achieved by dereferencing a URI template defined by the identifier scheme (which SHOULD be conformant with ISO/IEC 18975).

- Domains **SHOULD** declare their resolver service via a Resolver Description File at `{domain}/.well-known/resolver` per ISO/IEC 18975 and [RFC 8615](https://www.rfc-editor.org/rfc/rfc8615.html).
- When available and conformant, the resolver returns an [IETF linkset](https://datatracker.ietf.org/doc/rfc9264/) as a JSON document containing typed links from the identifier to other resources.

### End-to-End Example

1. Items in an inbound shipment are barcoded using an existing, well-known scheme (no UNTP-specific barcode).
2. A scanner captures an item ID (e.g., 1234567) and either constructs a URL directly (per ISO/IEC 18975) or looks up the scheme in the UN global register of schemes.
   * Example template: `https://resolver.example/{id}` → `https://resolver.example/1234567`.
3. Calling the URL `https://resolver.example/1234567` returns an [IETF link-set](https://datatracker.ietf.org/doc/rfc9264/) listing typed links to resources.
   * Link types might include a safety data sheet, instruction manual, brand homepage, Digital Product Passport (DPP), or Digital Conformity Credential (DCC).
   * Each link declares both its type and media format (e.g., HTML, PDF, JSON), using [IANA-registed Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml).
4. A link typed of `dpp` with a format declaration of [`application/vc`](https://www.w3.org/TR/vc-data-model-2.0/#vc-ld-media-type) indicates a verifiable DPP credential.
   * The DPP may include sustainability claims (e.g., product emissions footprint).
   * Following a `dcc` link yields a credential from a third-party certifier (e.g., carbon intensity attestation).

In this model, the scheme register defines how IDs resolve and who is authorized to add links.

## Implementation Guidance: Self-Issued Identifiers (DIDs)

This section is for organisations using [W3C Decentralized Identifiers](https://www.w3.org/TR/did-core/). Self-issued identifiers are created and controlled directly by an entity, without relying on a central registry. For details on which DID methods are acknowledged for use in UNTP implementations, see the [DID Methods](VerifiableCredentials.md#did-methods) specification.

:::info
**Note on DID Method Examples**: Throughout this section, `did:method` is used as a placeholder in examples to represent any acknowledged DID method. The specific syntax, resolution mechanisms, and implementation requirements vary by method. For details on which DID methods are acknowledged by UNTP and their specific characteristics, see the [DID Methods](VerifiableCredentials.md#did-methods) specification.
:::

### DID Discovery

- A DID string (e.g., `did:method:123456789abcdefghi`) can be carried in QR codes, RFID tags, or embedded in structured documents.
- Unlike registry-managed identifiers, there is no external register to provide discovery templates. Instead, the DID itself is the discovery key.
- Scanning a carrier or parsing a document yields the DID, which can then be resolved via its [DID method](VerifiableCredentials.md#did-methods).

**Examples of carriers**:
- **QR Code** containing a DID string: `did:method:mycompany.example` (see [DID Methods](VerifiableCredentials.md#did-methods) for acknowledged methods).
- **NFC tag** with an embedded DID.
- **Invoice document** with a DID for the issuing organization in its metadata.

### DID Documents as Resolvers

Resolution is performed according to the DID method specification (see [DID Methods](VerifiableCredentials.md#did-methods) for acknowledged methods and implementation requirements). The result of resolution is a **DID Document**, which describes:
- Public keys and verification methods.
- Service endpoints, including resolvers for linksets.
- Supported key material and cryptographic suites.

From DID service endpoints, clients may retrieve linksets in the same IETF format used for registry-managed identifiers.

By design, all DIDs resolve to a URL that addresses a DID document. The way in which a DID resolves to a DID document is specific to the DID method (see [DID Methods](VerifiableCredentials.md#did-methods) for acknowledged methods and implementation details).

:::info Important Note on DID Path Structure

The path components shown in these examples (such as `:products:123456789`) are illustrative and demonstrate one possible organizational approach. DID-based identifiers do **NOT** require any specific path structure. Organizations are free to structure their DIDs in any way that suits their needs, or use simple flat structures without paths (e.g., `did:method:sample-company.example:ABCD1234`). The critical requirement is that each DID must be globally unique and resolvable according to its DID method specification (see [DID Methods](VerifiableCredentials.md#did-methods)).

:::

- **DID with path structure**: `did:method:sample-company.example:products:123456789` is an example of a product identifier using an acknowledged DID method (see [DID Methods](VerifiableCredentials.md#did-methods)) with an organizational path component
  - **URL**: `https://sample-company.example/products/123456789/did.json` would be the URL of the DID document according to the DID method specification (see [DID Methods](VerifiableCredentials.md#did-methods) for resolution endpoints)
- **DID without path structure**: `did:method:sample-company.example:ABCD1234` is an alternative example using a flat structure
  - **URL**: `https://sample-company.example/ABCD1234/did.json` would be the corresponding DID document URL according to the DID method specification

The DID document `did.json` has a standard data model defined by the [W3C DID recommendation core properties](https://www.w3.org/TR/did-core/#core-properties). It is primarily designed to define the cryptographic methods by which control of a DID can be verified, including associated public keys. The DID [service](https://www.w3.org/TR/did-core/#services) property can be used to reference further information such as UNTP credentials like a digital product passport. The UNTP approach to using a DID document as a resolver service combines conformant use of DID `service` properties with maximum alignment with IETF linksets.

- The DID document `service.id` property is the same as the linkset `anchor` property with the optional `#fragment` suffix to ensure that `service.id` is unique
- The DID document `service.type` property is the same as the linkset linkType value
- The DID document `service.serviceEndpoint` property is exactly the same as the linkset `target` object

```json
{
  "id": "did:method:sample-company.example:products:123456789",
  "..other did document properties ..",
  "service": [{
    "id":"did:method:sample-company.example:products:123456789#untp:dpp",
    "type": "dpp",
    "serviceEndpoint": {
          "href": "https://sample-credential-store.example/credentials/dpp/90664869327.json",
          "title": "Digital Product Passport",
          "hreflang":["en"],
          "type": "application/vc+jwt"
     }
  }, {
    "id":"did:method:sample-company.example:products:123456789#untp:idr",
    "type": "linkset",
    "serviceEndpoint": {
          "href": "https://resolver.sample-company.example/products/123456789",
          "title": "Identity Resolver Service",
          "type": "application/linkset+json"
     }
  }]
}
```

**Note:** The DID in this example uses a path structure (`:products:123456789`), but organizations may choose any structure that ensures global uniqueness. For example, `did:web:sample-company.example:ABCD1234` would be equally valid.

The example above shows two ways of using the DID document `serviceEndpoint` as an identity resolver service:

- The first target references a UNTP DPP credential directly
- The second target references a resolver service endpoint which itself would return a linkset

In this way, simple scenarios can be achieved simply by placing link targets directly in the DID document whilst richer and more dynamic link resolver services can also be delivered by including a DID document service which is itself a link resolver.

### DID Deep Link Example

[Decentralised Identifiers (DIDs)](https://www.w3.org/TR/did-core/) are a type of URI that are resolvable and verifiable by design. They are self-issued by any party and do not depend on any central register or issuing authority. The general structure of a DID is defined by the [W3C Decentralised Identifiers recommendation](https://www.w3.org/TR/did-core/).

This section shows how [acknowledged DID methods](VerifiableCredentials.md#acknowledged-did-methods) can be used to define a globally unique product, company or facility DID and a discoverable deep link to the data associated with that DID. Every DID is associated with a DID Document. The digital product passport use case is used to show how to resolve from the globally unique product DID to the digital product passport data.

The DID method defines how the DID document is located, resolved, and how CRUD (create, read, update, delete) operations are performed. For details on acknowledged methods and their resolution mechanisms, see [DID Methods](VerifiableCredentials.md#did-methods).

To resolve the DID to the digital product passport, it needs to be combined with a DID resolver domain, the globally unique product DID, and optionally a service endpoint:

- **resolver domain**: The DID resolver implements the DID method and returns the DID document to the requestor. A free DID resolver is e.g. the [Universal Resolver](https://dev.uniresolver.io). The DID resolver can be freely chosen by the economic operator or can be built in-house.
- **product DID**: The product DID - when using [acknowledged DID methods](VerifiableCredentials.md#acknowledged-did-methods) - is constructed according to the method's identifier syntax (see [DID Methods](VerifiableCredentials.md#did-methods) for specific syntax details). It typically combines: 1. The DID method (e.g., `did:web`), 2. the Economic Operator domain that places the product on the market and where the DID document can be found, 3. the product identifier unique to that domain. The identifier portion may include organizational path components (e.g., `:products:123456789`) or use a flat structure (e.g., `:ABCD1234`) - the choice is entirely up to the organization, as long as the DID remains globally unique.
- **service endpoint**: The service endpoint can lead to different information e.g. a human readable DPP, a service API, or a DPP credential store.

The resulting URL including the resolver domain combined with product DID and service endpoint leads to the deep link of the digital product passport.

The table below shows the ingredients of a DID based DPP deep link URL:

| Component                | Description                                                                                | Value                             |
| :----------------------- | :----------------------------------------------------------------------------------------- | :-------------------------------- |
| Resolver                 | DID resolver domain used to resolve the DID                                                | `https://resolver.example`        |
| DID Method               | Method part of the DID – defined CRUD rules                                                | `did:method`                      |
| Economic Operator domain | Domain that is under the control of the economic operator and that hosts the DID document  | `example.com`                     |
| ID                       | Identifier that is unique to the product in the economic operator domain                   | `model4TR`                        |
| Product DID              | This is the globally unique product identifier in form of a decentralised identifier (DID) | `did:method:example.com:model4TR` |
| Service Endpoint         | Optional service endpoint parameter specifying what information to retrieve from the DID   | `?service=item-dpp`               |

The deep link URL to the digital product passport is accordingly:
`https://resolver.example/did:method:example.com:model4TR/?service=item-dpp`

It can be then put to different data carriers, such as QR codes, RAIN tags, or NFC tags. Below please find a QR code example carrying the DPP deep link (not resolvable!):

![QR code with DPP deep link](../assets/images/idr-qr-code-with-dpp-deep-link.png)

The figure below shows the information flow of accessing a digital product passport:

- The DPP deep link is scanned from the QR code, then
- the DID resolver is called and finds the DID document of the product DID.
- The DID document includes the human readable Battery Passport website URL under the provided service endpoint which is given back to the user who scanned the QR code.
- The user can explore the battery passport website.

![Battery Passport Infographic](../assets/images/idr-battery-passport-infographic.png)

### End-to-End Example

1. A facility issues a DID for a machine it operates:
   * Example: `did:method:abc123` (see [DID Methods](VerifiableCredentials.md#did-methods) for acknowledged methods).
2. The DID string is resolved using the method's resolution rules (as specified in the [DID Core specification](https://www.w3.org/TR/did-core/)).
   * Resolution yields a **DID Document** that describes key material, service endpoints, and supported link types.
3. The DID Document may include service endpoints that point to linksets or resources.
   * For example, a service endpoint could advertise a resolver URL returning an [IETF linkset](https://datatracker.ietf.org/doc/rfc9264/).
   * These linksets are structured identically to those in the registry-managed example, declaring typed links (DPP, DCC, manuals, etc.) and media formats using [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml).
4. A link of type `dpp` with format [`application/vc`](https://www.w3.org/TR/vc-data-model-2.0/#vc-ld-media-type) signals a verifiable credential.
   * The holder of the DID signs and publishes the DPP, which can be verified against keys in the DID Document.
   * A `dcc` link type may point to an attestation issued by an independent certifier, also verifiable via signatures.

In this model, the **DID controller** has direct responsibility for defining resolution endpoints and ensuring data availability. Governance is enforced cryptographically through key control rather than by a central register.

---

## Verifiable Credentials

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Overview

The World-Wide-Web Consortium (W3C) has defined a [data model for Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/) (VCs). A VC is a portable digital version of everyday credentials like education certificates, permits, licenses, and registrations. VCs are digitally signed by the issuing party and are tamper-evident, privacy-preserving, revocable, and independently verifiable.

The UN has previously assessed this standard and has recommended its use for a variety of cross-border trade use cases in a recent [white paper](https://unece.org/trade/documents/2023/10/white-paper-edata-verifiable-credentials-cross-border-trade). VCs are inherently decentralised and so are an excellent fit for UNTP, which recommends that passports, credentials, and traceability events are all issued as W3C VCs.

A related W3C standard called [Decentralized Identifiers (DIDs)](https://www.w3.org/TR/did-core/) provides a mechanism to manage the cryptographic keys used by verifiable credentials and to link multiple credentials into verifiable trust graphs. DIDs are not the same as the business, product, or location identifiers maintained by authoritative agencies, but can be linked to them.

## Business requirements for UNTP application of VCs

There are many different technical implementation options for verifiable credentials, which presents an interoperability risk — credentials issued by one party may not be understandable or verifiable by another. UNTP does not design new technical standards (that is the role of standards bodies such as W3C or IETF). Instead, UNTP enhances interoperability by recommending the narrowest practical set of technical options for each business requirement.

A key design principle for decentralised ecosystems is [Postel's robustness principle](https://en.wikipedia.org/wiki/Robustness_principle): **an implementation should be conservative in its sending (issuing) behaviour, and liberal in its receiving (verifying) behaviour.** Sustainability evidence in a given value chain may arrive as many different versions of W3C VCs, or as ISO mDL credentials, Hyperledger Anoncreds, or even human-readable PDF documents. Being open in what is received and verified allows sustainability assessments to draw on a wide set of evidence. Conversely, choosing a narrow set of ubiquitous technology options when *issuing* UNTP credentials simplifies the task of verifiers and minimises costs for the entire ecosystem.

| ID | Name | Requirement Statement | Solution Mapping |
|---|---|---|---|
| VC-01 | Integrity | Support tamper detection, issuer identity verification, and credential revocation so verifiers can trust the integrity of UNTP credentials. | All VC options support this |
| VC-02 | Compatibility | Recommend the narrowest practical set of technology options aligned with the most ubiquitous global choices to minimise the cost of interoperability. | [Basic profile](#vcdm-profile) |
| VC-03 | Human readable | Support both human-readable and machine-readable credentials so that actors with lower technical maturity are not blocked from participating. | [Render method](#render-method) |
| VC-04 | Discovery | Enable discovery and verification of credentials from product identifiers, so that verifiers need no prior relationship with issuers or subjects. | [Identity Resolver](IdentityResolver.md) |
| VC-05 | Semantics | Use standard web vocabularies so data from independent credentials can be meaningfully aggregated. | [Vocabularies](CoreVocabulary.md) |
| VC-06 | Performance | Enable efficient traversal and verification of graphs containing hundreds of credentials. | [Basic profile](#vcdm-profile) (JOSE proof) |
| VC-07 | Compliance | Meet any technology-based regulatory requirements in the countries where credentials are issued or verified. | [Basic profile](#vcdm-profile) |
| VC-08 | Openness | Avoid driving users towards closed ecosystems or proprietary ledgers. | [DID methods](#did-methods) |
| VC-09 | Portability | Allow issuers to move DID documents between service providers so long-duration credentials remain verifiable. | [DID methods](#did-methods) (webvh method) |
| VC-10 | Evolution | Evolve UNTP recommendations as VC tools and versions mature. | [Roadmap](#roadmap) |

## Verifiable Credential Profile

The UNTP Verifiable Credential Profile defines a narrow, interoperable subset of W3C VC technology choices. It comprises four parts: the VCDM profile (the core data model and proof mechanism), the render method (for human-readable presentation), the vocabularies (for semantic interoperability), and the DID methods (for issuer identification).

### VCDM profile

The VC basic profile is designed to be as simple, lightweight, and interoperable as possible. A conformant implementation

- MUST implement the [W3C VC Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) using the JSON-LD Compacted Document Form
- MUST implement [W3C VC Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/) for credential status management including revocation
- MUST implement [W3C-DID-CORE](https://www.w3.org/TR/did-core/) using DID methods defined in [DID methods](#did-methods)
- MUST implement the enveloping proof mechanism defined in [W3C VC JOSE / COSE](https://www.w3.org/TR/vc-jose-cose/) with JOSE (Section 3.1.1)

### Render Method

Human-readable rendering of digital credentials is essential because UNTP must work for every actor in a global supply chain — from multinationals with mature digital systems to small producers with nothing more than a smartphone and a barcode reader. A structured JSON credential is perfectly verifiable by a machine, but it is meaningless to a buyer, an inspector, or a consumer who needs to *see* what the credential says.

The VC data model addresses this through the `renderMethod` property, which allows a credential issuer to embed or reference a template that a verifier can use to transform the credential into a human-readable document (typically HTML). The same signed credential can therefore be verified by a machine and displayed as a nicely formatted passport, certificate, or report to a person — without requiring a second, separate human-readable artifact that could drift out of sync with the verified data.

A conformant UNTP implementation:

- SHOULD use the `renderMethod` property as defined in the [VC data model](https://www.w3.org/TR/vc-data-model-2.0/).
- SHOULD implement the `html render suite` defined in the draft [W3C render methods specification](https://w3c.github.io/vc-render-method/).

### Vocabularies

A shared understanding of the meaning of claims made in verifiable credentials is essential to interoperability. The UNTP approach is to retain full JSON-LD linked-data compliance while also supporting developers who are unfamiliar with linked data and "just want the JSON schema". This is achieved by maintaining versioned `@context` files for semantic meaning and complete JSON schemas for each credential type for schema validation.

![UNTP Credential Data Governance](../assets/images/vcp-CredentialVocabularyArchitecture.png)

Key design points:

* Credential instances contain VCDM type references for each uniquely identified linked-data object. Each extension builds on parent types and is enumerated in the type array (e.g. `["Facility", "Farm"]`).
* UNTP `@context` types are `protected` and MUST NOT be duplicated in extensions. Similarly, the UNTP `@context` does not duplicate `protected` terms from the VCDM `@context`.
* Unlike `@context` files, the JSON schema for each credential MUST be a complete schema that defines the entire credential including terms from VCDM and UNTP.

Conformant UNTP implementations:

- MUST use the [JSON-LD](https://www.w3.org/TR/vc-data-model/#json-ld) syntax for the representation of data in all issued credentials.
- MUST reference the relevant versioned `@context` file from the [UNTP vocabulary](https://vocabulary.uncefact.org/untp/). The UNTP context file is an extension of the W3C VC Data Model 2.0 context.
- MAY extend credentials with additional properties and, if so, SHOULD include an additional `@context` file reference that defines the extended properties. The `@vocab` "catch-all" mechanism SHOULD NOT be used.
- SHOULD implement widely used industry vocabularies such as [schema.org](https://schema.org/) as a first choice for UNTP extensions requiring terms not in the UN vocabulary.
- MAY use any other published JSON-LD vocabulary for industry or country specific extensions.
- MUST maintain `@context` files at the same granularity and version as the corresponding credential type. This prevents verification failures when context files change after credentials are issued.
- SHOULD provide a complete and versioned JSON schema for each credential type, to facilitate simple and robust implementation by developers without detailed knowledge of JSON-LD.

### DID Methods

UNTP supports the use of decentralised identifiers (DIDs) to uniquely and verifiably represent organisations, facilities, products, and other actors across global supply chains. These identifiers form the foundation for establishing [Digital Identity Anchors (DIAs)](/docs/specification/DigitalIdentityAnchor), resolving linksets via an [Identity Resolver](/docs/specification/IdentityResolver), and verifying credential issuers.

The [W3C DID Core specification](https://www.w3.org/TR/did-core/) allows for a broad range of DID methods, many of which are registered in the [W3C DID Extensions registry](https://www.w3.org/TR/did-extensions/#did-methods). Not all methods offer equivalent levels of verifiability, governance assurance, or operational fit for UNTP's trust model. Some methods rely solely on DNS and HTTPS infrastructure; others incorporate explicit proofs, registries, or governance contracts to strengthen control verification. The choice of DID method directly impacts the integrity of identity resolution and the downstream reliability of linked credentials. The UNTP working group expects that the proliferation of DID methods will consolidate over time to a much smaller number of methods, each designed to meet specific business needs.

#### Acknowledged DID methods

An acknowledged DID method is one that the UNTP working group has evaluated and determined to offer appropriate levels of verifiability, governance assurance, or operational fit for specific UNTP use cases. The list evolves through working group consensus as new methods mature.

| Method | Status | When to use |
|---|---|---|
| [`did:web`](#didweb) | ✅ Recommended | Simple, widely interoperable organisational identifiers where trust in domain ownership is independently verified |
| [`did:webvh`](#didwebvh) | ✅ Recommended (Advanced) | Institutional and organisational identifiers requiring verifiable history, key rotation, and auditability |

#### `did:web`

The `did:web` method enables identifiers to be derived from domain names and resolved via well-known HTTPS endpoints. It is widely supported and simple to implement, relying on existing DNS and TLS infrastructure to bind identifiers to hosting environments.

Within the UNTP framework, `did:web` offers a pragmatic entry point for identity publication and resolution. Its structure is compatible with the Digital Identity Anchor model and can be used to expose service endpoints, credential metadata, and other linkable assets.

However, `did:web` relies on implicit trust in domain ownership and HTTPS hosting. It does not by itself provide strong or auditable guarantees of control — particularly in shared hosting environments, federated platforms, or supply chains involving resellers and intermediaries. Its use is sensitive to domain expiration, certificate mismanagement, and untracked delegation. UNTP implementations MAY use `did:web` where simplicity and broad interoperability are prioritised, and where trust in domain ownership is independently verified.

A conformant UNTP implementation:

- MUST implement the [`did:web` method](https://w3c-ccg.github.io/did-method-web/) as an Organisational Identifier
- SHOULD implement the `did:web` method using the web domain of the issuer to avoid portability challenges

| Field | Description |
|---|---|
| Method Name | `did:web` |
| Identifier Syntax | `did:web:<domain>` or `did:web:<domain>:<path>` |
| Status | ✅ Recommended — widely interoperable and suitable for institutional and organisational identifiers |
| Governance | W3C-registered DID method maintained by the Decentralized Identity Foundation (DIF) and the W3C community |
| Resolution | Well-known HTTPS endpoints (typically `/.well-known/did.json` or `/did.json`), resolved via DNS and TLS infrastructure |
| Use Case in UNTP | Organisational identifiers, Digital Identity Anchors, identity publication and resolution. Suitable where simplicity and broad interoperability are prioritised. |
| Advantages | Widely supported, simple to implement, relies on existing DNS and TLS infrastructure. Compatible with the Digital Identity Anchor model. |
| Known limitations | Relies on implicit trust in domain ownership. No strong or auditable guarantees of control, particularly in shared hosting or federated platforms. Sensitive to domain expiration, certificate mismanagement, and untracked delegation. |
| Implementation Notes | MUST be implemented as an Organisational Identifier. SHOULD use the issuer's own web domain to avoid portability challenges. Requires independent verification of domain ownership. |

#### `did:webvh`

The `did:webvh` method extends `did:web` by introducing verifiable history — enabling tamper-evident tracking of identifier updates over time. It allows organisations to maintain a cryptographically linked log of key rotations, control changes, and migrations across domains, providing strong assurances of authenticity and continuity.

Within UNTP, `did:webvh` is recommended for institutional and organisational identifiers where auditability, long-term trust, and accountability are required — such as [Digital Identity Anchors](/docs/specification/DigitalIdentityAnchor), credential issuers, and registry maintainers. It retains the accessibility of web-based publishing via HTTPS while adding a transparent, verifiable chain of control that aligns with UNTP's principles of traceability, integrity, and transparency.

| Field | Description |
|---|---|
| Method Name | `did:webvh` |
| Identifier Syntax | `did:webvh:<domain>` or `did:webvh:<domain>:<path>`. Resolved via HTTPS to a `did.jsonl` (JSON Lines) file containing a verifiable chain of DID document versions. |
| Status | ✅ Recommended (Advanced) — suitable for institutional, organisational, and delegated identifiers requiring verifiable history, key rotation, and auditability |
| Governance | Maintained by the Decentralized Identity Foundation (DIF) as an extension of `did:web`. Defined in the [DIF DID Web Verifiable History specification](https://identity.foundation/didwebvh). |
| Resolution | HTTPS endpoints hosting a `did.jsonl` log file, typically at `/.well-known/did.jsonl`. Resolution verifies a chain of cryptographically linked versions (`previousVersionHash` + proof) to produce a tamper-evident DID Document history. |
| Use Case in UNTP | Digital Identity Anchors and institutional identifiers requiring auditability, traceability, and long-term trust. Supports continuity of identity even when domains change. |
| Advantages | Extends `did:web` with verifiable, append-only history of updates. Enables tamper-evident key rotation, continuity of trust, and portability between domains. Backward compatible with existing `did:web` resolvers when version history is ignored. |
| Known limitations | Still relies on HTTPS hosting and DNS domain ownership. More complex to implement due to the requirement to maintain a valid `did.jsonl` chain. Historical transparency may expose metadata about operational changes — privacy implications should be assessed per use case. |
| Implementation Notes | MUST be implemented where auditability of identity control is required (e.g. accredited data publishers, credential issuers). SHOULD maintain the `did.jsonl` file with proper version linking and proofs. Implementers SHOULD plan for domain portability using the `alsoKnownAs` and `newDomain` parameters. |

## Wallets and Presentations

The verifiable credentials ecosystem is typically designed around a model where a human **holder** stores credentials in a personal digital wallet and presents them to verifiers on demand. This works well for personal credentials such as driver's licenses or educational certificates, where the holder is a person who can actively participate in a presentation exchange.

UNTP operates in a fundamentally different context. The subject of most UNTP credentials is an **inanimate object** — a box of goods, a shipment of steel, a battery module. The box of goods cannot create verifiable presentations on demand, and the credential binding is to the identity of the goods rather than to a holder. Any party with access to the product identifier (via a barcode, QR code, or RFID tag) discovers credentials about that product through an [Identity Resolver](IdentityResolver.md). This is why UNTP's architecture centres on a resolver-based "pull" model rather than a wallet-based "push" model.

### Verifiable Presentations

A conformant UNTP implementation:

- MUST issue and publish product passports, product conformity credentials, and traceability events as verifiable credentials and MUST include the identifier of the goods within the VC subject.
- MAY exchange these and any other credentials as verifiable presentations in wallet-to-wallet transfers or any other method.

### Wallets

UNTP is **wallet-agnostic**. It neither mandates nor precludes the use of digital wallets for storing, managing, or exchanging verifiable credentials. Digital wallets are relevant in several legitimate implementation contexts — including organisational identity and accreditation presentation, regulatory compliance in wallet-mandated jurisdictions such as the EU Digital Identity (EUDI) Wallet, and business-to-business credential exchange as part of procurement or onboarding workflows. In these scenarios, wallets are one possible mechanism among several, complementing rather than replacing the resolver-based discovery model.

For detailed guidance on when and how to use digital wallets with UNTP, including design patterns and implementation considerations, see [Digital Wallets](../design-patterns/DigitalWallets.md).

## Roadmap

Future versions of this specification will

- Provide richer guidance on DID methods via a decision tree that helps to select the right method for the right purpose
- Address the proliferation of DID methods and their consolidation to meet specific business needs
- Provide guidance for different use cases (e.g. legal entities vs products)
- Provide guidance on selective redaction methods to better support confidentiality goals
- Provide timelines for transition between versions of technical specifications

---

## Technical Specifications

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

The UNTP specification defines a suite of interoperable digital credentials and discovery mechanisms that, together, enable verifiable supply chain transparency at scale. Each credential type is independently implementable and targeted at a specific supply chain role, but the real value emerges when multiple actors across a value chain each play their part — creating a connected graph of verifiable data that supports automated compliance assessment without any central authority or data store.

![UNTP Components](../assets/images/arch-untp-components.png)

## Credential Specifications

### For Producers and Manufacturers

Producers and manufacturers integrate DPP, DFR, and DTE credentials into their existing production management and ERP systems — either by building their own integration or because their business software provider has implemented UNTP credential support.

The [Digital Product Passport](DigitalProductPassport.md) (DPP) is issued by the shipper of goods and carries product identity, characteristics, and sustainability performance data for serialised products or product batches. It is deliberately lightweight, designed to carry the minimum data needed by downstream receivers — such as scope 3 emissions intensity or deforestation-free status — while linking to conformity credentials for independent verification and traceability events for supply chain visibility.

The [Digital Facility Record](DigitalFacilityRecord.md) (DFR) is issued by facility owners or operators and describes facility identity, location, ownership, and sustainability performance over defined reporting periods. Facilities typically hold multiple identifiers from different authorities, and the DFR allows each to resolve to the same authoritative facility record via the identity resolver infrastructure.

The [Digital Traceability Event](DigitalTraceabilityEvents.md) (DTE) records the lifecycle activities of products as lightweight verifiable credentials capturing the what, when, where, who, and how of supply chain events. Three event types — make, move, and modify — model any supply chain activity, enabling facility-level mass-balance assessment and full upstream traceability when linked to DPPs.

### For Conformity Scheme Owners

The [Conformity Vocabulary Catalog](ConformityVocabularyCatalog.md) (CVC) enables scheme owners and regulators to publish their rules, criteria, and scoring frameworks as machine-readable linked data vocabularies. When conformity criteria are published as unique digital objects, DPP claims can be unambiguously verified against conformity credentials and compared across different schemes — pushing complexity to scheme owners so that manufacturers and conformity assessment bodies have simpler, more consistent work.

### For Conformity Assessment Bodies

The [Conformity Credential](ConformityCredential.md) is issued by conformity assessment bodies (CABs) and provides independent, digitally verifiable assessments of products, facilities, or organisations against published standards and regulations. Each credential carries the assessor's accreditation, the reference scheme and profile, measured performance metrics, and a conformance determination — giving downstream verifiers high-confidence evidence to support the claims made in product passports and facility records.

### For Identifier Registers

The [Identity Resolver](IdentityResolver.md) (IDR) defines how existing identifier systems — business registers, product registries, facility cadastres — participate in a consistent discover-resolve-verify workflow. UNTP does not replace existing identifiers but builds upon them, enabling any identifier (whether registry-managed or self-issued as a DID) to resolve to verifiable data such as product passports, facility records, and conformity credentials.

### For Identity Authorities

The [Digital Identity Anchor](DigitalIdentityAnchor.md) (DIA) is issued by authoritative registers — national business registers, trademark offices, mining cadastres, accreditation bodies — and provides a digitally verifiable binding between a decentralised identifier (DID) and an authoritative registered identity. The DIA allows verifiers to confirm not only that a credential was issued by the controller of a DID, but that the DID controller is the genuine holder of a registered identity.

### Foundational Components

The following specifications provide the shared technical foundations and semantic building blocks used across all UNTP credential types.

The [Verifiable Credentials Profile](VerifiableCredentials.md) (VCP) specifies the W3C Verifiable Credentials and DID standards that underpin all UNTP credentials, ensuring that every credential is digitally signed, tamper-evident, revocable, and independently verifiable.

The [Decentralised Access Control](DecentralisedAccessControl.md) (DAC) specification defines patterns for balancing transparency with confidentiality. It provides six progressively stronger access control patterns — from anonymous public access through to decentralised authentication — that can be applied independently or in combination to meet each actor's data-sharing policies.

The [Core Vocabulary](CoreVocabulary.md) defines the shared classes and properties — such as Product, Facility, Party, Attestation, and Assessment — that are reused across all UNTP credential types, ensuring consistent semantics and interoperability.

The [Core Taxonomies](CoreTaxonomies.md) provide standardised classification schemes for conformity topics (what is being assessed) and performance metrics (how performance is measured), enabling automated comparison and aggregation of sustainability data across credentials and value chains.

## Beyond the Specification

The specification is the technical core of UNTP, but successful adoption depends on broader context. The following sections of this site provide complementary guidance.

- **[Governance](../governance)** — How the UNTP is developed, maintained, and versioned through an open, consensus-driven process.
- **[Best Practices](../design-patterns)** — Solutions for common supply chain challenges including transparency graphs, anti-counterfeiting, and chain-of-custody mass-balance allocation.
- **[Business Case](../business-case)** — The value proposition for industry and government, including cost-benefit analysis and adoption incentives.
- **[Tools and Support](../tools-and-support)** — Implementation guidance including how to test and verify your UNTP implementation.
- **[Implementations](../implementations)** — Registers of software providers, industry pilots, conformity schemes, identity registers, and other implementers — and how to register your own implementation.

---

## Extensions Methodology

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

***Normative***

This page describes the technical methodology for creating UNTP extensions. For the governance rules and registration process, see the [Community Extensions Register](../implementations/ext/) and its [registration guide](../implementations/ext/registration-guide.md). For sectoral collaboration and harmonisation, see [Sectoral Collaboration](../governance/sectoral-collaboration.md).

## Overview

UNTP is designed as a common core that is usable by any industry sector or in any regulatory jurisdiction. This extensions methodology describes how to extend UNTP to meet the specific needs of any industry sector or regulated market in such a way that the extension maintains core interoperability with any other extension. This cross-industry and cross-border interoperability is a core value of UNTP because almost every value chain will cross industry and/or national borders.

![ExtensionsMethodology](./ExtensionMethodology2.png)

In some cases, UNTP extensions are themselves UN projects - such as the extensions defined by the [UN critical raw materials traceability and transparency project](https://uncefact.github.io/project-crm/). In most cases however, industry sectors and/or national projects will govern their own extensions.

Anyone can take UNTP and extend it for any purpose. But for the extension to be registered as UNTP conformant, an extension MUST remain interoperable with UNTP. This is achieved by following the governance, methodology, and testing processes described below.

## Extension Governance

As shown in the diagram below, UNTP development follows the UN/CEFACT Open Development Process (ODP) and is maintained by a group of experts that are approved by their member state delegate. UNTP Intellectual Property is owned by the UN and the standard is available free for anyone to use. There are formal liaisons with other standards bodies including ISO so that UNTP remains aligned with similar initiatives.

![Extension Governance](ExtensionGovernance.png)

Registered UNTP extensions

- MUST follow an open and transparent development process that is open to participation from representative persons and organisations.
- MUST be freely available under a permissive or creative commons license.
- MUST be version managed (major.minor) and each extension version MUST state which UNTP major version from which it is derived.
- MUST be documented as a public website with reference-able URI for each specification component.

Since registered extensions have a clear vested interest in the ongoing development of UNTP, extension groups SHOULD nominate at least one member as a participant in the UNTP Technical Working Group.

## Extension Methodology

UNTP extensions must be interoperable with UNTP core. This means that a credential that conforms to a UNTP extension is also conformant with UNTP core. This requirement ensures that credentials issued in a specific industry or geographical context are still understandable across industry or geographic boundaries.

![Extension Methodology](ExtensionMethodology.png)

### Schema Extensions

UNTP credential JSON schema allow additional properties in most objects to provide flexibility to accommodate industry extensions.

**Core Principles:**

1. **Additive, Not Redefining**
   - Extensions MAY add new properties
   - Extensions MUST NOT change existing UNTP core properties
   - Extensions MUST NOT remove core properties

2. **Dual Validation**
   - Extension instances MUST validate against extension schema
   - Extension instances MUST validate against UNTP core schema
   - Both validations must pass

3. **Multiple Variants**
   - Extensions MAY define multiple credential variants
   - Example: Agriculture extension defines both livestock passport AND horticulture passport
   - Each variant extends the same UNTP core credential type

**Example: Adding Battery-Specific Properties**

**UNTP Core Digital Product Passport** (simplified):
```json
{
  "@context": ["https://www.w3.org/ns/credentials/v2",
               "https://test.uncefact.org/vocabulary/untp/dpp/0.6.0/"],
  "type": ["VerifiableCredential", "DigitalProductPassport"],
  "credentialSubject": {
    "product": {
      "name": "Product Name",
      "description": "Product description",
      "category": {...}
    }
  }
}
```

**Battery Extension Adds Specific Properties**:
```json
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://test.uncefact.org/vocabulary/untp/dpp/0.6.0/",
    "https://battery-extension.org/context/1.0/"
  ],
  "type": ["VerifiableCredential", "DigitalProductPassport", "BatteryPassport"],
  "credentialSubject": {
    "product": {
      "name": "Lithium-ion Battery Cell",
      "description": "High-density battery cell for EVs",
      "category": {...},
      "batterySpecifications": {
        "capacity": {"value": 75, "unit": "kWh"},
        "chemistry": "NMC811",
        "voltage": {"value": 400, "unit": "V"}
      }
    }
  }
}
```

### Vocabulary Extensions

Industry extensions will often leverage existing industry specific vocabularies. For example an agriculture extension may reference terms from [Codex Alimentarius](https://www.fao.org/fao-who-codexalimentarius/en/). This is achieved through JSON-LD @context files.

- Each credential defined by a UNTP extension MUST reference a JSON-LD @context file that defines all additional terms.
- JSON-LD @context files defined by a UNTP extension MUST NOT redefine terms in the corresponding UNTP @context file.
- External vocabularies referenced by UNTP extensions SHOULD be stable, version managed, and should not delete terms.

### Technical Reference: How Extensions Work

This section explains the mechanism that lets an extension add fields to a UNTP credential without breaking JSON Schema validation, JSON-LD expansion, or downstream linked-data consumers. Extension developers and UNTP-aware implementers who only want to tack on a few extra fields should both read this section.

#### The two layers that have to agree

A UNTP credential is validated at two layers, and any extension mechanism has to satisfy both:

- **JSON Schema** controls which properties are allowed on a given object. Open classes declare `additionalProperties: true`; closed classes declare `additionalProperties: false`.
- **JSON-LD** controls how each property name maps to an RDF IRI when the credential is expanded into a graph. A property name that cannot be resolved to an IRI is either silently dropped (default mode) or reported as an error (safe mode).

UNTP aligns the two layers: every class that is open at the JSON Schema layer also has a per-class `@vocab` fallback in the JSON-LD context, so unknown keys resolve to a stable IRI instead of being dropped.

#### Open vs closed classes

**Open classes** accept extension keys. The JSON Schema permits unknown properties, and the JSON-LD context declares a class-scoped `@vocab` that points at the class's own vocabulary page using the fragment form (for example `https://vocabulary.uncefact.org/untp/Product#`). Unknown keys become fragment identifiers on that page, which means the containing class's documentation is where an HTTP client lands when it tries to dereference an extension IRI — the class's vocabulary description serves as the explanation for why the fragment is not a curated term. The currently-open classes are:

Product, Facility, Party, CredentialIssuer, Entity, ConformityScheme, ConformityProfile, Criterion, Claim, Characteristics, ConformityAttestation, ConformityAssessment, Endorsement, ScoringFramework, Regulation, Standard, Material, Package, LifecycleEvent, MakeEvent, MoveEvent, ModifyEvent, RegisteredIdentity, Location, FacilityVerification, ProductVerification, plus the five credential wrappers (DigitalProductPassport, DigitalConformityCredential, DigitalFacilityRecord, DigitalIdentityAnchor, DigitalTraceabilityEvent).

**Closed classes** reject extension keys. These represent pure data shapes whose semantics are fully specified — adding a property would create ambiguity:

Measure, Dimension, Coordinate, Period, Address, Country, Classification, Score, Link, Image, PartyRole, SensorData, StandardAlignment, RegulatoryAlignment, Performance, IdentifierScheme, BitstringStatusListEntry, RenderTemplate2024, EventProduct, MaterialUsage, PerformanceMetric, ConformityTopic.

If you find yourself wanting to extend a closed class, extend the containing open class instead. For example, don't try to add a property to an embedded `Measure`; add a sibling property on the Product that carries the extra context.

#### Default behaviour: automatic per-class namespacing

An extension property added to an open class — with no special setup — expands into the class's synthetic namespace. For example, adding `partNumber` to a Product:

```json
{
  "type": ["Product"],
  "id": "https://manufacturer.example/p/42",
  "name": "Battery module",
  "partNumber": "BM-18650-3000"
}
```

produces the triple:

```
<.../p/42>
  <https://vocabulary.uncefact.org/untp/Product#partNumber>
  "BM-18650-3000" .
```

The extension key is preserved in the expanded graph, SPARQL and SHACL can target it, and safe-mode validation passes. Each class has its own namespace, so `partNumber` on a `Product` and `partNumber` on a `Material` land at different IRIs and never collide.

This default works for the 80% case where an implementer has one or two vendor-specific fields to add and does not maintain a formal vocabulary.

#### Preferred pattern: use your own vocabulary

If your extension is backed by a published industry or organisation vocabulary, redirect extension keys into that namespace by declaring a scoped `@context` inside the object and using a prefix:

```json
{
  "type": ["Product"],
  "id": "https://manufacturer.example/p/42",
  "name": "Battery module",
  "characteristics": {
    "@context": { "battery": "https://example-industry.org/battery/v1/" },
    "type": ["Characteristics"],
    "battery:batteryChemistry": "NMC 811",
    "battery:batteryCategory": "EV"
  }
}
```

Here, `battery:batteryChemistry` expands to `https://example-industry.org/battery/v1/batteryChemistry` — an IRI owned by the extension body, not by UNTP. The prefix declaration is local to the object; multiple prefixes can coexist in the same document.

This is the pattern extension working groups should document for their implementers. It keeps the extension's semantics under the extension owner's control rather than in UNTP's synthetic fallback namespace.

#### Curated terms always win

Extension keys never override curated UNTP terms. When the JSON-LD context defines a property explicitly (for example `name` on a Product expands to `https://schema.org/name`), that curated definition shadows the `@vocab` fallback. An implementer cannot inadvertently redefine a UNTP-standard term as something else — JSON-LD's `@protected` enforcement catches the attempt at context-loading time.

#### Promoting an extension to a curated UNTP term

If an extension property becomes widely adopted and standardisation is appropriate, the UNTP governance process may promote it to a curated term in a subsequent version of the core vocabulary. When this happens, the property's IRI changes:

- Before promotion: `https://vocabulary.uncefact.org/untp/Product#partNumber` (per-class synthetic fragment of the containing class's vocabulary page).
- After promotion: `https://vocabulary.uncefact.org/untp/partNumber` (curated core term).

This is a **breaking change** for existing consumers. Producers who had been using the extension key will emit the new IRI automatically once they upgrade the context version they reference, but graphs built from older credentials will still carry the old IRI. Treat extension-namespaced IRIs as stable within a specific UNTP context version but subject to rewrite at major version boundaries.

#### Validating extended credentials

Two tools in this repository check that extensions behave correctly:

- `node .claude/scripts/validate-artefacts.mjs` — runs JSON Schema validation AND JSON-LD expansion, including safe-mode. Extensions that would drop silently on expansion fail the safe-mode check.
- `node .claude/scripts/audit-context.mjs` — verifies the extension mechanism itself: that every open class in the context declares a correctly-namespaced `@vocab`, that property definitions are consistent, and that context terms resolve to ontology entries.

Extension developers SHOULD add their sample instances to the validator's `VALIDATIONS` array so the build catches regressions in their extension just like it does for core UNTP.

### Identifier Schemes

UNTP and it's extensions have a dependency on resolvable and verifiable identifiers. Industry extension will typically define specific identifier schemes (for products, facilities, and organisations) that are relevant for the specific industry and/or geography. For example, Australian livestock are identified by a [National Livestock Identifier](https://www.nlis.com.au/) that is carried as an RFID tag in the animal's ear.

- All identifier schemes used by registered UNTP extensions MUST be registered in the UNTP identifier scheme register.
- Identifiers used by UNTP extensions SHOULD be resolvable and verifiable as defined by the UNTP Identity Resolver specification.

### Conformity Criteria

UNTP is deliberately agnostic of specific standards and regulations. The generic `Declaration` object that is used by DPP, DFR, and DCC credentials is designed to support any conformity criteria defined by any standard or regulation. UNTP extensions, however, will normally agree a specific set of standards and regulations that are applicable in the extension context.

- UNTP extensions MUST list all relevant standards and regulations on the extension specification website.
- The specific conformity criteria within Standards and Regulations referenced by UNTP extensions SHOULD be reference-able as stable URIs.

## Extension Conformity Testing

Extension conformity testing ensures that:
- Extension credentials validate against both extension schema AND UNTP core schema
- Extension maintains interoperability with UNTP core
- Extension credentials are readable by other extensions
- Extension follows all methodology requirements

**Level 1: Schema Validation**
- Extension schema files MUST validate as proper JSON Schema
- Extension instances MUST validate against extension schema
- Extension instances MUST validate against corresponding UNTP core schema
- No validation errors allowed

**Tools**: Use UNTP Schema Validator at https://test.uncefact.org/test-untp-playground

**Level 2: Interoperability Testing**
- Extension credentials MUST be processable by UNTP core-compliant systems
- Extension-specific properties MUST NOT break core processing
- Extension credentials MUST render using UNTP generic rendering templates
- Credentials MUST be verifiable using standard VC verification libraries

**Tools**: Use UNTP Interoperability Test Suite at https://test.uncefact.org/

**Level 3: Cross-Extension Testing** (Recommended, not required)
- Test credential exchange with other registered extensions
- Verify supply chain data flows across extension boundaries

**Conformance Criteria**

To achieve UNTP conformance registration, extensions must:
- ✓ Pass all Level 1 schema validation tests
- ✓ Pass all Level 2 interoperability tests  
- ✓ Provide test report documenting results
- ✓ Include minimum 2 example credentials for each extension type
- ✓ Publish test cases on extension website
---

## Key Terms and Concepts

**JSON Schema**: A standard format for describing the structure and validation rules for JSON data.

**JSON-LD (JSON Linked Data)**: A method of encoding linked data using JSON. The @context file maps terms to URLs.

**@context file**: A JSON-LD file that defines the meaning of terms used in credentials.

**Verifiable Credential (VC)**: A tamper-evident credential with authorship that can be cryptographically verified.

**Schema Validation**: The process of checking whether a data instance conforms to schema rules.

**Interoperability**: The ability of different systems to exchange and use information.

**Identity Resolver**: A system that translates an identifier into a URL where information can be found.

**Conformity Criteria**: Specific requirements from standards or regulations that products/facilities must meet.

**Namespace**: A way to group related properties together to avoid naming conflicts.

**Extension Instance**: An actual credential (data) that follows an extension schema.

---

---

## Help and support

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

# Implementation Support

Implementing UNTP successfully depends on more than reading the specification. This page brings together the practical resources available to organisations at any stage of implementation — whether you are still assessing scope or actively building and testing.

## Community Support Channels

UNTP is developed and maintained as an open standard, and the community around it is the primary source of implementation support. Two channels are available:

**Slack** — The UN/CEFACT Slack workspace includes a dedicated UNTP channel where implementers, specification authors, and community members exchange questions, experience, and guidance. This is the fastest route to practical help. [Join the Slack workspace.](https://join.slack.com/t/uncefact/shared_invite/zt-43hn3irv4-jIynpESUeYaF9zIgqB~djA)

**GitLab** — The UNTP specification and open source reference implementations are hosted on GitLab. Issues, questions, and contributions can be raised directly in the repository. This is the appropriate channel for technical questions about the specification itself, bug reports, and proposed changes. [Visit the GitLab repository.](https://opensource.unicc.org/un/unece/uncefact/spec-untp)

## Finding Compatible Software and Services

The Implementations Register records organisations that have declared intent to implement or have active UNTP implementations. Three registers are relevant to organisations looking for compatible solutions and partners:

- [**Software Solutions**](https://untp.unece.org/docs/implementations/swi) — commercial and open source software products with UNTP support, including implementation scope and test status.
- [**Conformity Schemes**](https://untp.unece.org/docs/implementations/cvc) — scheme owners whose conformity criteria are digitally referenceable within UNTP credentials.
- [**Identifier Registers**](https://untp.unece.org/docs/implementations/idr) — identity register operators that have implemented the UNTP Identity Resolver and Digital Identity Anchor specifications.
- [**Community Extensions**](https://untp.unece.org/docs/implementations/ext) - current community UNTP extensions

Registering your own implementation — even at the intent stage — makes your organisation discoverable to potential pilots and partners.

## Mailing List

For less time-sensitive announcements, working group updates, and community news, the [UNTP mailing list](https://groups.google.com/g/transparency-uncefact) provides a lower-frequency alternative to Slack.

---

## Implementation Plans

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

UNTP is a collection of specifications that work together to enhance traceability and transparency in global supply chains. But each stakeholder type plays a different role and so will implement different subsets of UNTP. This page provides more specific implementation guidance for each stakeholder type. The [general steps](../tools-and-support/#has-five-simple-steps) of confirming business value, selecting components, implementing, testing, and registering apply to all and are not repeated here.

Stakeholders whose primary engagement is to **be listed in a UNTP register** (member associations defining extensions, identifier scheme operators, conformity scheme owners, software vendors) should follow the per-register registration guides. The other stakeholders — producers, regulators, conformity assessment bodies, consumers — have substantive implementation work that goes beyond registration; that work is described below.

## For Producers Manufacturers and Brands

Meet your supply chain due diligence obligations and provide evidence to your customers that allows them to meet their own obligations.

**Select your components from the registers**

|Component|Where to find it|
|--|--|
|Industry extension that defines the credential types and conformity criteria for your sector|[Extensions register](../implementations/ext/) — if no extension exists for your sector, lobby your member association to lead one|
|Software platform that issues UNTP credentials on your behalf|[Software register](../implementations/swi/) — or engage your ICT department to implement UNTP using the free [reference implementation](../tools-and-support/ReferenceImplementation.md)|
|Conformity scheme(s) that back your sustainability claims|[Conformity vocabulary catalogue](../implementations/cvc/) — references the criteria your CABs will assess against|
|Identifier scheme(s) for your products, facilities, and organisation|[Identifier scheme register](../implementations/idr/) — and request a [Digital Identity Anchor](../specification/DigitalIdentityAnchor.md) credential from each register that lists you|

**Issue and consume credentials**

|Step|Action|Outcome|
|--|--|--|
|1|Push your suppliers to issue UNTP [DPP](../specification/DigitalProductPassport.md), [DFR](../specification/DigitalFacilityRecord.md) with linked [DCC](../specification/ConformityCredential.md) credentials|Meet your supply chain due-diligence obligations|
|2|Issue a [digital facility record](../specification/DigitalFacilityRecord.md) for each facility you own/operate|Your customers can verify sustainability performance of your production facilities|
|3|Issue a [digital product passport](../specification/DigitalProductPassport.md) for each product (and optionally each export market) that you ship from your facilities|Your customers can verify sustainability performance of your products|
|4|Choose conformity assessment bodies that can issue [digital conformity credentials](../specification/ConformityCredential.md) that attest your conformance with relevant schemes and regulations|Prove your product and facility conformity|
|5a|Issue [digital traceability events](../specification/DigitalTraceabilityEvents.md) to link your manufactured products to the input components or materials used|Your customers can verify your product origin/traceability|
|5b|Where traceability information is commercially sensitive, request a trusted third party (eg a conformity assessment body or your member association) to assess traceability data and issue an independent guarantee of origin [conformity credential](../specification/ConformityCredential.md)|Your customers can trust an independent assessment of origin|
|6|Link the [Identity Anchor](../specification/DigitalIdentityAnchor.md) credentials issued to you by your national business/trademark/land registers (or by IDR-listed industry registers) to your issuer [decentralised identifier](../specification/DigitalIdentityAnchor#via-did-service-endpoint)|Reduce counterfeiting risk and prove your identity|

## For Member Associations

Activate your community to participate in transparent and traceable value chains by governing a UNTP [industry extension](../implementations/ext/) for your members.

The end-to-end methodology — including discovery, alpha, beta, and live phases, the role of pilot implementers, and how to scale across the membership — is described in the [Community Activation Program](../governance/CommunityActivationProgram). The technical registration steps for the extension itself are in the [extension registration guide](../implementations/ext/registration-guide.md).

## For Registry Operators

Empower your members with verifiable identity and identifiers as signposts to verifiable data.

Implement the [Identity Anchor](../specification/DigitalIdentityAnchor.md) and [Identity Resolver](../specification/IdentityResolver.md) specifications, then list your scheme in the [identifier scheme register](../implementations/idr/) so verifiers can confirm both that your members are who they claim to be and that your register itself is legitimate. The publishing checklist and continuous-observation rules are in the [identifier scheme registration guide](../implementations/idr/registration-guide.md).

## For Scheme Owners

Make compliance with your scheme digitally verifiable.

Describe your existing schemes and criteria as a digital [Conformity Vocabulary Catalog](../specification/ConformityVocabularyCatalog) so that issuers of [Product Passports](../specification/DigitalProductPassport.md) and CABs issuing [Conformity Credentials](../specification/ConformityCredential.md) can reference your criteria unambiguously. Publish sample DCCs that show CABs what conformant assessments against your scheme look like. The [conformity scheme registration guide](../implementations/cvc/registration-guide.md) describes the publishing requirements and the maturity levels (Level 1 → Level 3).

## For Regulators

Make compliance with your regulations digitally verifiable.

|Step|Action|Outcome|
|--|--|--|
|1|Publish your regulations and criteria as a [Conformity Vocabulary Catalog](../specification/ConformityVocabularyCatalog) and list it in the [CVC register](../implementations/cvc/)|Conformity criteria can be referenced by issuers of regulatory compliance claims in [Product Passports](../specification/DigitalProductPassport.md) and assessments in [Conformity Credentials](../specification/ConformityCredential.md)|
|2|Issue regulatory permits, licenses, and certificates as [Digital Conformity Credentials](../specification/ConformityCredential.md)|Exporters can prove their compliance to customers and other authorities|
|3|Establish a digital verification framework for imports including [Product Passports](../specification/DigitalProductPassport.md), [Conformity Credentials](../specification/ConformityCredential.md), and [Identity Anchors](../specification/DigitalIdentityAnchor.md)|Automate border compliance and risk assessments with higher identity integrity and reduced piggybacking|

## For Conformity Assessment Bodies

Make your third party conformity assessments digitally verifiable.

Issue [Digital Conformity Credentials](../specification/ConformityCredential.md) using [SWI-registered software](../implementations/swi/), referencing schemes and profile versions from the [CVC register](../implementations/cvc/) in `attestation.assessmentScheme`. Follow the sample DCCs published by the relevant scheme owner. CABs do not have their own register — DCCs are observed continuously via the issuing software's SWI-register entry.

## For Software Vendors

Empower your customers to participate in sustainable value chains. The [SWI registration guide](../implementations/swi/registration-guide.md) describes how to publish your vendor DID, embed the `issuingSoftware` block in every issued credential, and (optionally) stand up a binding-credential service. The implementation surface depends on your customer's role:

|Software type|Implementation focus|
|--|--|
|Verifiable credential / identity platforms|Support [Verifiable Credentials Profile](../specification/VerifiableCredentials) and [Digital Identity Anchor](../specification/DigitalIdentityAnchor) — provide the libraries other software vendors integrate|
|Traceability platforms|Follow links to find and verify [product passports](../specification/DigitalProductPassport), [facility records](../specification/DigitalFacilityRecord), [traceability events](../specification/DigitalTraceabilityEvents), and [conformity credentials](../specification/ConformityCredential) to construct [transparency graphs](../design-patterns/TrustGraphs) representing the n-tier traceable supply chain|
|Production Management Systems (PMS) or ERP systems|Issue [facility records](../specification/DigitalFacilityRecord), [product passports](../specification/DigitalProductPassport), and [traceability events](../specification/DigitalTraceabilityEvents) describing manufacturing facilities, manufactured products, and upstream materials|

## For Consumers

Scan data carriers, view digital product passports, make purchase decisions.

---

## Open Source Tools

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

# Reference Implementation

The following tools make up a reference implementation.  

| Tool          | Link     | Description              | Status   |
| ------------- | ------------- | ------------- | ------------- |
| UNTP Test Suite |  https://github.com/uncefact/tests-untp/tree/next/packages/untp-test-suite | Provides tooling for implementers to validate their DPP's across the 3 tiers (correct credential, correct schema, and correct choreography) | Active Development |
| Project VC Kit	 | https://github.com/uncefact/project-vckit | This is a tool that verifies and issues credentials.  | Active Development |
| Mock Apps | https://github.com/uncefact/tests-untp/tree/next/packages/mock-app | Tool to build testable supply chain implementations to enable testing and validation of your DPPs and supply chain | Active Development |
| Identity Resolver |  https://github.com/uncefact/project-identity-resolver | Tool that enables to go from the identifier to more information about the identified object including a DPP | Active Development |

---

## Test Services

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

Conformance testing is a requirement for [implementation registration](../governance/implementation-governance.md) — for software platforms, conformity scheme owners, conformity assessment bodies, identifier registers, and community extensions. This page describes the testing tools and architecture available to implementers.

## Test Playground

UNTP provides a test playground where implementers can

* Test their own credentials for conformity to UNTP standards.
* Access UNTP standard sample credentiuals.

There are two plaground instances - one for the current release and also one for the

### Current release playground

For testing against the current UNTP release version credential specifications.

URL: https://test.uncefact.org/test-untp-playground

### Latest bleeding-edge playground

For testing against the latest bleeding edge experimental versions.

URL: https://test.uncefact.org/untp-playground

## Full Test Service

The playgrounds are hosted implementations of the full UNTP test service which can be deployed locally 

Test documentation URL: https://uncefact.github.io/tests-untp/

## 3 Tier Test Architecture

There is a 3 tier testing architecture to help implementors ensure that they are issuing UNTP interoperable digital product passports.  This architecture also ensures that as implementors 'extend' the UN Transparecy Protocol they do that in a non-breaking fashion.

![Architecture for issuer](3tiertestarchitecture.png)

At each tier we articulate the specific testing for UNTP and for an extension.

### UNTP Testing (the blue sections in the diagram)

The UNTP testing is intended to provide implenentors the ability to validate that they have a complete valid reference implementation of UNTP.  This testing gives a starting point so that implenters know that their implemenation is starting as UNTP compliant and that any externsions that they make need to have validations added to ensure continued UNTP interoperability.

#### Tier 1: UNTP Test: Technology Interoperability Testing

This testing is intended to provide implementers confidence that the technical implementation is correct.  It is primarily focused on W3C verifiable credential compliance.

#### Tier 2: UNTP Test: UNTP Schema Testing

This tests that the schema that are being used to issue credentials are a valid UNTP schema.  This will enable an implementor to validate that they are starting with a valid UNTP set of schema.

#### Tier 3: UNTP Test: Trust Graph Testing

This validates that the links between the different components of the UNTP schema (DPP, DTE, DCC) are validated.  It is anticipated that this is relatively simple at generic UNTP level, but will get more involved for each extension.

### Extension Testing (grey boxes)

UNTP has been designed so that each industry and jurisdicton can extend UNTP to meet their specific busines, governance and community needs.  In order to ensure that supply chain customers downstream can consume details from their upstream supply chain partners - it is important that extensions maintain UNTP compliance.  Extension testing is intended to provide that confidence to implementors.

#### Tier 1: Extension Test: Nothing?

It is expected that there won't be changes at Tier 1 of the testing architecture for extensions.  This is because we are using W3C standards and if there are requirements for extenisons it is beyond the scope of UNTP to manage.  We are including it in the architecture to faciliate future unforeseen needs.

#### Tier 2: Extension Test:  Extension Schema Testing

This testing is designed to ensure that as implementors are extending UNTP schema (DPP, DTE, DCC) to meet their specific needs that they are not breaking compatibility with UNTP and that they are able to provide the implementors of their extensions with confidence that their extension is correct.

#### Tier 3: Extension Test:  Choreography Testing (Trust Graph Validation)

This provides the ability for extendors to map the different credentials together to validate specific industry or regional scenarios.  In Australia NATA is the national accrecditor for laboratories - so the link from NATA to an accredited laboratory to a specific accreditation would be validated by a test in this component.

---

## Implementation Guidance

import Disclaimer from '../\_disclaimer.mdx';

<Disclaimer />

## Implementation Of UNTP

Implementation of UNTP will be a very different experience for organisations of different size, industry/geography sector, and stakeholder type. The purpose of this page is to help potential implementers navigate quickly and simply to the relevant scope of work.

## Has Five Simple Steps

At a macro-level, there are just five steps for any UNTP implementer to follow.

|Step|Action|Outcome|
|--|--|--|
|1|Review the [business case](../business-case/) section to confirm that UNTP implementation is likely to deliver value for your organisation. Establish key performance measures to track costs and benefits.|Positive business case|
|2|Browse the [four UNTP registers](../implementations/) to select the components you'll build on — software, extensions, conformity schemes, and identifier schemes that already exist for your sector. Where a needed component is missing, raise it with the relevant community.|Implementation scope and components selected|
|3|Implement (or have your software vendor implement) the credentials relevant to your [organisation type](#organisation-type). Validate against the [UNTP test service](TestService.md) before going live, and use [support channels](HelpAndSupport.md) as needed.|Pre-production conformance evidence|
|4|Register the implementation in the appropriate UNTP register and run a pilot with any other registered implementer(s) to confirm interoperability and value. Contact [support](HelpAndSupport.md) to facilitate coordination of pilot activities.|Registered implementation and successful pilot|
|5|Ramp up to full production volumes, routinely issuing and verifying UNTP credentials. The registrar agent continuously observes your implementation and updates your registry status. Measure cost and benefit performance indicators to track ongoing value.|Continuously-observed conformant implementation; consider publishing your story as a UNTP case study|

## Details Vary With Your Context

### Organisation Size

* **Small businesses** (under 20 employees) are likely to find themselves using UNTP simply because their commercial off the shelf (COTS) business software system has implemented UNTP to support transparent digitalised supply chains. Just as small businesses make international payments without knowing anything about ISO-20022, so they would issue and verify digital product passports without knowing about UNTP. 
* **Medium businesses** (20 to 200 employees) will also be using commercial off the shelf software but are likely to have developed some customized solutions and internal integrations that mean UNTP implementation is not simply a case of just using compliant software. Some implementation and testing costs will be incurred.
* **Large enterprise** (over 200 employees) will usually have a complex ICT landscape with multiple systems and will usually need to engage their ICT department for a UNTP implementation. 

### Organisation Type

|Stakeholder|Implementation Scope|
|--|--|
|**[Producers, Manufacturers, and Brands](ImplementationPlans#for-producers-manufacturers-and-brands)** - produce raw materials, manufacture goods, own brands.  |**Implement UNTP Extensions** *Issue [Product Passports](../specification/DigitalProductPassport.md), [Facility Records](../specification/DigitalFacilityRecord.md), and [Traceability Events](../specification/DigitalTraceabilityEvents.md) according to guidelines specified in [industry extensions](ExtensionsMethodology.md) so that your customers can easily verify your compliance and meet their due diligence obligations* |
|**[Registry Operators](ImplementationPlans#for-registry-operators)** - Maintain authoritative registers of products, assets, facilities, and businesses. |**Implement UNTP Core** *Implement [Identity Resolver](../specification/IdentityResolver.md) and [Identity Anchor](../specification/DigitalIdentityAnchor.md) so that your registered members can prove their identity and link discoverable credentials such as [Product Passports](../specification/DigitalProductPassport.md), [Facility Records](../specification/DigitalFacilityRecord.md) to their product or facility identifiers.* |
|**[Conformity Assessment Bodies](ImplementationPlans#for-conformity-assessment-bodies)** - Provide test and certification services to certify compliance with recognised schemes and regulations|**Issue Conformity Credentials** *Issue [Digital Conformity Credentials](../specification/ConformityCredential.md) using [SWI-registered software](../implementations/swi/) referencing schemes from the [CVC register](../implementations/cvc/). CABs do not have their own register — credentials are observed via the issuing software.* |
|**[Member Associations](ImplementationPlans#for-member-associations)** - Represent and advocate for industry interests |**Create UNTP Extensions** *[Activate communities](../governance/CommunityActivationProgram) to participate in transparent and traceable value chains by governing the design and maintenance of UNTP [industry extensions](ExtensionsMethodology.md).*|
|**[Regulators](ImplementationPlans#for-regulators)** - Enforce compliance with laws and regulations. |**Implement UNTP Core** *Issue regulatory permits, licenses, and certificates as [Digital Conformity Credentials](../specification/ConformityCredential.md) so that exporters can prove their compliance to customers and other authorities. Also automate border compliance and risk assessments by verifying [Product Passports](../specification/DigitalProductPassport.md), [ Conformity Credentials](../specification/ConformityCredential.md) and [Identity Anchors](../specification/DigitalIdentityAnchor.md) that accompany imports*|
|**[Software Vendors](ImplementationPlans#for-software-vendors)** - Develop software solutions that underpin business operations and facilitate participation in transparent value chains. |**Implement UNTP Core** *Add support for [Verifiable Credentials](../specification/VerifiableCredentials.md) and [Decentralised Access Control](../specification/DecentralisedAccessControl.md) to software products and, depending on your target market, the ability to issue all UNTP credential types (DPP, DFR, DCC, DTE, DIA) including relevant industry specific [extensions](ExtensionsMethodology.md).*|
|**[Scheme Owners](ImplementationPlans#for-scheme-owners)** - Develop sustainability standards and associated assessment criteria |**Create Sustainability Vocabularies** *Describe your existing schemes and criteria as a digital [Conformity Vocabulary Catalog](../specification/ConformityVocabularyCatalog) so that your conformity criteria can be referenced by issuers of claims in [Product Passports](../specification/DigitalProductPassport.md) and assessments in [ Conformity Credentials](../specification/ConformityCredential.md).*|
|**[Consumers](ImplementationPlans#for-consumers)** - Choose, purchase and use products. |**Verify Sustainability Claims** *Scan data carriers, view digital product passports, make purchase decisions*|

### Industry and Geographic Sector

UNTP has been designed as an industry and geography agnostic standard - with a framework for multiple industry and/or geography specific extensions. This raises the question for implementers - whether to implement support for UNTP core or for specific industry extensions. The answer depends on your role.

* UNTP Core specifications are targeted at [Software Vendors](ImplementationPlans#for-software-vendors), [Registry Operators](ImplementationPlans#for-registry-operators), [Regulators](ImplementationPlans#for-regulators) and [Scheme Owners](ImplementationPlans#for-scheme-owners).
* UNTP [industry extensions](ExtensionsMethodology.md) are created by [Industry Associations](ImplementationPlans#for-member-associations) and implemented by [Producers, Manufacturers, and Brands](ImplementationPlans#for-producers-manufacturers-and-brands) that are members of the association using UNTP compliant software.

## And Some Key Dependencies

Whilst any individual industry actor can choose to implement UNTP in isolation, there are some important economies of scale that make implementation at scale far more feasible. The dependency map below shows UNTP specification elements in purple and stakeholder type in green with dependencies between them described by the arrows. The most important dependencies are highlighted in bold:

* A **UNTP Extension** adds industry specific needs to the generic **UNTP Core** specification and is best coordinated by a **Member Association** that creates the extension once for use by all members. 
* A **Software Vendor** such as a production management system implements UNTP within their software package once and it becomes available for use by all their **Industry** customers.
* A **Registry Operator** implements the UNTP **Identity Resolver** and **Identity Anchor** specification so that every identifier (of a product or facility) issued to any of their **Industry** members can be used as a pointer to the **Product Passport**
* A **Scheme Owner** specifies their rules as a **Sustainability Vocabulary** so that claims in **Product Passports** and assessments in **Conformity Credentials** can unambiguously reference the sustainability criteria. 

The focal point for coordinating the participation of Industry, Software Vendors, Registry Operators and Scheme Owners is the Member Association that creates a UNTP Extension

```mermaid
flowchart TD

    UNTP_Core --- |includes| Product_Passport
    UNTP_Core --- |includes| Conformity_Credential
    UNTP_Core --- |includes| Facility_Record
    UNTP_Core --- |includes| Traceability_Event
    UNTP_Core --- |includes| Identity_Anchor
    UNTP_Core --- |includes| Identity_Resolver
    UNTP_Extension --- |extends| UNTP_Core
    Software_Vendor --- |implements| UNTP_Core
    Sustainability_Vocabulary --- |Defined by| Scheme_Owner
    Industry --- |uses| Software_Vendor
    Industry --- |implements| UNTP_Extension
    Industry --- |issues| Product_Passport
    Industry --- |issues| Traceability_Event
    Industry --- |issues| Facility_Record
    Industry --- |references| Conformity_Credential
    Industry --- |identified by| Identity_Anchor
    Industry --- |specifies links| Identity_Resolver
    Member_Association --- |creates| UNTP_Extension
    Registry_Operator --- |implements| Identity_Resolver
    Registry_Operator --- |implements| Identity_Anchor
    Registry_Operator --- |has members| Industry
    Member_Association --- |has members| Industry
    Conformity_Credential --- |issued by| Conformity_Assessment_Body
    Conformity_Credential --- |references| Sustainability_Vocabulary
    Product_Passport --- |references| Sustainability_Vocabulary
    Conformity_Assessment_Body --- |accredited by| Scheme_Owner
    Identity_Resolver --- |links to| Product_Passport
    Identity_Resolver --- |links to| Traceability_Event
    Identity_Resolver --- |links to| Conformity_Credential
    Identity_Resolver --- |links to| Facility_Record

    classDef untp fill:#a9f;
    classDef specification fill:#f9f;
    classDef stakeholder fill:#7e7;
    class UNTP_Core,UNTP_Extension untp;
    class Conformity_Credential,Product_Passport,Facility_Record,Traceability_Event,Identity_Anchor,Identity_Resolver specification,Sustainability_Vocabulary;
    class Software_Vendor,Registry_Operator,Member_Association,Industry,Scheme_Owner,Conformity_Assessment_Body stakeholder;
    linkStyle 6,7,8,9,10,16,17,20,21,24,26 stroke-width:4px;

```