Standards register
This register lists every standard Registry Stack touches and the projects that touch it. It records
each relationship using one of six explicit claim levels: implements, emits, maps_to,
aligns_with, inspired_by, or compares_against. Registry Stack does not introduce a new
standard.
The table is generated from src/data/standards.yaml.
For selected external validator results, see ITB and SEMIC evidence.
Historical Relay profiles
Section titled “Historical Relay profiles”Registry Relay previously carried bounded GeoJSON, JSON-FG, and SDMX publication profiles. Those profiles ended with Registry Stack 0.38.0 and remain in this register as historical relationships. No maintained product replaces or claims conformance for those publication surfaces. The retirement decision records the boundary.
Register
Section titled “Register”DCAT and DCAT-AP
dcatDCAT 3 plus DCAT-AP profile usage
Registry Manifest emits DCAT-shaped metadata. Profile conformance claims still require profile-specific validation evidence; no DCAT validator output is pinned.
BRegDCAT-AP
bregdcat-apBRegDCAT-AP 2.00 render surface
Registry Manifest emits BRegDCAT-shaped registry and data-service metadata. CPSV-AP is the service-discovery layer; BRegDCAT-AP remains the registry and data-service discovery layer. Later BRegDCAT-AP releases require a separate renderer review.
Core Public Service Vocabulary Application Profile
cpsv-apCPSV-AP 3.2.0
Registry Manifest emits CPSV-AP service catalogues.
OGC API Records
ogc-api-recordsOGC API Records (no numbered spec version asserted; URL-pinned)
Registry Manifest renders and publishes static OGC Records item collections, and those link-free Records metadata artifacts are stable for 1.0.
OGC API Features
ogc-api-featuresOGC API Features (no numbered spec version asserted; URL-pinned)
No maintained Registry Stack surface implements OGC API Features. The feature-gated routes belonged to the retired Relay V1 runtime and the pinned V1 tests are the record of them.
OGC API Environmental Data Retrieval
ogc-api-edrOGC API EDR (no numbered spec version asserted; URL-pinned)
No maintained Registry Stack surface implements OGC API EDR. The area routes belonged to the retired Relay V1 runtime and the pinned V1 tests are the record of them.
OpenAPI
openapiOpenAPI 3.1.0; Evidence services publish fixed generated contracts
Evidence Gateway and its separate OID4VCI supporting service each generate a fixed OpenAPI 3.1.0 contract. The Registry Notary link stays pinned as the record of a retired product, not as a surface an adopter can run.
GeoJSON
geojsonRFC 7946
The maintained Registry Stack has no GeoJSON service surface. Registry Relay emitted a bounded GeoJSON Point profile through v0.38.0.
OGC Features and Geometries JSON
json-fgJSON-FG 1.0
The maintained Registry Stack has no JSON-FG service surface. Registry Relay emitted a bounded JSON-FG Point profile through v0.38.0.
Statistical Data and Metadata eXchange (SDMX)
sdmxHistorical Relay read subset
The maintained Registry Stack has no SDMX service surface. Registry Relay exposed a bounded read profile through v0.38.0.
GovStack Digital Registries Building Block
govstack-digital-registriesHistorical Relay comparison
Registry Relay carried a directional comparison through v0.38.0. No maintained Registry Stack product claims this alignment target.
SHACL
shaclSHACL Core
Registry Manifest renders SHACL from a manifest. No SHACL validator run against the emitted shapes is pinned.
Simple Knowledge Organization System
skosSKOS Reference codelist concept-scheme profile
Registry Manifest emits flat SKOS-shaped `skos:ConceptScheme` and `skos:Concept` nodes for manifest codelists inside SHACL and BRegDCAT/DCAT-shaped outputs. It does not yet publish a standalone SKOS artifact or claim full SKOS conformance.
JSON Schema
json-schemaDraft 2020-12
Registry Manifest renders entity JSON Schemas; the pinned fixture declares Draft 2020-12.
JSON-LD
json-ldJSON-LD 1.1
Registry Manifest renders JSON-LD artifacts, and a pinned fixture is cited as a concrete emitted artifact. No broad RDF dataset conformance claim is made here.
OpenID for Verifiable Credential Issuance
oid4vciOpenID for Verifiable Credential Issuance 1.0 Final, frozen Registry pre-authorized-code profile
The separate `registry-evidence-oid4vci` supporting service implements a frozen subset of OID4VCI 1.0 Final for holder-bound Evidence credentials. The profile permits issuer-initiated anonymous pre-authorized-code delivery, a stateless nonce, ES256 JWT proofs with an inline public JWK or self-contained `did:jwk#0`, and plural `dc+sd-jwt` credentials. It excludes authorization code, PAR, DPoP, remote DID resolution, other credential formats, deferred issuance, notifications, status or revocation, persistence, and multiple replicas. This is a profile implementation claim, not full issuer certification or conformance. Exact pinned source-level interoperability and the sanitized Registry flow passed. This is not OpenID certification, device or UI evidence, compatibility with other revisions, or general Inji compatibility.
SD-JWT VC
sd-jwt-vcRFC 9901 and `draft-ietf-oauth-sd-jwt-vc-18`, under the frozen Evidence audience-scoped and holder-bound profiles
Registry Platform owns reusable SD-JWT VC issuance and holder-proof helpers. Evidence Gateway serializes its stateless assertion as an SD-JWT VC under its own frozen profile, and that profile is the source of truth for the claim set it emits. Two subject binding modes exist. Under the default audience-scoped mode the credential is meaningful only to the relying party the assertion names, and a caller-supplied holder key is echoed into `cnf` unverified. Under the declared holder-bound mode the binding derives from the RFC 7638 thumbprint of the holder key, `cnf` is required, and possession is proven at presentation by a key-binding JWT under RFC 9901 section 4.3 rather than by the audience at issuance. Verifying a key-binding JWT proves possession at signing time over the presented bytes; comparing its nonce is not consuming it, so nothing here is replay prevention. Both profiles and the strict verification policy are frozen and citable. Evidence signs issuer JWTs with ES256 over P-256. Evidence confirmation keys, RFC 9901 key-binding JWTs, and OID4VCI proofs use ES256 over P-256. Registry Platform also retains a generic EdDSA holder-proof helper, but that is not the Evidence holder-bound presentation path. Registry Notary is retired; its pinned conformance profile and format constants remain historical evidence. Full SD-JWT VC conformance is not claimed. Wallet-facing OID4VCI delivery belongs to the separate `registry-evidence-oid4vci` front end.
Verifiable Credentials Data Model
verifiable-credentialsVerifiable Credentials Data Model 2.0
Evidence emits and the OID4VCI service transports an IETF draft-18 SD-JWT VC. That format is not a W3C Verifiable Credentials Data Model 2.0 document. No maintained component emits a W3C VCDM 2.0 envelope. The retired Notary alignment remains historical evidence only.
Core Criterion and Core Evidence Vocabulary
cccevCCCEV 2.2.0
Manifest emits CCCEV requirement and evidence type list metadata. The pinned Notary renderer and media type constants record the CCCEV-shaped claim results of a retired product. Profile conformance is not claimed.
ODRL
odrlODRL Information Model 2.2; emitted policies use ODRL Vocabulary terms
Registry Manifest renders ODRL policy metadata. That publication surface is descriptive and is not itself an access grant. The retired `registry-platform-pdp` crate is removed; Registry Manifest retains the enforcement profile vocabulary, including `odrl:purpose` and `odrl:spatial`, as descriptive metadata, so nothing in the stack enforces an ODRL term today. The technical identifier remains `registry-evidence-gateway-pdp/v1` for compatibility and does not name the Evidence Gateway product.
PROV-O
prov-oPROV-O
The pinned claim model belongs to Registry Notary, which is retired. Provenance concepts shaped that model, but no PROV-O vocabulary emission surface was shown then and no service in this register claims one now. Keep this as design influence until PROV-O terms are emitted or mapped.
HL7 FHIR
fhir-r4FHIR R4 (no profile implemented)
No maintained Registry Stack surface parses or serves FHIR. Evidence Gateway's frozen fixed-source contract accepts `application/json`, not `application/fhir+json`, so FHIR compatibility runs through a local read-through adapter the operator writes. That adapter and its profile-specific matching are project code, not a Registry Stack surface. Registry Stack has never claimed to implement a FHIR server or broad FHIR conformance.
Universal DPI Safeguards Framework
universal-dpi-safeguardsUniversal DPI Safeguards Framework version 2.0 (governance framework; no numbered technical specification asserted)
The framework is a governance instrument, not a technical specification, so no conformance is claimed. The alignment page compares stack capabilities against selected Framework 2.0 principles and pathways at the technical implementation layer and states explicitly that alignment is not certification.
Social Protection Digital Convergence Initiative
sp-dciSP-DCI (no spec version asserted; URL-pinned)
No maintained Registry Stack surface speaks SP-DCI. The pinned retired fixture records an earlier comparison only.
W3C Decentralized Identifiers (DID Core)
w3c-didDID Core 1.0 boundary around self-contained did:jwk
The OID4VCI supporting service accepts a self-contained did:jwk#0 proof-key reference, decodes it locally as an ES256 P-256 public key, and never performs remote resolution. Platform retains shared DID and JWK helpers, while the pinned Notary route is historical. No current service publishes a DID document or operates a general DID resolver, and no DID Core conformance class is claimed.
Generated from src/data/standards.yaml.
Claim levels
Section titled “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: the named output is shaped according to the stated standard or profile. Read the row’s notes and evidence before assuming validator conformance.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: only the named normative requirement or API surface, within the stated profile and evidence boundary, is implemented.inspired_byorcompares_against: design context only, no interoperability claim.
Column guide
Section titled “Column guide”- Standard links to the official standards body page.
- Status is one of
used,referenced,evaluated,planned, orhistorical. - Used by lists the registry stack projects covered by the displayed claim level.
- Claim level uses the six levels defined in Claim levels.
- 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.
Scope boundaries
Section titled “Scope boundaries”- OGC API Features, OGC API EDR, GeoJSON, JSON-FG, SDMX, HL7 FHIR R4, and SP-DCI are historical or comparison-only Relay relationships. No maintained runtime claims those surfaces.
- OGC API Records stays at
emitsbecause Registry Manifest publishes static Records item collections. - ODRL is still emitted by Registry Manifest as policy metadata, and that metadata is descriptive
rather than an access grant. No maintained runtime enforces an ODRL constraint. The governed
evaluation path belonged to Relay V1. Its
registry-platform-pdpcrate was removed; Registry Manifest retains the descriptive vocabulary it validates. - The CCCEV row’s
emitsclaim applies to Registry Manifest. Evidence Gateway separatelymaps_toCCCEV fields under its frozen assertion profile and does not emit a CCCEV document. - Evidence Gateway emits an IETF SD-JWT VC under its frozen draft-18 profile, and the separate OID4VCI supporting service transports it. This is not a W3C Verifiable Credentials Data Model 2.0 envelope. No maintained component emits a W3C VCDM 2.0 document.
- 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.