DPI safeguards alignment
If you are a DPI implementer or reviewer trying to place the registry stack inside a safeguards program, use this page to see which safeguards claims the stack can support with software evidence, and which claims still belong to the institution that governs, deploys, and operates the DPI.
Claim scope
Section titled “Claim scope”The registry stack is compared against the Universal DPI Safeguards Framework as implementation evidence, not as certification. The framework spans 18 principles, 13 risks, responsible authorities, five DPI life-cycle stages, and adoption pathways across law, institutions, technical foundations, capacity, and whole-of-society participation.
The stack maps mainly to technical foundations. It can make a registry surface inspectable, scoped, auditable, and easier to integrate. It does not create lawful basis, public mandate, inclusion practice, grievance handling, or independent oversight.
Where it fits
Section titled “Where it fits”Use the registry stack when a program needs controlled registry facts instead of broad data access:
- A ministry needs a read-only consultation API over an existing registry.
- A program needs eligibility evidence without copying the source record.
- An integrator needs to inspect schemas, policies, services, and evidence offerings before connecting.
- A reviewer needs audit events, stable denial codes, bundle digests, or signed evidence artifacts.
- A known peer needs delegated evaluation through a configured Registry Notary relationship.
Do not use the stack as an unrestricted data portal, data warehouse, ad-hoc SQL service, consent platform, grievance system, eligibility engine, or proof that a DPI deployment conforms to the framework.
Safeguards support
Section titled “Safeguards support”| Safeguards question | Stack evidence | Boundary |
|---|---|---|
| What does the registry expose? | Registry Manifest renders portable catalog, schema, service, policy, and evidence-offering metadata. | Metadata describes a surface. It does not authorize access. |
| Who can read protected data? | Registry Relay and Registry Notary authenticate protected routes and enforce scopes before source access. | Deployment policy decides who receives scopes. |
| Is the exchange purpose-bound? | Governed runtime routes can require purpose and trusted context, then fail closed with stable pdp.* denial codes. | Static policy metadata is not enforcement until a runtime service binds it. |
| Is data minimized? | Relay exposes configured fields, relationships, and aggregates. Notary can return value, predicate, or redacted results. | The operator still chooses the fields, claims, and disclosure defaults. |
| Can the exchange be reviewed later? | Relay and Notary audit events, PDP provenance, package and content digests, signed response credentials, and SD-JWT VC credentials provide review evidence. | Audit records support accountability. They are not accountability by themselves. |
| Can other systems interoperate? | Manifest emits standards-shaped metadata; Relay and Notary publish OpenAPI; Notary issues SD-JWT VC credentials and exposes a profiled OID4VCI flow. | These are scoped adoption claims, not blanket conformance to every named standard. |
Project roles
Section titled “Project roles”| Project | Safeguards contribution | Explicit boundary |
|---|---|---|
| Registry Manifest | Validates metadata.yaml, rejects known runtime-only keys, and renders standards-shaped metadata: Data Catalog Vocabulary (DCAT), BRegDCAT-AP, Core Public Service Vocabulary Application Profile (CPSV-AP), Shapes Constraint Language (SHACL), JSON Schema, Open Digital Rights Language (ODRL), Core Criterion and Core Evidence Vocabulary (CCCEV), Open Geospatial Consortium (OGC) API Records, evidence offerings, and SKOS-shaped codelists. | Manifest does not serve HTTP, read production data, authorize callers, or evaluate claims. See the Registry Manifest data model. |
| Registry Relay | Exposes protected, read-only, domain-oriented registry routes for records, relationships, schemas, aggregates, scoped metadata, and governed PDP reads, plus emitted audit events and optional signed response credentials. | Relay does not mutate source data, expose arbitrary SQL, evaluate claims, issue Notary credentials, or put admin routes on the public API. See the Registry Relay protocol. |
| Registry Notary | Evaluates configured claims against HTTP sources, applies disclosure policy, renders claim results, issues SD-JWT VC credentials from stored evaluations, and supports static-peer delegated evaluation. | Notary does not decide eligibility, run a wallet, certify source truth, or provide open federation. See the Registry Notary protocol. |
| Registry Platform | Supplies shared primitives for authentication, OpenID Connect (OIDC), audit envelopes, HTTP security, outbound HTTP policy, cryptography, PDP behavior, and SD-JWT VC support. | Platform provides primitives. Relay and Notary configure and enforce their route behavior. See RS-SEC-G. |
Principle alignment
Section titled “Principle alignment”Each cluster groups one or more of the framework’s 18 principles. The IDs in parentheses
(foundational F1-F9, operational O1-O9) point back to the named principles so a reviewer
holding the framework can check the mapping directly. The stack speaks to technical-foundations
principles; the remaining principles are governance and institutional work outside the software.
| Framework principle cluster | How the stack helps | What remains outside the stack |
|---|---|---|
| Data privacy by design (O3) | Configured fields, scoped metadata, aggregate routes, predicate evidence, redacted evidence, and selective disclosure reduce unnecessary data movement. | Legal privacy duties, data subject rights, retention rules, and consent operations remain deployment responsibilities. |
| Data security by design (O4) | Protected routes use API key or OIDC modes, scope-before-source authorization, shared security primitives, separate admin surfaces, and fail-closed governed decisions. | Key custody, network controls, incident response, security audits, and production hardening remain operator responsibilities. |
| Data protection during use (O5) | Runtime services can record purpose, checked scopes, PDP policy provenance, stable denials, and audit events for reads and evaluations. | A program still needs lawful basis, oversight, retention policy, and protections against overreaching requests. |
| Transparency and accountability (F4) | Portable metadata, runtime metadata, OpenAPI references, stable error codes, audit records, signed responses, credentials, and the standards register make behavior reviewable. | Public governance, remedies, procurement discipline, and independent accountability mechanisms are institutional controls. |
| Build and share open assets (O9) | The stack emits or uses open, standards-shaped artifacts and documented HTTP contracts rather than one-off integration agreements. | External conformance and certification require separate validation against each standard or program rule. |
| Autonomy and agency (F6) | Notary credentials support holder binding through did:jwk; claim results and credentials can avoid exposing more than the configured disclosure mode allows. | The stack does not provide a complete wallet, consent journey, opt-out path, appeal process, or assisted service channel. |
| Inclusion and non-discrimination (F2, F3, O6) | Metadata, audit, and claim evidence can help reviewers inspect what a service exposes and how it behaves. | Accessibility, language access, community participation, gender or disability inclusion, and non-digital alternatives are not solved by these components. |
Fit boundaries
Section titled “Fit boundaries”The stack fits best at the implementation-evidence layer. It helps reviewers answer what is exposed, who may call it, what policy gates exist, what evidence can be returned, and which project owns the behavior.
The stack does not hide governance decisions inside software. Manifest metadata and Relay metadata do not grant access. Notary credentials do not decide benefits. Signed response credentials do not certify a deployment. Audit events do not replace remedy, supervision, or public accountability.