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.

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 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.

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

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.

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) — 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) — extensions may rely on registered identifier schemes for product/facility/party IDs.
• Conformity Vocabulary Catalogue Register (CVC) — 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.