Learning outcomes
- Map every identity and access field from authoritative source to decision, disclosure, log, and deletion.
- Replace broad profiles and global identifiers with decision-specific inputs and scoped references.
- Preserve investigation and authorization needs without copying sensitive claims everywhere.
- Test field removal, purpose change, recipient access, retention, and deletion across the complete path.
Protection need
Identity systems often collect a complete directory profile and copy it into sessions, tokens, headers, logs, traces, analytics, and applications. Most decisions need fewer fields. The objective is to keep enough current data for authentication, route policy, upstream mapping, revocation, and investigation without creating unnecessary exposure or cross-service history.
Security objectives and requirements
Inventory each field with source, meaning, authority, decision, recipient, format, identifier scope, refresh, access, log use, retention, deletion, and owner. Include subject IDs, email, name, groups, roles, device state, network facts, risk signals, route, time, policy result, and application action.
For every field, ask:
- Which exact decision or operation requires it?
- Can a Boolean, category, scoped identifier, or server-side lookup replace the raw value?
- Must every recipient receive it?
- How fresh must it be?
- How long must the value and evidence persist?
Separate authentication identity from application profile. Separate route authorization from application object permission. Do not put sensitive source attributes into a client-readable token if only the server needs a derived decision.
Security invariants and evidence
- Each claim and signal has one documented decision purpose and accountable source.
- Upstreams receive only fields they need and validate the documented assertion.
- Unrelated applications do not receive one global correlating identifier when a scoped subject works.
- Logs retain the minimum identity needed for stated investigations and protect any resolution mapping.
- Removed or changed source data expires from sessions, caches, assertions, analytics, and backups within defined limits.
Evidence includes schema review, token and header captures, log sampling, recipient access review, field-removal tests, retention jobs, and deletion through restored backups.
Failure cases
- All directory groups enter a token although one route needs one derived membership result.
- Email serves as global identity across unrelated tenants and later changes or gets reused.
- Device telemetry is collected continuously but policy uses one simple managed-device state.
- Full claims appear in error logs and third-party traces.
- A short session lifetime exists, but analytics retains route history indefinitely.
- Removing a claim breaks an undocumented downstream and reveals hidden purpose expansion.
Design tradeoffs and residual risk
Fewer embedded claims can require current lookups and add availability and latency. Scoped identifiers reduce correlation and complicate cross-application support. Short retention limits exposure and can reduce investigation. Derived Boolean decisions can hide why access was allowed unless evidence records source and policy version.
Minimization does not prevent misuse of the remaining data. Compromised endpoints and recipients can copy values they legitimately receive.
Pomerium boundary
Pomerium can use configured identity and device context in policy and can pass documented identity to upstreams. Operators select provider claims, directory data, device signals, policy, assertion consumers, log destinations, and retention. Applications must request and store only the identity data they need for their own permissions.
Exercise
Capture one real authentication and request path. Create a field inventory from identity provider through Pomerium session, policy, upstream assertion, application log, central telemetry, and backup.
Remove or derive at least three fields, scope one identifier, and shorten one retention period. Test authentication, authorization, revocation, support, investigation, deletion, and recipient behavior. Record the performance and evidence tradeoff.
Evaluation checklist
- Can every claim, identifier, signal, and log field name one current decision, recipient, retention, and owner?
- Can a derived result, lookup, scoped subject, or coarser value replace raw or globally stable data?
- Do tokens, headers, errors, traces, analytics, exports, and backups follow the same minimization rule?
- Does field removal expose undocumented consumers or secondary purposes that need review?
- Can the system still revoke, investigate, and delete with bounded identity resolution and no permanent broad history?
Next learning unit
Data Minimization and Purpose Limitation
Collect, use, expose, and retain only the data necessary for a stated operational purpose and bounded period.
