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.

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

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

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.

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