Trace the digital identity lifecycle

System and boundaries

Map the parties before the events. Include the subject, credential service provider, identity proofing service, authenticator, verifier, identity provider, federation protocol, relying party, lifecycle source, provisioning service, application account, session stores, policy system, evidence sinks, and recovery operators.

Assign stable identifiers at each boundary. A human resources record, identity-provider subject, application account, and email address are not automatically the same identifier. Record the binding rule and authority for each link.

Request and decision flow

Trace these stages:

1. Proof and enroll: Resolve the applicant, validate evidence, verify ownership, create the subscriber account, and bind authenticators.
2. Authenticate: The claimant proves control of bound authenticators to a verifier at a selected assurance level.
3. Federate: The identity provider issues a result for the intended relying party. The relying party validates it and maps the issuer and subject to local state.
4. Establish session: The relying party creates session state with explicit idle, absolute, and reauthentication limits.
5. Authorize: Policy evaluates the authenticated principal, resource, action, and current context.
6. Provision and change: Lifecycle events create, update, disable, or remove accounts, groups, and permissions.
7. Recover: A controlled process replaces lost authenticators or restores account access.
8. Terminate: The system disables identity state, revokes authenticators and sessions, removes authority, and preserves necessary evidence.

At each stage, name the input authority, output, assurance, maximum age, consumer, and evidence.

Failure domains

Test failures that cross stages:

• Strong authentication protects an account that was linked to the wrong person.
• A valid federation result maps to the wrong local account because email was used as a global key.
• SCIM disables the account but an old session or local application permission remains active.
• Recovery adds a weak authenticator and leaves the stolen authenticator valid.
• A mover receives a new group while obsolete direct grants remain.
• The identity provider terminates the account while a long-lived connection continues.

Measure end-to-end effect. A successful source update is not proof that access ended.

Design tradeoffs and residual risk

Central identity improves consistency but increases shared impact. Fast propagation reduces stale access but adds dependency and availability pressure. More attributes can support policy but increase privacy, mapping, and freshness risk. Strong recovery can be slower during legitimate loss.

Record residual risk for each cross-system delay and manual exception. State the owner and review trigger.

Pomerium boundary

Pomerium acts as a relying party to an OpenID Connect identity provider, creates its own session, evaluates route policy, and can pass a signed identity assertion to an upstream. It does not perform the provider's proofing, authenticator enrollment, or recovery. It does not provision application accounts or remove application sessions.

Exercise

Choose one employee and one application. Draw the lifecycle from the authoritative joiner event through proofing, authenticator binding, first sign-in, federation, Pomerium session, application account, role change, recovery, and termination.

For each edge, record the identifier, authority, maximum delay, failure result, and evidence. Run one termination test. Disable the source identity and measure when new route requests, existing connections, and application actions stop.

Evaluation checklist

• Can every account binding be traced to an authoritative identifier and event?
• Are proofing, authentication, federation, provisioning, authorization, and session state separate?
• Does recovery preserve the intended assurance and revoke replaced authenticators?
• Do mover events remove obsolete direct and group authority?
• Does termination cover sessions, connections, local accounts, delegated authority, and recovery paths?
• Is end-to-end revocation latency measured instead of inferred?