Implementation Registers Architecture

info

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

The implementation governance layer is organised as four registers — the technical roots of the UNTP 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.

Register status is the observed conformance of a listed implementation (software, extension, scheme, or identifier service). It is not the UNTP specification version. Which spec version is current, frozen, or unmaintained is recorded on the Documentation Versions page and in Version Management.

The four registers

Register	Catalogues	What the implementer publishes	What the agent verifies
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
CAP register — 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 — 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
ISR — 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 Identity Resolver (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. ISR is the Identifier Scheme Register. IDR is the Identity Resolver protocol; optional "UNTP IDR conformance" in the table above means a scheme's resolver implements that protocol.

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.

What registration means — and what it does not

A register entry records observed technical conformance: that signatures verified, schemas validated, vocabularies resolved, and services responded, as at the last observation cycle. It is not an endorsement, certification, or accreditation by UNECE, and it says nothing about the commercial standing of the registered party or the truth of the business claims inside the credentials they issue. No inference beyond observed technical conformance should be drawn from the fact that a party appears in a register, and each entry's lifecycle status distinguishes declared intent (proposed, planned) from tested production reality (pilot, active, conformant).

Loss of recognition is automatic rather than committee-driven. Because status is derived from rolling observations, an implementation that stops conforming — silent schema changes, broken resolvers, unsigned credentials, forged software claims — degrades on the next cycle without any human decision to "revoke" it. Verifiers see the current status and the signed observation history behind it, not a one-time seal of approval.

Technical conformance and truthful content are different properties, and the registers only police the first. A credential can validate perfectly and still carry a false claim. Deliberately misleading or fraudulent data is a matter for the scheme owners whose vocabularies are misused, and for regulators under the applicable law of the relevant jurisdiction — see Sovereignty and Jurisdiction. What the registers contribute to that process is evidence: an append-only, registrar-signed observation history that no party, including UNECE, can quietly rewrite.

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	Register your software	SWI governance
EXT — Community Extensions	Community Activation Register	Register an extension	EXT governance
CVC — Conformity Vocabulary Catalogue	Scheme owners register	Register a scheme	CVC governance
ISR — Identifier Schemes	Identifier registers	Register an identifier scheme	ISR governance

Conformity Assessment Bodies

Conformity assessment bodies (CABs) — auditors, certifiers, testing laboratories, and inspection bodies — issue Digital Conformity Credentials (DCCs) 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 ISR-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 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 (ISR). 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 ISR-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 ISR/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 ISR 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 and the locally deployable full test service are for implementers to validate their work during development, before publishing anything. The playground exercises the same three-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.