Standards register

This register lists every standard the registry stack touches, the projects that touch it, and the claim level that names how strong the relationship is. The registry stack does not introduce a new standard; each project emits, maps to, or aligns with existing ones, and says so explicitly.

The table is generated from src/data/standards.yaml.

Register

DCAT and DCAT-AP

dcat

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-manifest

Surface

metadata rendering catalog JSON-LD access service metadata

DCAT 3 plus DCAT-AP profile usage

Relay and Manifest emit DCAT-shaped metadata. Conformance claims require profile-specific validation evidence.

Evidence

• Registry Relay README
• Registry Manifest README

BRegDCAT-AP

bregdcat-ap

Status

used · 2026-05-25

Claim level

emits

Used by

registry-relay registry-manifest

Surface

business registry catalog metadata embedded SHACL entity shapes

BRegDCAT-AP 2.00 render surface

Manifest and Relay emit BRegDCAT-shaped registry and data-service metadata. CPSV-AP is now the service-discovery layer; BRegDCAT-AP remains the registry and data-service discovery layer. Later BRegDCAT-AP releases require a separate renderer review.

Evidence

• Registry Relay README
• Registry Manifest README

Core Public Service Vocabulary Application Profile

cpsv-ap

Status

used · 2026-05-25

Claim level

emits

Used by

registry-manifest registry-atlas registry-lab

Surface

public service catalogue rendering service-first discovery channel and form linking competent authority and requirement links

CPSV-AP 3.2.0

Registry Manifest emits CPSV-AP service catalogues. Registry Atlas consumes them for service-first discovery; Registry Lab demonstrates the flow with static metadata.

Evidence

• Registry Manifest CPSV-AP fixture
• Registry Atlas service-first spec
• Registry Lab service-first discovery docs

OGC API Records

ogc-api-records

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-manifest

Surface

dataset catalogue discovery OGC records item bodies

OGC API Records

Relay exposes records routes behind the ogcapi-records feature, and Manifest renders OGC records artifacts.

Evidence

• Registry Relay README
• Registry Manifest README

OGC API Features

ogc-api-features

Status

referenced · 2026-05-23

Claim level

aligns_with

Used by

registry-relay

Surface

standards adapter discussion

OGC API Features

Listed as an optional standards integration. Keep the claim below implementation until route evidence is pinned.

Evidence

• Registry Relay README

OpenAPI

openapi

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-notary

Surface

generated API reference Redoc publication

OpenAPI 3.x

Relay and Notary generate OpenAPI. These docs publish pinned artifacts through Redoc.

Evidence

• Registry Relay README
• Registry Notary README

SHACL

shacl

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-manifest

Surface

validation workflow entity node shapes

SHACL Core

Relay docs describe SHACL validation and Manifest renders SHACL.

Evidence

• Registry Relay README
• Registry Manifest README

JSON Schema

json-schema

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-manifest

Surface

entity schema documents static publication bundle

Draft 2020-12

Manifest renders entity JSON Schemas and Relay exposes entity schema endpoints.

Evidence

• Registry Relay README
• Registry Manifest README

JSON-LD

json-ld

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-manifest registry-notary

Surface

catalog JSON-LD CPSV-AP service catalogue JSON-LD policy JSON-LD CCCEV render output provenance contexts

JSON-LD 1.1

The projects emit JSON-LD artifacts and contexts. No broad RDF dataset conformance claim is made here.

Evidence

• Registry Relay JSON-LD renderers
• Registry Notary CCCEV renderer

SD-JWT VC

sd-jwt-vc

Status

used · 2026-05-24

Claim level

emits

Used by

registry-notary registry-platform

Surface

credential issuance selective disclosure contracts shared SD-JWT VC issuance and holder-proof helpers

Draft SD-JWT VC usage

Registry Platform owns reusable SD-JWT VC issuance and holder-proof helpers. Registry Notary owns the claim-to-credential workflow and service routes that use them.

Evidence

• Registry Notary README
• Registry Platform SD-JWT crate

Verifiable Credentials Data Model

verifiable-credentials

Status

referenced · 2026-05-23

Claim level

aligns_with

Used by

registry-relay registry-notary

Surface

provenance contexts static VC fixtures credential issuance positioning

Verifiable Credentials Data Model 2.0

Relay has VC-oriented provenance fixtures and contexts, and Notary issues SD-JWT VC. Keep this below an emits claim until a reviewed VC profile and validation fixtures are pinned.

Evidence

• Registry Relay provenance context tests
• Registry Relay VC fixtures
• Registry Notary README

Core Criterion and Core Evidence Vocabulary

cccev

Status

used · 2026-05-25

Claim level

emits

Used by

registry-manifest registry-notary registry-atlas registry-lab

Surface

requirement and information requirement metadata evidence type and evidence type list metadata grouped evidence option discovery claim result rendering evidence node JSON-LD

CCCEV 2.2.0

Manifest emits CCCEV requirement and evidence type list metadata. Atlas treats each EvidenceTypeList as one grouped option and multiple lists as alternatives. Notary renders CCCEV-shaped claim results. Profile conformance is not claimed.

Evidence

• Registry Manifest grouped evidence fixture
• Registry Atlas service-first navigation API
• Registry Notary CCCEV renderer
• Registry Notary media type constants

ODRL

odrl

Status

used · 2026-05-23

Claim level

emits

Used by

registry-relay registry-manifest

Surface

dataset-scoped offers policy documents

ODRL Information Model

Relay catalog JSON-LD can include dataset-scoped ODRL Offers; Manifest renders policies. Policies are published as metadata; Relay does not evaluate or enforce them at runtime.

Evidence

• Registry Relay README
• Registry Manifest README

PROV-O

prov-o

Status

referenced · 2026-05-23

Claim level

inspired_by

Used by

registry-relay registry-notary

Surface

provenance model discussion provenance-shaped audit and claim fields

PROV-O

The code uses provenance concepts, but current evidence does not show a PROV-O vocabulary emission surface. Keep this as design influence until PROV-O terms are emitted or mapped.

Evidence

• Registry Relay provenance configuration
• Registry Notary claim model

GovStack Digital Registries Building Block

govstack-digital-registries

Status

evaluated · 2026-05-23

Claim level

compares_against

Used by

registry-relay

Surface

product positioning capability boundary

Digital Registries Building Block

Relay explores a protected consultation gateway model rather than the current single uniform CRUD platform.

Evidence

• Registry Relay README

Social Protection Digital Convergence Initiative

sp-dci

Status

referenced · 2026-05-23

Claim level

maps_to

Used by

registry-relay registry-notary

Surface

optional sync adapter HTTP source connector

Optional sync adapter and source connector

Relay exposes an SP-DCI sync adapter behind `spdci-api-standards`. Notary ships an HTTP source connector that maps SP-DCI search and sync responses into claim evaluation inputs.

Evidence

• Registry Relay README
• Registry Notary source connector

OpenID for Verifiable Credential Issuance

oid4vci

Status

used · 2026-05-25

Claim level

emits

Used by

registry-notary registry-platform registry-lab

Surface

credential offer endpoint nonce endpoint credential issuance endpoint issuer metadata at `/.well-known/openid-credential-issuer` wallet-facing citizen self-attestation flow

OID4VCI Draft 13 compatible

Registry Notary exposes the OID4VCI credential offer, nonce, credential, and issuer-metadata routes. Registry Platform owns the underlying primitives in the `registry-platform-oid4vci` crate. Registry Lab exercises the full flow through the `just citizen-oid4vci-*` recipes. Conformance to the full OID4VCI profile is not asserted; the surfaces emit the protocol shape and have been validated against the lab smoke script.

Evidence

• Registry Notary OID4VCI routes
• Registry Platform OID4VCI crate
• Registry Lab citizen OID4VCI smoke script

W3C Decentralized Identifiers (DID Core)

w3c-did

Status

used · 2026-05-24

Claim level

implements

Used by

registry-relay registry-notary registry-platform

Surface

did:web document publication did:jwk parsing for credential subjects issuer identifier handling shared DID validation and Ed25519 JWK helpers

DID Core 1.0 with did:web and did:jwk methods

Relay publishes a did:web document, Notary parses did:jwk values for credential subjects, and Platform owns shared DID and Ed25519 JWK helpers. The site does not claim conformance to the wider DID method registry beyond did:web and did:jwk.

Evidence

• Registry Relay did:web document builder
• Registry Relay DID route
• Registry Notary did:jwk handling
• Registry Platform crypto crate

Generated from src/data/standards.yaml.

Claim levels

Six levels in descending strength:

• implements: the project implements a normative requirement or API shape from the standard.
• emits: the project produces artifacts shaped like the standard (JSON-LD, SHACL, OpenAPI, catalog records).
• maps_to: local concepts or fields are mapped to the standard.
• aligns_with: the project follows the model or intent without claiming formal conformance.
• inspired_by: the standard influenced design without any compatibility claim.
• compares_against: the standard is discussed to explain boundaries or alternatives.

What these levels mean for integrators:

• emits: you can parse that project’s output as the standard expects. Fixtures or generated artifacts back the claim.
• aligns_with: the project uses the vocabulary and intent of the standard but does not guarantee strict conformance. Do not write a validator against the spec without reading the surface notes.
• implements: a normative requirement is met; you can rely on the API shape.
• inspired_by or compares_against: design context only, no interoperability claim.

Column guide

• Standard links to the official standards body page.
• Status is one of used, referenced, evaluated, planned, or historical.
• Used by lists the registry stack projects that reference this standard.
• Claim level uses the six levels defined above.
• Surface names the specific output or endpoint that the claim applies to.
• Profile and notes identifies the version or profile in use and any boundary conditions.
• Evidence links to the source code, fixture, or document that supports the claim.

Gaps

• OGC API Features is listed as aligns_with (referenced). Route evidence has not been pinned to a specific commit. Promote to emits only after src/api/ogc/features.rs is exercised by an integration test.
• The Verifiable Credentials Data Model (W3C VC) is listed as aligns_with (referenced). Registry Relay has VC-oriented provenance fixtures and Registry Notary issues SD-JWT VC credentials, but neither project emits a full W3C VC Data Model envelope. Promote when a reviewed VC profile and validation fixtures are pinned.
• PROV-O is listed as inspired_by (referenced). The code uses provenance-shaped concepts (audit fields, claim provenance struct) but no PROV-O vocabulary terms are emitted as JSON-LD.