From 87bb62a1a5e0ff2ac2e8a1a339960a1c698e8a1b Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Thu, 2 Jul 2026 14:37:18 +0700 Subject: [PATCH 1/3] docs: pin DPI safeguards mapping to framework version 2.0 and add O2 row The framework site now publishes version 2.0; the page cited principle IDs against an unversioned link, so the mapping could drift silently. Pin the version in the claim scope (matching the standards register entry) and link the canonical framework page instead of /assessments. Add an Evolve with evidence (O2) row to the principle alignment table, pointing at the ITB/SEMIC evidence, security self-assessment, and OpenSSF release-trust pages, which already exist as reviewable evidence but were not surfaced in this mapping. Signed-off-by: Jeremi Joslin --- .../content/docs/explanation/dpi-safeguards-alignment.mdx | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx b/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx index 2a42e130..47e3c9ff 100644 --- a/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx +++ b/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx @@ -8,7 +8,7 @@ source_repos: - registry-relay - registry-manifest - registry-notary -last_reviewed: "2026-06-23" +last_reviewed: "2026-07-02" doc_type: explanation locale: en standards_referenced: @@ -36,8 +36,11 @@ claims still belong to the institution that governs, deploys, and operates the D ## Claim scope -The registry stack is compared against the [Universal DPI Safeguards Framework](https://www.dpi-safeguards.org/assessments) +The registry stack is compared against version 2.0 of the +[Universal DPI Safeguards Framework](https://www.dpi-safeguards.org/framework) as implementation evidence, not as certification. +The principle IDs on this page follow that version, as recorded in the +[standards register](../../reference/standards/). 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. @@ -94,6 +97,7 @@ principles; the remaining principles are governance and institutional work outsi | 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](../../reference/standards/) make behavior reviewable. | Public governance, remedies, procurement discipline, and independent accountability mechanisms are institutional controls. | +| Evolve with evidence (O2) | [ITB and SEMIC validation evidence](../../reference/itb-semic-evidence/), the [security self-assessment](../../security/self-assessment/), [OpenSSF status and release verification evidence](../../security/openssf-evidence/), and CI-gated tests and conformance fixtures give assessors material they can re-run and re-check. | Independent assessments, audits, engagement with affected people, and acting on findings remain program and institutional responsibilities. | | 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. | From 5dc184655120ea20b59aef5bf15dcba56ff85394 Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Thu, 2 Jul 2026 14:56:44 +0700 Subject: [PATCH 2/3] docs: define acronyms on first use and link evidence on DPI safeguards page The page expanded DCAT, CPSV-AP, SHACL, and OIDC on first use but left PDP, SD-JWT VC, and OID4VCI bare, and dropped holder binding and did:jwk unexplained; the stated reader is a DPI reviewer, not a credentials engineer. Expand each on first use, gloss holder binding inline, and replace the untraceable 'bundle digests' phrase with the package and configuration-bundle digests the code actually publishes. Link the pdp.* denial codes to the errors reference and the disclosure modes to their explanation page so table claims are checkable in one click. Signed-off-by: Jeremi Joslin --- .../docs/explanation/dpi-safeguards-alignment.mdx | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx b/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx index 47e3c9ff..07854920 100644 --- a/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx +++ b/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx @@ -57,7 +57,7 @@ Use the registry stack when a program needs controlled registry facts instead of - 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 reviewer needs audit events, stable denial codes, package and configuration-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 @@ -70,10 +70,10 @@ framework. | --- | --- | --- | | 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. | +| Is the exchange purpose-bound? | Governed runtime routes can require purpose and trusted context, then fail closed with stable [`pdp.*` denial codes](../../reference/errors/). | 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` [disclosure results](../disclosure-modes-and-computed-answers/). | The operator still chooses the fields, claims, and disclosure defaults. | +| Can the exchange be reviewed later? | Relay and Notary audit events, Policy Decision Point (PDP) provenance, package and content digests, signed response credentials, and Selective Disclosure JWT Verifiable Credentials (SD-JWT VC) 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 OpenID for Verifiable Credential Issuance (OID4VCI) flow. | These are scoped adoption claims, not blanket conformance to every named standard. | ## Project roles @@ -99,7 +99,7 @@ principles; the remaining principles are governance and institutional work outsi | Transparency and accountability (F4) | Portable metadata, runtime metadata, OpenAPI references, stable error codes, audit records, signed responses, credentials, and the [standards register](../../reference/standards/) make behavior reviewable. | Public governance, remedies, procurement discipline, and independent accountability mechanisms are institutional controls. | | Evolve with evidence (O2) | [ITB and SEMIC validation evidence](../../reference/itb-semic-evidence/), the [security self-assessment](../../security/self-assessment/), [OpenSSF status and release verification evidence](../../security/openssf-evidence/), and CI-gated tests and conformance fixtures give assessors material they can re-run and re-check. | Independent assessments, audits, engagement with affected people, and acting on findings remain program and institutional responsibilities. | | 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. | +| Autonomy and agency (F6) | Notary credentials support holder binding through `did:jwk`, so only the key holder can present a credential; 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 From 4877c4897af531912aa2846549f73e2de42766cc Mon Sep 17 00:00:00 2001 From: Jeremi Joslin Date: Thu, 2 Jul 2026 15:59:05 +0700 Subject: [PATCH 3/3] docs: qualify holder-binding claim and drop unanchored CI claim Review findings on #187: holder_binding.mode defaults to none per credential profile, so state that binding applies when the profile enables it rather than implying every credential is bound. Remove the 'CI-gated tests and conformance fixtures' clause from the O2 row; it had no evidence link, and the three linked evidence pages carry the claim. Signed-off-by: Jeremi Joslin --- .../src/content/docs/explanation/dpi-safeguards-alignment.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx b/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx index 07854920..8a8106d6 100644 --- a/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx +++ b/docs/site/src/content/docs/explanation/dpi-safeguards-alignment.mdx @@ -97,9 +97,9 @@ principles; the remaining principles are governance and institutional work outsi | 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](../../reference/standards/) make behavior reviewable. | Public governance, remedies, procurement discipline, and independent accountability mechanisms are institutional controls. | -| Evolve with evidence (O2) | [ITB and SEMIC validation evidence](../../reference/itb-semic-evidence/), the [security self-assessment](../../security/self-assessment/), [OpenSSF status and release verification evidence](../../security/openssf-evidence/), and CI-gated tests and conformance fixtures give assessors material they can re-run and re-check. | Independent assessments, audits, engagement with affected people, and acting on findings remain program and institutional responsibilities. | +| Evolve with evidence (O2) | [ITB and SEMIC validation evidence](../../reference/itb-semic-evidence/), the [security self-assessment](../../security/self-assessment/), and [OpenSSF status and release verification evidence](../../security/openssf-evidence/) give assessors material they can re-run and re-check. | Independent assessments, audits, engagement with affected people, and acting on findings remain program and institutional responsibilities. | | 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`, so only the key holder can present a credential; 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. | +| Autonomy and agency (F6) | Notary credentials support holder binding through `did:jwk` when the credential profile enables it (off by default); a bound credential can be presented only by the key holder; 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