Skip to content

API Response Projection

Response-shaping method — instantiates Role-Scoped Disclosure Minimization

Shapes the outgoing response at the producer, composing it from an allow-list of only the fields a given consumer's role and purpose justify, so surplus data is never serialized and never leaves the source.

API Response Projection is the enforcement step that actually builds the minimal payload. Given a record that holds far more than any one caller needs, the producer composes the response from a declared per-consumer view — an allow-list of fields — so that surplus attributes are dropped before serialization and never enter the bytes the consumer receives. The one idea that makes it this mechanism and not its siblings: minimization is achieved by never emitting the surplus field, at the source, rather than by deciding who is entitled (a policy question) or by obscuring a value that is still present (masking). What is not in the payload cannot be stored, forwarded, recombined, or leaked downstream — the boundary is the projection itself.

Example

A ride-hailing platform's driver app needs just enough about a rider to complete the trip: a first name to greet by, a pickup pin, a rough dropoff area, and the trip id. The rider record behind the API holds much more — full legal name, phone number, home address, saved places, payment token, rating history. The driver-scoped projection declares the view {first_name, pickup_point, dropoff_area, trip_id}, and the server assembles each driver-facing response from exactly those fields. The rider's phone is exposed only as a relay number the app can dial, never the real one.

The effect is structural, not cosmetic. Because the home address and payment token were never placed in the JSON the phone downloads, a compromised device, an over-eager analytics SDK, or a debug log on the driver side has nothing to leak — the surplus was left at the source. Contrast the weaker alternative of sending the whole rider object and asking the app not to display the address: that data has already crossed the boundary and is one logging call away from exposure.

How it works

The method is server-side field selection against a declared schema, composed as an allow-list rather than a deny-list. The producer enumerates, per consumer role, the fields that ship; everything else is omitted by construction, so a newly added sensitive field stays hidden until someone deliberately adds it to a view. For a field the consumer must act on but need not see — a phone number to dial, an account to charge — the projection substitutes a relay handle or token rather than the raw value. The projection is the boundary: unlike redaction, which blanks a value inside an otherwise-complete document, projection means the field never occupies the response at all.

Tuning parameters

  • Allow-list vs. deny-list — enumerate the permitted fields (new fields hidden by default, fails safe) or the forbidden ones (new fields ride along, fails open). Allow-list is the safe default.
  • Projection granularity — whole-object, per-field, or down to sub-fields and array elements. Finer projection trims more surplus but multiplies the views that must be maintained.
  • Number of named views — one fixed projection per consumer role vs. a parameterized sparse-fieldset the caller narrows further. More views fit tighter but are more surface to keep in sync with the record.
  • Static vs. dynamic — a fixed per-role schema, or a projection computed from the request's attributes (consuming an Attribute-Based Access Policy decision at call time).
  • Relay vs. omit — for a field needed for action but not for sight, substitute a relay/token instead of dropping it outright — trading a little linkage for the function the consumer genuinely needs.

When it helps, and when it misleads

Its strength is that surplus becomes structurally absent rather than merely hidden: the payload is the smallest thing that does the job, the attack and leak surface shrinks to what was actually sent, and the view is a contract you can test against. It is the enforcement that makes every upstream access decision real.

It misleads in two ways. A deny-list projection drifts dangerously out of sync with the record — add a sensitive column and it silently rides along in every response — which is why the allow-list default matters. And projection controls fields, not what they imply: a coarse dropoff_area can still betray a rare destination, so inference is not solved here. The classic misuse is projecting on the client — returning the full object and hiding the extra fields in the UI — which is not minimization at all, only its appearance. The discipline is to project at the source, allow-list by default, and treat any new field as hidden until a view opts it in, honoring data minimisation[1] as a property of the wire, not the screen.

How it implements the components

  • source_record_map — the projection is defined against the full record's field inventory, so the producer must hold a map of what the source actually contains before it can decide what to withhold.
  • source_side_projection_boundary — it draws the boundary at the producer: surplus fields are dropped before serialization, so the outgoing view is the boundary and the surplus never crosses it.
  • minimum_payload_contract — the declared per-consumer view is the payload contract, enumerating exactly which fields ship and letting both sides check that nothing extra does.

It emits the view but does not decide entitlement — the role-and-purpose profile and the field-necessity rules that authorize a view are Attribute-Based Access Policy; it omits fields rather than obscuring values left in place, which is Tokenization or Masking and Field-Level Redaction; and it does not judge what the surviving fields still let a consumer infer — that review sits with Derived Eligibility or Status Answer and Privacy Impact Review.

References

[1] The principle that data collected or disclosed should be adequate, relevant, and limited to what is necessary for the purpose — expressed, among other places, as the data-minimisation requirement in Article 5(1)© of the EU General Data Protection Regulation. Projection enforces it at the point of disclosure. ↩