Skip to content
Registry StackDocsv0.13.0

Data minimization and purpose limitation by design

View as Markdown

As a data protection officer or privacy reviewer, you are asked whether a system supports the principles you work to (data minimization, purpose limitation, accountability) and where those supports stop. This page answers one question about Registry Stack: how does its architecture support data minimization and purpose limitation by design, where are those supports conditional on how an operator configures a deployment, and which data-protection obligations does the architecture not address at all? This page makes no compliance claim and gives no legal advice. Conformance to the underlying specifications does not imply conformance to any external standard, nor to GDPR or any data-protection regulation, and no jurisdiction-specific reading is offered: that judgement remains yours. The specifications here are all draft, pre-1.0 documents and may change, so treat the design as a posture under development rather than a finished or warranted product. Four terms are enough to follow this page. A claim is one pre-modelled question (one decision or one extracted value) that a system can ask about a person against a registry the institution already holds. A Relay consultation is the compiler-pinned contract that connects a registry-backed claim to the minimized typed outputs Relay may return. Minimized evidence means a response shaped by data minimization or selective disclosure; a purpose-bound request is a request that carries or is evaluated against a stated purpose.

How the claim model limits collection at the source

Section titled “How the claim model limits collection at the source”

The first place minimization appears is in the unit of data the system is built around. A claim definition describes one decision or one extracted value, not a whole record, so returning a full record would over-collect relative to the question actually asked. The design treats the narrow question, not the record, as the thing to be answered.

That principle is enforced at two separate boundaries. A Relay integration declares closed request inputs and minimized typed outputs. A Notary claim can consume only the outputs of its compiler-pinned consultation, or the configured authenticated context for self-attestation. Callers cannot choose a source destination, credential, selector field, adapter capability, or undeclared output at request time.

The project author still decides which Relay outputs the claim needs. Minimization therefore depends on a reviewed integration contract and synthetic fixtures, not on Notary deriving a source projection from the claim rule.

Purpose limitation as an enforced gate, not a label

Section titled “Purpose limitation as an enforced gate, not a label”

Purpose limitation in this design is more than a field written into a log. A Registry Stack project authors the evidence-service purpose once and compiles it into the Notary claim contract and the Relay consultation profile. Notary rejects a missing or mismatched purpose, missing scope, or inadmissible typed input before calling Relay. Relay separately verifies its workload caller, the same purpose, the consultation profile, and the contract hash before source work.

The compiler-pinned input mapping carries the same idea further: the request can populate only declared typed inputs, and Notary cannot substitute a different consultation when authorization or contract validation fails. The effect a reviewer should take away is that purpose, when configured, acts as a precondition for access rather than an after-the-fact annotation.

Several of these protections apply only when configured; the operator-responsibilities section lists them.

Minimization at the output: disclosure modes and selective credentials

Section titled “Minimization at the output: disclosure modes and selective credentials”

Minimization also applies to what leaves the boundary. A claim’s result can be shaped into one of three disclosure modes: value returns the full value, predicate returns only the true/false satisfaction, and redacted hides the value entirely. A privacy-sensitive claim is expected to default to the least-revealing mode that still answers the question. (How a mode is selected and policy-bound is covered in Disclosure modes and computed answers and is out of scope here.)

The redacted mode is worth a reviewer’s attention because it shows minimization without loss of accountability: a redacted result carries neither the underlying value nor the satisfaction outcome, yet the evaluation stays referenceable and verifiable through an evaluation identifier, a verification identifier, and a claim hash. You can audit that an evaluation happened and verify it later without the result itself disclosing anything about the person.

When the system issues a credential rather than returning a direct answer, minimization continues at presentation time. Issuance also requires one exact compiler pin for every registry-backed claim in each selected root’s dependency closure, plus one normalized execution record per unique Relay consultation ULID. Notary retains those private Relay ids and acquisition times only when all selected roots share a mutually validated credential profile; registry-backed evaluation-only claims retain no private issuance provenance. A deterministic unkeyed SHA-256 binding detects partial mutation between a claim pin, execution record, and claim provenance, but is not an authenticity anchor against an operator able to rewrite all committed fields and the digest. A source-free, delegated, or legacy evaluation cannot cross the credential trust boundary. Issued credentials are SD-JWT VC: a verifiable-credential format in which the signed body carries only a SHA-256 digest of each selectively disclosable field, so a field the holder does not present stays hidden, and the holder controls what is revealed. Selective disclosure here is at the claim (or configured-projection) level: by default each claim becomes one disclosure carrying its whole value, so an object-valued claim is revealed as a unit unless an explicit projection splits it into separately-disclosable fields. Holder binding (tying the credential to a holder key with did:jwk) is enabled by default per profile, and the registry-backed OID4VCI issuance path requires EdDSA proof of possession; an operator can explicitly configure holder_binding.mode: none for a bearer-style credential profile. The direct claim or evaluation result is not a credential and is never holder-bound. One caveat for a reviewer: the issuance surface is a profiled, partial subset, not a full credential-issuer implementation, and should not be read as general wallet interoperability or full standards conformance.

A further minimization detail guards against a subtler leak. A failed or ambiguous consultation does not let Notary choose a source record. The public Notary surface reports unavailable evidence without returning the raw Relay observation.

Data stays at source: distributed custody

Section titled “Data stays at source: distributed custody”

Underneath all of this is an architectural choice that matters for minimization at the system level: data stays at source. The design premise is distributed custody: the stack provides an API surface for lawful exchange between authorities and does not aggregate data into a central system. The read component must not mutate source registry data and exposes no write-back route, and runtime services are read-only in this version, with no source-registry data-mutation routes at all.

For a reviewer this has a direct consequence. Because the architecture cannot alter or delete source records, it is also why no erasure flow exists at the source layer: the design has no mechanism to reach into and change the registry it reads from. The What the architecture does not provide section describes this as a limit, not a feature.

One related boundary is positive rather than cautionary. The portable metadata the stack publishes must not carry person-level data or runtime secrets and bindings, which is precisely why those artifacts are safe to share: they hold no personal data. But publishing metadata only describes; it does not authorize access, enforce a policy, or assert that any record exists, so a published manifest carries no data-protection guarantee about live data.

Audit as an accountability primitive

Section titled “Audit as an accountability primitive”

Accountability is supported through audit, which is treated as a security control rather than an optional log. Every request that returns person-level records or claim results must be recorded with at least the caller principal, the scopes exercised, a request identifier, and the purpose value where one was supplied, and a deployment can run audit fail-closed so that a request whose audit record cannot be written does not succeed.

Audit fail-closed is a capability a deployment can turn on, not a guarantee that every route in any given build has been individually audited against it. Whether a particular deployment meets it is something a reviewer verifies in that deployment, not something the design asserts on its behalf.

What the architecture does not provide

Section titled “What the architecture does not provide”

Some of the most important things for a DPO to know are the absences. The full, canonical inventory is in Known limitations and non-guarantees.

  • No data-subject erasure or right-to-be-forgotten workflow: There is no built-in erasure or deletion flow anywhere in the design, so it does not satisfy erasure obligations on its own. As the Data stays at source: distributed custody section notes, the read-only design cannot mutate source records, so erasure, where it is required, remains an operation on the source registry outside this system.
  • No rectification or data-subject-rights flow: Beyond erasure, there is no rectification or general data-subject-rights mechanism.

Revocation mechanics, federation’s cross-authority scope, aggregate-analytics privacy budgeting, and the general compliance disclaimer are stack-wide absences rather than specifics of data minimization or purpose limitation, but a data-protection assessment should weigh them too. See the known limitations hub for the full inventory.

Operator responsibilities: what the design leaves to you

Section titled “Operator responsibilities: what the design leaves to you”

The minimization and purpose-limitation posture described above is the design default, but the operator owns the configuration. Several of the protections are conditional, and a reviewer should test the deployment, not the design, for each one.

The main conditional control is the authored projection. The compiler prevents Notary from bypassing the Relay consultation, but it does not decide which typed outputs an institution has a lawful reason to expose. Project reviewers must confirm the source authority, selector inputs, output projection, purpose, claims, and disclosure defaults together. Operators must then bind only the reviewed source and workload credentials to the generated product inputs.

More broadly, the architecture defines primitives and leaves a large set of data-protection-relevant controls to the operator. Secret and key provisioning, audit retention and storage, tenant isolation, transport security, edge rate limiting, deployment configuration, and incident response are not defined by the design; they are responsibilities you provision and verify in a deployment. For the concrete stores and product expiry points, see Retention and persistent state. Registry Stack offers minimization, purpose limitation, and accountability as enforceable design primitives, but whether a given deployment realizes them (and whether it meets any legal obligation) depends on how the operator configures and runs it.

Section titled “Related”