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 against data from one or more source services 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.
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.
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 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.
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 read sources only after a configured relationship proof claim 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.
Evidence Gateway: Governed runtime path for evidence responses. A Relay read or Notary source-bound evaluation selects an evidence pack or source policy, passes trusted request and source context to the shared Policy Decision Point (PDP), and then permits, redacts, or denies the response. The manifest describes governed evidence bindings and evidence packs; runtime services enforce their configured surfaces.
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 lab 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 configured sources.
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. Current public docs link to them only when they explain a current product boundary or decision.
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.
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.
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. Governed runtime PDP enforcement currently uses the supported Evidence Gateway ODRL terms odrl:purpose and odrl:spatial; publishing an ODRL document alone is not enforcement.
ODRL enforcement profile: Supported runtime-enforcement subset of ODRL terms. The current governed Evidence Gateway profile is registry-evidence-gateway-pdp/v1; it supports odrl:purpose and odrl:spatial as runtime-enforced ODRL constraint terms and denies unsupported ODRL terms 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 a Registry Notary source-bound 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 five current formal stack projects: Registry Platform, Registry Relay, Registry Manifest, Registry Notary, and Registry Lab. 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.
Registry Lab: Compose-based runnable local demo that starts three Registry Relay instances, four Registry Notary instances, live Postgres and Zitadel services, a source adapter sidecar path (using built-in http_json/http_flow/fhir engines), a static metadata publisher, and narrated clients. Repo slug: registry-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 turns existing registry source data, such as files, extracts, and database tables, into protected, read-only, domain-oriented consultation APIs. Repo slug: registry-relay.
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. Repo slug: registry-notary.
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: Opt-in Registry Relay feature that attaches a W3C 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 DID document is served at /.well-known/did.json in gateway issuer mode, JSON Schemas are served under /schemas/..., and JSON-LD contexts are served under /contexts/.... Enabled by the crosswalk-runtime Cargo feature group.
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. 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.
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.
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

Product names (Registry Platform, Registry Relay, Registry Manifest, Registry Notary, Registry Lab) are always title case.
Repo slugs (registry-platform, registry-relay, registry-manifest, registry-notary, registry-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. Do not use them in prose on current pages.
Spell out standards acronyms on first use per page. The glossary provides a reference but does not replace per-page first-use expansion.