Boundaries and map

View as Markdown

The current formal registry stack has five repositories with distinct responsibilities. Use this page to decide which repository owns a question before opening implementation docs, and to understand how the five repositories connect at runtime.

Registry Platform

registry-platform

Shared Rust workspace for security and operational primitives consumed by Registry Relay, Registry Notary, and related registry services, including auth helpers, OIDC verification, JWKS fetching, audit envelopes, HTTP security, outbound HTTP policy, crypto, SD-JWT VC support, and test fixtures.

Owns

Shared auth, OIDC, JWKS fetching, audit, HTTP security, outbound HTTP, crypto, SD-JWT, and testing primitives.
OID4VCI credential offer, nonce, credential request, and issuer metadata primitives via the `registry-platform-oid4vci` crate.
Cross-service crate APIs that must behave consistently in Relay, Notary, and future registry services.
Shared Rust hygiene templates and supported integration-test fixtures.

Does not own

Registry Relay runtime data access, entity routing, metadata publication, or scope policy semantics.
Registry Notary claim configuration, evaluation rules, disclosure policy decisions, or service routes.
Product-level authorization policy, tenant isolation, audit retention, secret provisioning, or deployment configuration.

Registry Manifest

registry-manifest

Renders standards-shaped catalog, service, schema, form, policy, evidence-offering, public Notary federation, OGC Records, and embedded SKOS-shaped codelist metadata from a single YAML metadata manifest, so a registry's published surface stays consistent across formats.

Owns

Metadata manifest model and compiled metadata model.
Pure renderers for catalog, DCAT, CPSV-AP service catalogues, CCCEV requirements and evidence type lists, BRegDCAT-AP, SHACL, JSON Schema, form JSON Schema, OGC Records, policies, evidence offerings, and embedded SKOS-shaped codelist nodes.
Public Registry Notary federation metadata and evaluation profile validation.
CLI validation, rendering, static publication, and profile fixture validation.

Does not own

Registry Relay runtime data access.
Auth, audit, observability, DataFusion, Postgres, Axum, or secret handling.
Production source configuration.

Registry Relay

registry-relay

Read-only HTTP gateway that fronts a sensitive registry database. Exposes entity-shaped query routes, caller-scoped metadata, evidence-offering discovery, optional OGC API adapters, and optional signed response provenance while composing shared auth, OIDC, audit, HTTP security, crypto, and SD-JWT primitives from Registry Platform.

Owns

Runtime configuration and source binding.
Entity-shaped Registry Data API routes.
Relay-specific API key and OIDC resource-server configuration, scope checks, and route enforcement.
Caller-scoped metadata publication.
Relay-native evidence offering discovery and publication.

Does not own

Source-registry provisioning, write-back, or domain-data mutation paths in v1.
Portable metadata schema ownership.
Standalone claim service internals owned by Registry Notary.
Shared security and operational primitives owned by Registry Platform.
Storage table ids or arbitrary SQL in public APIs.

Registry Notary

registry-notary

Standalone service that evaluates eligibility claims against registry data, serves static-peer federated delegated evaluation, and issues SD-JWT verifiable credentials with selective disclosure, composing shared auth, audit, OIDC, HTTP security, crypto, SD-JWT, and testing primitives from Registry Platform.

Owns

Claim configuration and evaluation.
Disclosure policy and redacted audit event semantics.
Registry Notary API routes.
Static-peer delegated evaluation at `/federation/v1/evaluations`.
Credential issuance workflow and claim-to-credential mapping.
OID4VCI Draft 13 credential offer flow (credential-offer, nonce, credential endpoints) and the `/.well-known/openid-credential-issuer` metadata endpoint.
HTTP source connectors for Registry Data API and SP DCI-style sources.

Does not own

Registry Relay source code or runtime internals.
Portable metadata renderers owned by Registry Manifest.
Shared security and operational primitives owned by Registry Platform.
Open federation, dynamic trust-chain discovery, shared replay storage, or federated credential issuance.
Browser inspection workflows outside the current formal v1 stack scope.

Registry Lab

registry-lab

Docker Compose demo of the registry runtime on a laptop. Wires three Relay instances, four Notary instances, live Postgres and Zitadel services, a source adapter sidecar scenario (using built-in http_json/http_flow/fhir engines), a static metadata publisher, and narrated demo clients together with Registry Platform, Relay, and Notary source pins, fixtures, and smoke tests.

Owns

End-to-end local topology for Relay, Notary, live Postgres, live Zitadel, the source adapter sidecar path (built-in http_json/http_flow/fhir engines), the static metadata publisher, and demo-client fixtures.
Demo scripts, smoke checks, generated local credentials, live-service checks, static metadata checks, and narrated client flows.
Citizen self-attestation walkthrough that exercises the Notary OID4VCI flow end-to-end through the `just citizen-oid4vci-*` recipes.
Acceptance rehearsal after rename waves land.

Does not own

Production deployment guidance.
Normative API or metadata contracts.
Real product integrations for OpenCRVS, OpenSPP, DHIS2, OpenIMIS, MOSIP, or other systems.

Update via projects.yaml. Generated from src/data/projects.yaml.

Flow across the stack

For how the five projects connect at runtime, see the architecture overview.

Ownership quick reference

Question	Owning project
Which shared Rust crate owns auth helpers, OIDC verification, audit envelopes, HTTP security, outbound HTTP policy, crypto, SD-JWT VC helpers, or test fixtures?	Registry Platform
How is a CSV, XLSX, Parquet, or PostgreSQL source exposed as authorized entity routes?	Registry Relay
How is `metadata.yaml` validated or rendered into standards-facing artifacts?	Registry Manifest
How is a claim evaluated, delegated to a trusted Notary, or turned into an attestation or credential?	Registry Notary
How do the services run together in a local demo?	Registry Lab

Cross-project explanation, standards evidence, and contract indexes live in these docs (not in any one project repo).

Registry Platform

Registry Platform is a shared crate workspace. It does not run a service or decide product policy.

Does not own:

Registry Relay route behavior, runtime source binding, metadata publication, or Relay-specific scope semantics.
Registry Notary claim definitions, evaluation rules, disclosure decisions, service routes, or claim-to-credential mapping.
Operator responsibilities such as tenant isolation, audit retention, secret provisioning, deployment configuration, and incident response.

Use Registry Platform when a primitive needs to behave identically across services. Use the consuming repo when the question is about a product route, config file, or user-facing workflow.

Registry Manifest

Registry Manifest is a pure library and CLI with no runtime data dependencies.

Does not own:

Registry Relay runtime data access. Manifest doesn’t serve HTTP, doesn’t talk to databases, doesn’t run inside a gateway.
Auth, audit, observability, or secret handling. These are intentionally excluded so the library can be used without running any runtime service.
Production source configuration. Source paths, table IDs, scopes, cache paths, and backend runtime details belong in Registry Relay configuration, not in portable manifests.
Runtime federation policy. Manifest can publish public Notary federation metadata, but peer allowlists, signing keys, replay stores, purpose policy, and source scopes belong in Registry Notary config.

No HTTP serving, no database queries, no authorization scoping. The manifest compiles and renders only.

Registry Relay

Registry Relay exposes protected read-only APIs over registry sources. It does not own:

Record provisioning or writes. The README explicitly states write operations are out of scope for v1.
Portable metadata schema ownership. The metadata.yaml manifest format and its renderers are owned by Registry Manifest. Registry Relay may serve compiled artifacts over HTTP and scope them for callers, but the schema is defined and versioned in Registry Manifest.
Standalone claim service internals owned by Registry Notary. Registry Relay can declare evidence offerings and route clients to a Registry Notary endpoint, but claim evaluation, disclosure policy, and credential issuance run in Registry Notary.
Shared auth, OIDC, audit, HTTP security, outbound HTTP, crypto, and SD-JWT helper primitives owned by Registry Platform. Registry Relay owns how those primitives are configured and enforced on Relay routes.
Storage table IDs or arbitrary SQL in public APIs. Public route paths use dataset and entity identifiers; internal table names and query shapes are configuration internals.

Registry Relay is not an open-data portal. It publishes restricted consultation APIs for authorized systems only.

Registry Notary

Registry Notary evaluates claims and issues SD-JWT VC credentials. It does not own:

Registry Relay source code or runtime internals. Registry Notary calls Registry Relay over HTTP using a source connector; it does not import or link Registry Relay libraries. Both services can depend on Registry Platform.
Portable metadata renderers owned by Registry Manifest. Registry Notary does not produce DCAT, SHACL, BRegDCAT-AP, or OGC Records artifacts.
Shared auth, OIDC, audit, HTTP security, outbound HTTP, crypto, SD-JWT, and testing primitives owned by Registry Platform. Registry Notary owns the claim service behavior that composes those primitives.
Open federation, dynamic trust-chain discovery, shared replay storage, audit checkpoint exchange, or federated credential issuance. The current federation implementation is static-peer delegated evaluation only.
Browser inspection workflows are outside the current formal v1 stack scope. Registry Notary does not inspect published discovery artifacts, parse DCAT catalogs, or run capability queries.

Registry Notary credentials are SD-JWT VC format (application/dc+sd-jwt), not W3C Verifiable Credentials Data Model JSON-LD envelopes. No W3C VC Data Model namespace or @context is present in the issued credential.

Registry Lab

Registry Lab is a compose-based local demo. It does not own:

Production deployment guidance. The demo uses CSV, XLSX, and Parquet fixtures and demo-grade credentials. It is not a reference for production configuration.
Normative API or metadata contracts. API contracts are owned by Registry Relay and Registry Notary; metadata contracts are owned by Registry Manifest.
Real product integrations. The services simulate civil, social protection, and health registry patterns but are not real integrations with OpenCRVS, OpenSPP, DHIS2, OpenIMIS, MOSIP, or other systems.

Documentation rule

Put detailed setup, configuration, and command references in the owning repo. Put cross-project orientation, standards evidence, and contract indexes in these docs.

When a page needs both, these docs summarize the decision and link to the owning source.

Next: Architecture overview: how the five projects connect at runtime.