APIs over-share records
A vehicle licensing service queries the driver registry to verify a customer’s licence before authorizing a transaction at the counter. The API returns the full record: date of birth, home address, every endorsement, every suspension going back ten years. The clerk needed a yes or no. They now have a copy of the customer’s driving history on the screen, in the application’s database, and in every backup the service keeps.
The problem
Section titled “The problem”Most registry questions are narrow. Is this company active? Is this licence valid? Is this person enrolled? The API the caller can reach usually answers by returning the whole record.
Over-sharing happens inside narrow APIs too. A route can expose enough fields, identifiers, or free-text values to let a caller reconstruct more than the service required, without ever asking for it directly.
Why it matters
Section titled “Why it matters”Every field a caller receives becomes a field the caller must protect, retain, justify, and eventually delete. Broad records turn every integration into a privacy obligation the caller did not ask for and the registry owner cannot inspect.
A reviewer asking “what was disclosed, and why?” cannot answer it from the API contract: the contract said “everything in the record.” The registry owner is now trusting every downstream system to do the right thing with data it never asked for.
Why common approaches stall
Section titled “Why common approaches stall”Role-based access to whole records can reduce the number of callers but does not change what each caller receives. The clerk with the right role still gets the full driving history.
Custom minimized endpoints work for one workflow. They stall when the next evidence question requires another bespoke endpoint, another review cycle, and another disclosure rule that lives in nobody’s documentation.
Field-level filtering at the gateway strips fields on the way out. It also strips them with no record of what was disclosed, who configured the filter, or whether the filter is still correct after the source schema changes.
What Registry Stack changes
Section titled “What Registry Stack changes”The caller does not need to receive the full record. The deployment chooses what gets returned.
Registry Relay exposes protected entity routes with configured field projection and caller scopes. A route can be configured to return “licence valid” without ever exposing date of birth or suspension history.
Registry Notary evaluates configured claims and returns a claim-result document, CCCEV-shaped JSON-LD, or an SD-JWT VC credential. The licence verification can be a signed yes/no that the calling service stores in place of the record.
Registry Manifest publishes evidence-offering metadata so a caller can discover, before writing code, which evidence path exists for the question they actually need answered.
The vehicle licensing counter still gets its answer. The customer’s driving history stays where it belongs. For the broader model, see the architecture overview.
What is built today
Section titled “What is built today”Registry Relay documents declared field projection, caller scopes, and evidence-offering
metadata routes.
Registry Notary documents disclosure modes (value, predicate, and redacted), claim
evaluation, CCCEV-shaped output, direct credential issuance, and OID4VCI issuance.
Registry Platform provides shared primitives used by Relay and Notary for audit,
authentication, HTTP safety, and SD-JWT handling.
See evidence issuance and Registry Notary reference.
What is future-facing or out of scope
Section titled “What is future-facing or out of scope”Registry Stack does not decide whether a caller is legally entitled to a fact. The deployment must define policy, configure allowed disclosure modes, and decide which evidence shape is appropriate for the purpose.
Lineage evidence, chain-of-title evidence, and broader sector-specific evidence profiles are future-facing unless a source repo documents and tests the pattern.