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.

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

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.

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