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.

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

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

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.

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) — the registrar agent uses identifier schemes registered here to discover credentials.
• Conformity Vocabulary Catalogue Register (CVC) — vocabulary validation in the observation cycle uses schemes registered here.
• Credential Extensions Register (EXT) — 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.