Glossary

View as Markdown

Use this page to look up unfamiliar terms. Product names are always in English, including on future translated pages.

BRegDCAT-AP: SEMIC profile of DCAT-AP for base registries. Registry Relay and Registry Manifest emit BRegDCAT-AP-shaped registry and data-service metadata.
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".
claim evaluation: Registry Notary process that evaluates configured evidence rules over compiler-pinned Registry Relay outputs or permitted self-attestation and returns a structured claim result.
claim level: The evidence discipline these docs use for standards claims: implements, emits, maps_to, aligns_with, inspired_by, or compares_against.
consultation: A named use of one Registry Relay integration by a Registry Notary evidence service. One consultation can supply several Notary claims.
DCAT: Data Catalog Vocabulary. W3C recommendation. Registry Relay and Registry Manifest emit DCAT-shaped JSON-LD catalogs. Spell out on first use per page: “Data Catalog Vocabulary (DCAT)”.
CPSV-AP: Core Public Service Vocabulary Application Profile. Registry Manifest emits CPSV-AP service catalogue JSON-LD. Registry Relay does not expose a current CPSV-AP runtime metadata route.
crosswalk: The 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.
credential profile: Registry Notary configuration that names which claims may be issued as a credential. A Registry Stack project authors claim membership once on the profile, and the compiler derives the product-level claim-to-profile reverse index.
deployment bundle: The target generated, signed artifact for one Registry Stack project and environment. Its root manifest binds compatible Relay and Notary submanifests when both are present. The current authoring command builds separate unsigned product inputs, not a deployment bundle; signed project-root bundles are deferred.
deployment: One activated deployment-bundle generation. Replicas of that generation are one logical deployment.
DPI: Digital Public Infrastructure. Shared, interoperable digital systems (identity, payments, data exchange) deployed at population scale to support public service delivery. These projects cover the registry-consultation slice of a DPI deployment.
DID: Decentralized Identifier. W3C DID Core 1.0. Registry Relay no longer publishes a did:web document. Registry Notary parses did:jwk values for credential subjects.
delegated self-attestation: Registry Notary self-attestation access mode delegated_attestation. The authenticated principal is the requester, the request target and scoped authorization details identify the same configured dependent subject, and the dependent claim can continue only after a compiler-pinned Relay relationship proof evaluates to boolean true. This is separate from static-peer delegated evaluation under Notary federation.
disclosure profile: Registry Notary control over what the caller receives: Value (full value disclosed), Predicate (only true/false satisfaction), or Redacted (value fully hidden).
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.
entity route: A Relay API route shaped around a domain resource such as household or individual, not around storage table identifiers.
entity: A logical Registry Relay-local schema that snapshot can materialize and query. A project can expose an entity through a records service.
environment: Private bindings and operational settings for one Registry Stack project deployment target. An environment does not change the project’s stable intent.
Evidence Gateway: Governed runtime path for evidence responses. A Relay read or consultation and a Notary claim evaluation pass trusted request and evidence context through configured authorization and disclosure policy before returning or denying a response. Registry-backed Notary claims consume compiler-pinned Relay results.
evidence service: A Registry Notary-owned service containing service policy, claims, disclosure, optional Registry Relay consultations, and optional credential profiles.
ecosystem binding: Manifest-level binding that connects an external ecosystem profile or governed evidence pack to a Registry Stack runtime surface. A governed evidence ecosystem binding names the evidence pack metadata and policy identity a runtime service can use for PDP enforcement.
eSignet: Open-source identity and authentication service (part of MOSIP). The hosted Solmara Lab demo uses eSignet as the authorization server a citizen signs in to before Registry Notary issues a self-attestation credential.
evidence offering: Metadata entry that describes a verification capability and the access path a client uses to reach it. In the current stack it points a client from Registry Relay metadata to Registry Notary or another evidence service; Relay describes the offering but does not evaluate the claim.
evidence claim: Registry Stack product term for a verifiable claim, attestation, credential claim, or status assertion that Registry Notary evaluates from Relay outputs or permitted self-attestation.
evidence type list: 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.
executable safeguards: Registry Stack product term for runtime-enforced safeguards: scoped routes, disclosure policy, audit events, machine-readable metadata, and other policy enforcement point behavior that can be checked by software.
governed evidence: Evidence metadata and runtime behavior bound to a governed-evidence ecosystem binding. Manifest validation requires pack identity, evidence metadata, required PDP gates, allowed outputs, policy id/hash binding, and the registry-evidence-gateway-pdp/v1 ODRL enforcement profile, while some evidence metadata fields remain opaque JSON.
historical docs: Older specs, implementation reviews, or pre-rename documents that remain useful evidence but are not current user guidance.
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.
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, OGC Records, SKOS-shaped codelists, SD-JWT VC), so downstream systems integrate against stable contracts rather than per-deployment ones.
integration: A product-neutral source adaptation authored in a Registry Stack project. An integration declares reviewed metadata and one source capability such as http, script, or snapshot. Product and version labels do not select compiler or runtime behavior.
output: A typed, minimized scalar returned by Registry Relay on a matching consultation.
claim: A Registry Notary-owned, purpose-specific value or predicate derived from consultation outcome and outputs.
JSON-LD: JSON-based linked data format. W3C recommendation (JSON-LD 1.1). Used for catalog, policy, and CCCEV render output.
metadata manifest: Portable metadata.yaml document (schema version registry-manifest/v1) that describes datasets, entities, fields, public services, forms, requirements, policies, evidence offerings, federation metadata, evaluation profiles, and governed evidence ecosystem bindings. Must not include Relay runtime bindings such as source paths, table names, or scopes.
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. See also: observations.
minimized evidence: Registry Stack product term for 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.
ODRL: Open Digital Rights Language. W3C recommendation. Relay and Manifest emit ODRL Offer documents for dataset-scoped descriptive policies. Relay governed runtime PDP enforcement currently uses odrl:purpose; publishing an ODRL document alone is not enforcement.
ODRL enforcement profile: Governed Evidence Gateway profile vocabulary for ODRL terms. The current profile is registry-evidence-gateway-pdp/v1; Relay currently enforces odrl:purpose and denies terms such as odrl:spatial fail-closed rather than treating them as enforced.
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. The field replaces the former data name from the SDMX-refactor rename.
OGC API Records: Open Geospatial Consortium API specification for records. Relay exposes records endpoints behind the ogcapi-records feature flag. Manifest renders and publishes an OGC Records item collection.
OGC API Features: Open Geospatial Consortium API specification for feature collections and items. Registry Relay exposes a profiled feature collection surface behind the ogcapi-features feature flag.
OGC API EDR: Open Geospatial Consortium API specification for Environmental Data Retrieval. Registry Relay exposes profiled area queries over configured spatial aggregates behind the ogcapi-edr feature flag.
OID4VCI: OpenID for Verifiable Credential Issuance. The protocol a wallet uses to obtain a credential from an issuer. Registry Notary emits an OID4VCI issuance flow: a credential offer, issuer metadata at /.well-known/openid-credential-issuer, a nonce, 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).
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.
PDP: Policy decision point. In Registry Stack, the shared Registry Platform primitive that evaluates a governed policy against trusted request and source context and returns permit, permit with redaction, or deny with stable pdp.* provenance.
PDP gate: A named policy decision point check evaluated by the shared Registry PDP, such as policy identity, ODRL terms, purpose, jurisdiction, assurance, source freshness, legal basis, consent, source binding, route identity, checked scope, and redaction. Evaluated PDP gates appear as rule IDs in governed audit records.
PDP audit provenance: Audit fields that explain a governed PDP decision, including policy id, policy hash, evaluated rule ids, route identity, source binding, checked scopes, trust-provenance labels, and stable pdp.* denial code when denied.
PEP: Policy enforcement point. The runtime service surface, such as a Registry Relay governed read or consultation, or a Registry Notary claim evaluation, that calls the PDP and enforces the resulting permit, redaction, or deny decision.
policy hash: Lowercase sha256: digest that binds a governed evidence policy identity to canonical policy bytes or an externally supplied policy artifact. Manifest verifies it when an inline evidence pack policy object is present; Relay records the selected hash in governed PDP audit provenance.
Protected Registry APIs: Registry Stack runtime pattern for exposing existing registry source data through scoped, read-only HTTP routes with authentication, authorization, metadata, and audit. Registry Relay implements this pattern.
registry stack: The four formal stack products: Registry Platform, Registry Relay, Registry Manifest, and Registry Notary. Use lowercase when referring to the concept.
purpose-bound request: Registry Stack product term for a request that carries or is evaluated against purpose limitation, policy-based access control, or context-aware authorization. Relay records the Data-Purpose header in audit records where present.
checked scope: Authorization scope that the runtime service has already verified before PDP enforcement and then passes into the PDP and audit provenance. A PDP decision must not invent a checked scope that ordinary authorization did not verify.
fail closed: Security posture where missing, malformed, unsupported, stale, or unauditable governed policy inputs result in denial rather than permit.
Solmara Lab: Separately maintained adopter demo for the fictional Republic of Solmara. It runs published Registry Stack images in local and hosted topologies and is not a formal Registry Stack product. Repo slug: solmara-lab.
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 CLI (registry-manifest-cli). Repo slug: registry-manifest.
Registry Platform: Shared Rust workspace for registry security and operational primitives, including auth helpers, OIDC verification, audit envelopes, HTTP security, outbound HTTP policy, crypto, SD-JWT VC helpers, and test fixtures. Repo slug: registry-platform.
Registry Relay: Config-driven Rust service that owns registry source access, product-neutral HTTP and script adaptation, immutable snapshot lookups, and protected read-only consultation APIs. Repo slug: registry-relay.
Registry Notary: Standalone Rust service for Relay-backed or self-attested claim evaluation, disclosure policy, credential issuance, and audit. Repo slug: registry-notary.
Registry Stack project: The authored root for one registry trust domain. A project can describe a Relay-only, Notary-only, or combined deployment and compiles separate product inputs for the selected topology.
Registry Stack project workspace: The local directory containing one Registry Stack project’s authored YAML, scripts, fixtures, and generated review and build outputs.
records service: A Registry Relay-owned records API exposure of an entity, with its own access, purpose, projection, filter, and pagination policy.
service: An authored, purpose-bound public capability. Use the specific term evidence service or records service when the distinction matters. A service is not a Registry Relay or Registry Notary process.
service policy: The purpose, legal basis, consent, caller access, and disclosure rules governing one service.
source: The one logical registry data interface available to Registry Relay, when present, inside a project trust domain. An OAuth or JSON Web Key Set endpoint used by a protocol is not another data source.
registry-manifest/v1: Schema version string for portable metadata manifests.
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.
runtime binding: Relay configuration that connects logical manifest concepts to actual files, database tables, scopes, and backend credentials. Lives in Relay config, not in the manifest.
route identity: Canonical identifier for the runtime route or claim path being evaluated by the PDP. Route identity prevents a policy written for one route from silently authorizing another route with a similar shape.
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 source-registry data mutation through Relay; audit envelopes for every request that touches person-level data.
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.
self-attestation: Registry Notary access pattern where an authenticated OIDC principal is the protected requester for configured claim evaluation or credential issuance. In direct self-attestation, the subject is the authenticated requester. In delegated self-attestation, the requester acts for a configured dependent target only when the relationship proof passes.
signed response credentials: Removed Registry Relay feature that attached a W3C VCDM 2.0 VC-JWT signed credential to entity record and aggregate responses. Registry Relay no longer accepts provenance or entity publicschema credential mapping config, no longer serves /.well-known/did.json, /schemas/{claim_type}/{version}, or /contexts/{vocab}/{version}, and no longer returns application/vc+jwt. Use Registry Notary for credential issuance.
SHACL: Shapes Constraint Language. W3C recommendation. Relay and Manifest emit SHACL node shapes for entity validation.
source freshness: PDP gate that compares trusted source evidence age with a configured maximum age. A stale or malformed freshness assertion can produce the stable denial code pdp.evidence_stale.
source binding: Runtime or source-policy identifier that names the configured source service, resource, or claim binding a governed decision is allowed to use. Source binding lets audit records and PDP rules distinguish one backend source from another.
SP DCI: Social Protection Digital Convergence Initiative. Registry Relay can expose an SP DCI adapter and can execute a reviewed DCI source integration. Registry Notary consumes the resulting compiler-pinned Relay consultation, not a direct DCI source connector.
static publication bundle: Manifest-generated directory containing catalog.json, dcat.jsonld, cpsv-ap.jsonld, shacl.jsonld, entity and form JSON Schemas, OGC Records item collections, evidence offering JSON, policy JSON-LD, and embedded SKOS-shaped codelist metadata in linked-data outputs. Can be hosted as static files without running Registry Relay.
standards-shaped metadata: Registry Stack product term for machine-readable metadata emitted through formats such as DCAT, CPSV-AP, CCCEV, SHACL, JSON Schema, ODRL, OpenAPI, OGC API Records, and SKOS-shaped codelist metadata.
SKOS: Simple Knowledge Organization System. Registry Manifest currently emits flat SKOS-shaped skos:ConceptScheme and skos:Concept nodes for codelists inside SHACL and BRegDCAT/DCAT-shaped outputs. It does not yet publish a standalone SKOS artifact.
stable PDP denial code: Machine-stable pdp.* problem code returned on governed PDP denial and recorded in audit provenance as pdp_stable_problem_code, for example pdp.purpose_not_permitted, pdp.evidence_stale, or pdp.policy_hash_invalid.
trust context: Trusted facts supplied to the PDP for a governed decision. The context can include the authenticated principal, checked scopes, requested purpose, route identity, source binding, requested fact or disclosure, jurisdiction, assurance, legal basis, consent, and source freshness. Caller-supplied facts count only when backed by trusted assertion scopes or trusted source metadata.
trust domain: The institutional boundary whose operators, runtime identities, policy, and deployment approval govern one Registry Stack project. A country can contain several trust domains, and a trust domain does not need to represent a country.
wallet: 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.

Style notes

Formal product names (Registry Platform, Registry Relay, Registry Manifest, Registry Notary) and the adopter demo name (Solmara Lab) are always title case.
Repo slugs (registry-platform, registry-relay, registry-manifest, registry-notary, solmara-lab) are always lowercase and monospace.
Legacy underscore forms (registry_relay) and old repo names (decentralized-evidence-demo) appear only in historical pages or rename_status fields.
The glossary provides a reference for standards acronyms but does not replace per-page first-use expansion.