RS-TERMS: Terms and abbreviations
This document establishes the shared vocabulary for the registry stack formal specification layer. It defines terms used normatively in other specifications, records the product names and their repository identifiers, and maps the external standards that the stack’s own terms extend or adopt. Implementors, auditors, and governance teams who read or write registry stack specifications SHOULD treat the definitions here as binding, and a specification SHOULD cite RS-TERMS when referencing a defined term rather than re-defining it locally.
REQ-TERMS-001: The definitions in this document apply wherever a registry stack specification uses the term. A specification SHOULD cite RS-TERMS when importing vocabulary defined here.
Version history
Section titled “Version history”| Version | Date | Status | Change |
|---|---|---|---|
| 0.1.0 | 2026-06-13 | draft | Initial terms, distilled from the documentation glossary. |
| 0.2.0 | 2026-06-13 | draft | Added the adoption mode term (Section 3) and the documentation declaration terms, layer and audience (Section 6). |
1. Products
Section titled “1. Products”The five related projects that form the registry stack are listed below. Product names are Title Case. Repository slugs appear in monospace and are always lowercase. The phrase “registry stack” (lowercase) refers to the five-project ensemble.
Registry Platform (registry-platform): Shared Rust workspace for registry security and operational primitives, including auth helpers, OIDC verification, audit envelopes, HTTP security, outbound HTTP policy, crypto, Selective Disclosure JWT Verifiable Credential (SD-JWT VC) helpers, and test fixtures. Consumed by both runtime services.
Registry Relay (registry-relay): Config-driven Rust service that turns sensitive government tabular files and database tables into protected, read-only, domain-oriented consultation APIs.
Registry Manifest (registry-manifest): Rust workspace for modeling, validating, and rendering standards-facing service, registry, form, and policy metadata without running Registry Relay. Provides a library (registry-manifest-core) and a command-line interface (registry-manifest-cli).
Registry Notary (registry-notary): Standalone Rust service for claim evaluation, disclosure policy, credential issuance, and audit. Decoupled from Registry Relay application code by design, while sharing Registry Platform primitives.
Registry Lab (registry-lab): Compose-based runnable local demonstration that starts three Registry Relay instances, four Registry Notary instances, live Postgres and Zitadel services, a private OpenFn sidecar path, a static metadata publisher, and narrated clients.
2. Protocol and credential terms
Section titled “2. Protocol and credential terms”claim evaluation: The Registry Notary process that evaluates configured evidence rules against data from one or more source services and returns a structured claim result. Registry Stack product term.
evidence claim: A verifiable claim, attestation, credential claim, or status assertion that Registry Notary evaluates from configured sources. Registry Stack product term.
disclosure profile: Registry Notary control over what the caller receives from a claim evaluation result: Value (full value disclosed), Predicate (only true/false satisfaction), or Redacted (value fully hidden). Registry Stack product term.
holder: The party that holds a credential in a wallet and presents it to a verifier. Registry Notary binds each credential to a holder key (did:jwk) in the cnf claim, so only the holder can present it.
wallet: A holder-owned application that stores credentials and presents them to verifiers. Registry Notary issues credentials; the wallet that stores, unlocks, and presents them is a separate component owned by the holder.
self-attestation: Credential issuance pattern where the credential subject is bound to the identity the requester authenticated as. The hosted lab issues a person_is_alive self-attestation: Registry Notary will not issue a credential for a subject the caller did not sign in as. Registry Stack product term.
signed response credentials: Opt-in Registry Relay feature that attaches a W3C Verifiable Credentials Data Model (VCDM) 2.0 VC-JWT signed credential to entity record and aggregate responses when the caller requests Accept: application/vc+jwt. The config key is provenance for backward compatibility. The Decentralized Identifier (DID) document, JSON Schemas, and JSON-LD contexts for this feature are served under /.well-known/. Enabled by the crosswalk-runtime Cargo feature group.
SD-JWT VC: Selective Disclosure JWT Verifiable Credential (IETF draft). Registry Notary issues SD-JWT VC credentials signed with EdDSA. Media type: application/dc+sd-jwt.
OID4VCI: OpenID for Verifiable Credential Issuance. The protocol a wallet uses to obtain a credential from an issuer. Registry Notary implements an OID4VCI issuance flow: a credential offer, issuer metadata at /.well-known/openid-credential-issuer, a nonce endpoint, and a holder proof. The surface is a profiled subset of OID4VCI Draft 13 advertising the dc+sd-jwt format; full issuer conformance is not asserted (openid4vci.support: not_full_issuer).
DID: Decentralized Identifier. W3C DID Core 1.0. Registry Relay publishes a did:web document at /.well-known/did.json when signed response credentials are enabled (config key: provenance). Registry Notary parses did:jwk values for credential subjects.
eSignet: Open-source identity and authentication service (part of MOSIP). The hosted lab uses eSignet as the authorization server a citizen signs in to before Registry Notary issues a self-attestation credential. Not a Registry Stack product term; included here because it appears in hosted lab documentation.
3. Metadata and standards terms
Section titled “3. Metadata and standards terms”metadata manifest: Portable metadata.yaml document using schema version registry-manifest/v1 that describes datasets, entities, fields, public services, forms, requirements, policies, and evidence offerings. MUST NOT include Registry Relay runtime bindings such as source paths, table names, or scopes. Registry Stack product term.
runtime binding: Registry Relay configuration that connects logical manifest concepts to actual files, database tables, scopes, and backend credentials. Lives in Relay config, not in the manifest. Registry Stack product term.
static publication bundle: Manifest-generated directory containing catalog.json, dcat.jsonld, cpsv-ap.jsonld, shacl.jsonld, entity and form JSON Schemas, evidence offering JSON, and policy JSON-LD. Can be hosted as static files without running Registry Relay. Registry Stack product term.
standards-shaped metadata: Machine-readable metadata emitted through formats such as Data Catalog Vocabulary (DCAT), Core Public Service Vocabulary Application Profile (CPSV-AP), Core Criterion and Core Evidence Vocabulary (CCCEV), Shapes Constraint Language (SHACL), JSON Schema, Open Digital Rights Language (ODRL), OpenAPI, and OGC API Records. Registry Stack product term.
entity route: A Registry Relay API route shaped around a domain resource such as household or individual, not around storage table identifiers. Registry Stack product term.
crosswalk: The Registry Relay feature that maps source field names and values to canonical domain terms using configured CEL expressions. Replaces the former cel-mapping name. Enabled by the crosswalk-runtime Cargo feature and the standards-cel-mapping feature alias. Config key: crosswalk. Registry Stack product term.
measures: The configured numeric computations in a Registry Relay aggregate definition (renamed from indicators). Each measure has an id, a label, an aggregation method (count, sum, average, among others), and a source column. Returned in the AggregateResult.measures field alongside observations. Registry Stack product term.
observations: The array of data rows returned in the AggregateResult.observations field for a Registry Relay aggregate query. Each observation is an object keyed by dimension and measure identifiers. Replaces the former data field name from the SDMX-refactor rename. Registry Stack product term.
evidence offering: Metadata entry that describes a verification capability and the access path a client uses to reach it. Can point to a Relay-native verification endpoint or to an external evidence service. Registry Stack product term.
evidence type list: A Core Criterion and Core Evidence Vocabulary (CCCEV) list of evidence types that satisfy a requirement. In Registry Manifest, one list is one grouped option; multiple lists on the same requirement are alternatives. The CCCEV term is adopted directly.
DCAT: Data Catalog Vocabulary. W3C recommendation. Registry Relay and Registry Manifest emit DCAT-shaped JSON-LD catalogs. Spell out on first use per document.
BRegDCAT-AP: SEMIC profile of DCAT-AP for base registries. Registry Relay and Registry Manifest emit BRegDCAT-AP-shaped registry and data-service metadata.
CPSV-AP: Core Public Service Vocabulary Application Profile. Registry Manifest emits CPSV-AP service catalogue JSON-LD.
CCCEV: Core Criterion and Core Evidence Vocabulary. Registry Manifest emits CCCEV-shaped requirement, evidence type, and evidence type list metadata. Registry Notary renders CCCEV-shaped JSON-LD for claim evaluation results. Media type: application/ld+json; profile="cccev".
SHACL: Shapes Constraint Language. W3C recommendation. Registry Relay and Registry Manifest emit SHACL node shapes for entity validation.
ODRL: Open Digital Rights Language. W3C recommendation. Registry Relay and Registry Manifest emit ODRL Offer documents for dataset-scoped policies.
JSON-LD: JSON-based linked data format. W3C recommendation (JSON-LD 1.1). Used for catalog, policy, CCCEV render output, and signed response credential contexts.
OGC API Records: Open Geospatial Consortium API specification for records. Registry Relay exposes records endpoints behind the ogcapi-records feature flag. Registry Manifest renders OGC Records item bodies.
SP DCI: Social Protection Digital Convergence Initiative. Registry Relay exposes an SP DCI adapter behind the spdci-api-standards feature flag. Registry Notary ships an HTTP source connector that maps SP DCI search responses into claim evaluation inputs.
PROV-O: W3C Provenance Ontology. Currently listed as design influence (inspired_by). Provenance-shaped concepts appear in audit fields and the claim provenance struct, but no PROV-O vocabulary terms are emitted as JSON-LD at reviewed commits.
claim level: The evidence discipline these docs use for standards claims: implements, emits, maps_to, aligns_with, inspired_by, or compares_against. Applies to entries in the standards register and is used to characterize a product’s relationship to an external standard without overstatement.
adoption mode: The technical integration pattern a registry stack surface takes toward an external standard, recorded per entry in the standards register: adopted (used directly, as the standard intends, for the part used), profiled (a constrained or profiled subset), adapted (reached through an adapter or connector at a boundary), mapped (the standard’s terms mapped onto the stack’s own), or not adopted (referenced, compared against, or a design influence only, with no implemented contract). Adoption mode is orthogonal to claim level: claim level grades how strongly a relationship is evidenced, adoption mode names what the relationship is. A standard can be not adopted and still aligns_with the stack, meaning the design is consistent with it but the stack does not implement it as a contract. Registry Stack documentation term.
4. Governance and safeguards terms
Section titled “4. Governance and safeguards terms”safeguards: Commitment that every exchange the stack mediates is authorized, scoped, and audited. Concretely: authentication by API key or OIDC; scope-checked routes; per-claim disclosure control (value, predicate, or redacted); no write paths in v1; audit envelopes for every request that touches person-level data. Registry Stack product term.
executable safeguards: Runtime-enforced safeguards: scoped routes, disclosure policy, audit events, machine-readable metadata, and other policy enforcement point behavior that can be checked by software. Registry Stack product term.
distributed custody: The architectural premise that each authority retains control of its own registry data. The registry stack provides the API surface for lawful exchange between authorities; it does not aggregate data into a central system. Equivalent terms include data sovereignty (Gaia-X, IDS, EU dataspaces vocabulary), subsidiarity (governance literature), and federated custody. Registry Stack product term.
purpose-bound request: A request that carries or is evaluated against purpose limitation, policy-based access control, or context-aware authorization. Registry Relay records the Data-Purpose header in audit records where present. Registry Stack product term.
minimized evidence: An evidence response shaped by data minimization, selective disclosure, or verifiable attestation. The response can be narrower than the full source record when the configured use case supports that pattern. Registry Stack product term.
reviewability: Commitment that every promise the stack makes is backed by an artifact a third party can inspect without trusting the operator’s word. Examples include the published DCAT catalog, the SHACL shapes, the ODRL policy documents, the audit envelope schema, the JWKS public key endpoint, and the credential profile configuration. Registry Stack product term.
interoperability: Commitment that every registry in the stack publishes its catalog, schemas, services, and policies in standards-shaped form (DCAT, BRegDCAT-AP, CPSV-AP, CCCEV, SHACL, JSON Schema, ODRL, OpenAPI, SD-JWT VC), so downstream systems integrate against stable contracts rather than per-deployment ones. Registry Stack product term.
DPI: Digital Public Infrastructure. Shared, interoperable digital systems (identity, payments, data exchange) deployed at population scale to support public service delivery. The registry stack covers the registry-consultation slice of a DPI deployment.
5. Abbreviations
Section titled “5. Abbreviations”The table below maps each acronym used in registry stack documentation to its expansion. The first occurrence of each acronym in any document SHOULD be followed by its expansion in parentheses.
| Acronym | Expansion |
|---|---|
| BRegDCAT-AP | Base Registry DCAT Application Profile |
| CCCEV | Core Criterion and Core Evidence Vocabulary |
| CPSV-AP | Core Public Service Vocabulary Application Profile |
| DCAT | Data Catalog Vocabulary |
| DID | Decentralized Identifier |
| DPI | Digital Public Infrastructure |
| JSON-LD | JSON Linked Data |
| ODRL | Open Digital Rights Language |
| OID4VCI | OpenID for Verifiable Credential Issuance |
| PROV-O | W3C Provenance Ontology |
| SD-JWT VC | Selective Disclosure JWT Verifiable Credential |
| SHACL | Shapes Constraint Language |
| SP DCI | Social Protection Digital Convergence Initiative |
| SDMX | Statistical Data and Metadata eXchange |
6. Documentation declaration terms
Section titled “6. Documentation declaration terms”These terms classify a documentation page so a reader, human or AI agent, can tell from the page frontmatter where it sits and whom it serves. They are recorded in the optional layer and audience frontmatter keys defined by RS-DOC. Both keys take a list, because a specification is frequently cross-cutting; a page that spans every layer omits layer rather than list all of them. The vocabulary mirrors the layer and surface vocabulary the registry stack already uses, so documentation does not invent a parallel taxonomy.
layer: The stack layer or layers a page documents. The defined values are:
- metadata: the portable metadata layer (Registry Manifest and the static discovery bundle).
- consultation: Registry Relay’s protected, read-only consultation APIs.
- evaluation: Registry Notary claim evaluation.
- credential: Registry Notary credential issuance, direct and over OID4VCI.
- federation: Registry Notary delegated (static-peer) evaluation.
- administration: operator administration surfaces, including configuration and the key and reload boundaries.
- operations: runtime operation and recovery, including audit sinks, deployment, and runbooks.
audience: The reader role or roles a page serves. The defined values are integrator (a developer integrating against a stack surface), operator (an operator configuring or running a deployment), maintainer (a contributor to a stack component), specification editor (an author of this formal layer), and tooling (an AI coding agent or other automated reader that consumes the page as input).
Evidence
Section titled “Evidence”This specification is verified: the definitions are distilled from published reference material a reader can inspect, per RS-DOC REQ-DOC-014.
- The glossary is the friendlier reference form of this vocabulary and the source these definitions distill. RS-TERMS is authoritative where the two disagree.
- The standards register records each external standard mapped in Section 3, with its adoption mode and the products that use it.
- The architecture specification RS-ARC-G is the referent for the layer vocabulary in Section 6: each layer names a component or surface defined there.
- RS-DOC defines the documentation framework and the conventions every specification in this layer follows.
- The glossary provides the same vocabulary in a friendlier reference format. RS-TERMS is the authoritative source when the two disagree; practical docs use the glossary for approachable explanation.