Registry stack documentation: machine-readable Markdown. Index of all pages: https://docs.registrystack.org/v/0.38.0/llms.txt Full corpus: https://docs.registrystack.org/v/0.38.0/llms-full.txt # Data minimization and purpose limitation by design > How the Registry Stack architecture supports data minimization and purpose limitation, where those supports depend on operator configuration, and which data-subject-rights obligations it does not address. 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 *requirement* is one predefined, reviewed question about one set of subject roles, together with the exact set of values its answer may carry, asked against a registry the institution already holds. A *Relay consultation* is a Relay-owned contract that fixes the closed request inputs and the minimized typed outputs one protected read route 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. Two runtime patterns carry these principles, Registry Relay and Evidence Gateway, and each enforces them at its own boundary rather than in one chain. ## How the requirement model limits collection at the source The first place minimization appears is in the unit of data the system is built around. A requirement describes one reviewed question and the exact values its answer may carry, 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. An Evidence Gateway requirement uses a closed single or search-then-fetch acquisition whose sources, origins, methods, paths, headers, and client-side response projections are all set by reviewed configuration, and it discloses only the concepts it declares. Callers cannot choose a source destination, credential, selector field, adapter capability, or undeclared output at request time in either product. The project author still decides which source fields the answer needs. Minimization therefore depends on a reviewed contract and its fixtures, not on a runtime deriving a source projection from the question it was asked. ## Purpose limitation as an enforced gate, not a label Purpose limitation in this design is more than a field written into a log. In Evidence Gateway, the purpose a caller states is one dimension of a single authorization decision that also binds the requester, the requirement revision, every subject role and selector profile, the subject authority, and the audience. The match must be exact and complete, and it happens before audit, credential resolution, or source access, so a request with a missing or unauthorized purpose reaches no source at all. Relay separately verifies its own caller, scopes, and governed policy gates before source work. The closed request schema carries the same idea further: a caller supplies a nonce, a requirement, a purpose, one selector per declared role, and optionally a holder public key that matters only to the SD-JWT VC response format. There are no thresholds, expressions, paths, headers, source fields, or response projections a caller can set. 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: closed value forms Minimization also applies to what leaves the boundary. Evidence Gateway has no caller-selectable disclosure at all, so there is no request-time negotiation to review. Instead, a requirement declares one to sixteen *concepts*, and each concept fixes the exact *value form* its fact takes: a boolean, a code from a reviewed codelist, a bounded identifier or number, a date or time bucket, an audience-scoped opaque reference, or a reviewed closed structure. The set of forms is closed at twelve, and a requirement issuing under the holder-bound subject binding mode may use ten of them: the two entity-reference forms take the audience as a derivation input, so a holder-bound requirement declaring either is refused at startup rather than served with a degenerate reference. The answer carries a value for each declared concept and nothing else, and the assertion schema rejects additional properties. For a reviewer, this moves the disclosure decision from request time, where a caller could argue for more, to authoring and review time, where an operator justifies it once and can be held to it. (The forms themselves are catalogued in [Disclosure modes and computed answers](../disclosure-modes-and-computed-answers/) and are out of scope here.) There is no equivalent of the retired redacted mode, and this is structural rather than an omission: an assertion must carry at least one supported value, so an assertion with nothing in it cannot be produced. A request that cannot be answered returns a problem document and no assertion. Minimization can continue past the response boundary when the operator enables the SD-JWT VC format. That format is a second encoding of the same assertion, never a credential lifecycle: the signed body carries a SHA-256 digest of each selectively disclosable value, so a holder can later present a subset. A value uses one disclosure by default. A governed structured value can instead place each direct field in a separate disclosure while keeping nested field values atomic. Two limits matter to a reviewer. The issuer appends every disclosure, so the response the caller receives reveals the same set as the signed JWS, and holder-side omission is outside this version. Evidence Gateway also runs no wallet interaction and speaks no part of OID4VCI. Under the default audience-scoped binding mode a caller may supply a holder public key that Evidence Gateway echoes into the `cnf` claim for a relying party to check itself, and nothing verifies it. A requirement may instead declare the holder-bound subject binding mode, which changes what the credential is bound to and moves the audience check from issuance to presentation. The service still issues no key-binding JWT and holds no presentation state; verification is a relying-party act, performed by the portable verifier or the `evidence verify-presentation` operator command. For minimization the mode is a trade rather than a gain: the same holder key, trust domain, purpose, subject role, selector profile, and selector values yield the same binding for every verifier, so a holder who reuses one key is correlatable across the verifiers it presents to. Holder-bound issuance also refuses the two entity-reference value forms, and a holder-bound assertion carries neither an audience nor the request nonce, because it names no relying party to echo them to. Purpose behaves the same way on both sides of the boundary. A relying party compares the issuance purpose as signed provenance: it records why the assertion was produced and licenses, limits, or authorizes nothing about what the relying party may now do with it. Under the holder-bound mode that record is also disclosed to every verifier the credential reaches, and it is a low-cardinality attribute, so treat it as visible rather than internal. A further minimization detail guards against a subtler leak. No match, ambiguity, a missing required fact, and an unresolved derivation input all collapse into one problem response with the same title and body shape, so a caller cannot use a refusal to learn whether a record exists. The outcomes stay distinct in the audit record; collapsing is a property of what the caller sees, not of what the operator can review. ## 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](#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 an assertion 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. Evidence Gateway takes that further and is fail-closed by construction rather than by configuration: it writes an access record before it contacts any source and a release record after signing and before release, and an audit failure fails the request. Selector, source, and disclosed values never appear in those records or in logs, and raw source responses are never persisted. 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](../known-limitations/). - 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. There is also no revocation, suspension, status list, or credential-status endpoint of any kind: an assertion carries a validity window and is otherwise final once released. Cross-authority federation, aggregate-analytics privacy budgeting, and the general compliance disclaimer are likewise 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](../known-limitations/) for the full inventory. ## Operator responsibilities: what the design leaves to you The minimization and purpose-limitation posture this page describes 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. A runtime can stop a caller from reaching past the reviewed contract, but it cannot decide which values an institution has a lawful reason to expose. Project reviewers must confirm the source authority, selector inputs, output projection, purpose, requirements, and declared value forms together, and Evidence Gateway expects the complete simultaneously enabled configuration to be reviewed as one disclosure surface, since two answers that are each defensible alone can reconstruct a protected value between them. 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](../../operate/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](../disclosure-modes-and-computed-answers/): the closed value forms and what each one reveals - [Threat model](../threat-model/): the boundaries, assets, and threats behind this posture - [Security overview](../../security/): the high-level security summary - [Known limitations and non-guarantees](../known-limitations/): the full inventory of edges - [Records stay home](../records-stay-home/): what stays inside the institution's boundary and what crosses it - The security and protocol specifications: [RS-SEC-G](../../spec/rs-sec-g/), [RS-PR-EVIDENCE](../../spec/rs-pr-evidence/), [RS-PR-RELAY](../../spec/rs-pr-relay/)