Data minimization and purpose limitation by design

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 source binding is the configured rule that connects a claim to the specific source fields it reads. 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

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 one layer down, at the binding between a claim and its source. A source binding reads the fields it is configured to project (the declared binding.fields, plus the lookup and freshness fields), so “read only what the rule needs” depends on the binding being configured that way rather than being automatically derived from the rule. A request that supplies an input path outside a declared allow-list is rejected, so a binding cannot over-collect by accident. The allow-list converts “read only what you need” from an aspiration into a gate that refuses out-of-scope inputs before they reach the source.

Purpose limitation as an enforced gate, not a label

Purpose limitation in this design is more than a field written into a log. It is enforced as a policy decision before any source is read. Where a source is configured to require a purpose, a request that omits the purpose header is rejected, and the supplied purpose is recorded in the audit record. Beyond recording it, the evaluation component combines the claim’s permitted purposes with the source binding’s permitted purposes and denies the request before source access if either set rejects the stated purpose.

A matching policy carries the same idea further: it binds a source read to a declared purpose and relationship context and constrains which inputs may identify the subject, and a request whose purpose, relationship, or inputs the policy does not admit is refused before the source is touched. 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

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. 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 self-attestation (wallet) issuance path requires 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 subject match collapses by default to a single public reason (evidence not available), with the granular reason kept only in the audit record, so the lookup surface cannot by default be used to confirm whether a person exists in a registry.

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

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

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

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 clearest example is the fallback when no matching policy is configured. With no matching policy in place, a binding skips the binding-level gating (no purpose gating, no relationship gating, and no input minimization) and falls back to identifier-only resolution. Claim-level purpose constraints still apply, though: the claim’s own permitted purposes and the deployment’s allowed-purposes list are enforced before the source is read, so a claim-purpose mismatch is refused with no source reads. Purpose limitation is therefore not entirely absent without a matching policy; what is missing is the binding-level gating.

The existence-oracle protection is also defeasible. The matching surface collapses failures to a single public reason by default, but a deployment may disable that collapse and surface not-found, ambiguous, or rejected outcomes, an over-disclosure risk the operator controls.

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.

Related

• Disclosure modes and computed answers: how disclosure modes are selected and policy-bound
• Threat model: the boundaries, assets, and threats behind this posture
• Security overview: the high-level security summary
• Known limitations and non-guarantees: the full inventory of edges
• Records stay home: what stays inside the institution’s boundary and what crosses it
• The security and protocol specifications: RS-SEC-G, RS-DM-CLAIM, RS-PR-NOTARY, RS-PR-RELAY