Skip to content

Role-Based View

Scoped-view artifact — instantiates Role-Scoped Disclosure Minimization

Gives each role a standing, pre-shaped window onto the source record that exposes only the fields that role's work requires, so the surplus is never in the view to leak.

A Role-Based View is a standing projection of a rich record, defined once per role, that returns only the fields that role legitimately needs. Its defining move is to bake the role-to-field mapping into a durable artifact — a database view, a scoped API, a filtered screen — so minimization is the default shape of the data a role ever sees, not a decision made per request. A billing clerk's view and a nurse's view are different windows onto the same record; each is a fixed contract of columns, and the fields outside it are never returned to that role's client in the first place. It is the structural, always-on counterpart to a per-request ask: where Purpose-Based Access Request justifies a one-off grant, the role view is the steady-state entitlement each role carries.

Example

An HRIS holds each employee's full record: compensation, performance notes, national ID, bank details, the reason behind a medical leave, home address. A line manager who logs in does not get the record — they get the manager view: name, job title, PTO balance, review status, and whether a leave is approved, but not the salary-band comparison, the national ID, the bank details, or why the leave was taken. Payroll's view is the mirror image: bank details and comp, but not performance notes. Each view is specified as a named set of columns and enforced at the database, so the surplus columns are simply absent from every query a manager runs. When a manager genuinely needs a field outside the window — a home address to send a gift — that is an exception request, not a permanent widening of the standing view.

How it works

  • Map each role to its necessary fields. For every role, decide the columns its work actually requires — a field-level necessity rule made concrete.
  • Materialize the window. Express that subset as a durable view or scope, ideally a whitelist (name what is shown), so new fields added to the source default to hidden.
  • Enforce at the source. Bind the view at the database or service boundary so the excluded fields are never serialized to that role, not merely hidden in the UI.
  • Recertify. Periodically re-review each role's window and prune fields that accreted but aren't used.

Tuning parameters

  • Role granularity — a few broad roles versus many narrow ones; narrower roles leak less but multiply maintenance and risk role explosion.
  • View composition — whitelist (name the fields shown) versus blacklist (name the fields hidden); a whitelist fails safe when the schema grows.
  • Static vs. parameterized — one fixed view per role versus a view filtered by row or attribute (this manager sees only their own reports); parameterization tightens scope but edges toward attribute-based policy.
  • Enforcement layer — database view, application filter, or API scope; the closer to the source, the harder it is to bypass.
  • Recertification cadence — how often role-to-field grants are re-reviewed and trimmed.

When it helps, and when it misleads

Its strength is that minimization becomes ambient and cheap: a role's window is defined once and every access inherits it, which is the principle of least privilege rendered as an artifact rather than a habit.[1] Nobody has to remember to minimize; the surplus isn't there to forget. Its failure mode is role bloat — fields quietly added "temporarily" and never removed, and coarse roles that lump distinct needs together so the view drifts toward the union of everyone's wants rather than any one job's need. The classic misuse is defining a role's window to match what a powerful stakeholder wants to see rather than what the work requires, then treating that as the minimum. The discipline is periodic access recertification and whitelist composition, so entitlements shrink by default and grow only on demonstrated need.

How it implements the components

  • field_level_necessity_rule — the view is that rule made durable: for each role, precisely which fields are necessary and which are withheld.
  • minimum_payload_contract — the view's column set is the fixed contract of what that role receives on every access.

It defines the standing per-role window; it does not capture the requester's purpose — that's Purpose-Based Access Request — nor transform values (Tokenization or Masking), nor strip a one-off document (Field-Level Redaction), nor shape per-response API payloads (API Response Projection).

Notes

A role is a blunt instrument: N roles can never capture N × situations, so any role view is a compromise between too many roles to maintain and too broad a window to be safe. That is precisely why it is meant to sit alongside finer tools — the attribute-based policy for row- and context-level decisions, and Purpose-Based Access Request for the exceptions the standing window can't anticipate.

References

[1] The principle of least privilege — that a subject should hold only the access its function requires — is the design norm a role-based view materializes; role-based access control (RBAC) is its standard institutional form. ↩