SL2 Session Termination: What Scope Should "Terminate" Mean?

[ttripp]

SL2 Session Termination: What Scope Should "Terminate" Mean?

Context

The SL2 requirement says applications "MUST terminate sessions at the request of the Identity Service." In the 2026-01-13 and 2026-01-20 meetings, we agreed that "kill all the things" is the crisp, high-value MVP. But the current language does not clarify what "terminate sessions" requires the RP to do.

I mentioned the agent task concepts and Dick asked me to write up the use cases to help explain the concepts so we can align on SL2 MVP and the protocols.

The Ambiguity

When the IdP requests termination, should the RP:

A. Invalidate the interactive session only?
The user must re-authenticate to start new interactive activity. But existing Refresh Tokens and background tasks (agents, sync jobs, queued exports) can continue until they naturally expire.

B. Revoke all active authorization for that user? - "Kill all the things"
All sessions end. Refresh Tokens become invalid. Access Tokens are revoked, ignored, or forced through a revocation-aware path (for example via introspection). Background tasks lose the ability to call APIs. The user must fully re-authenticate and re-authorize.

Both are interpretations people use today and the need for global kill is agreed by everyone, but they have different purposes. The key difference is whether offline/background authorization survives, which is something that will come into more prominence in the age of agents.

Three Possible Scopes

To frame the discussion, here are three scopes the group could define:

Scope	What Happens	Offline Access
Session Invalidation	Interactive session ends. User must re-auth for new activity.	Continues
Session-Scoped Revocation	Session ends, plus all tokens issued from that session are revoked. Other sessions unaffected.	Revoked for that session only
Global Revocation	All sessions and all tokens for that user at the RP are revoked.	Revoked entirely

Note: Session-Scoped Revocation requires the RP to track which tokens came from which session. Many RPs do not have this binding today.

Why This Matters in the World of AI Agents

In modern "agentic" systems, a user interaction commonly creates a long-running task that continues outside the user's immediate request/response cycle. A representative industry pattern (for example, the Agent2Agent protocol) models this as:

• A user message creates a Task (a stateful unit of work with an ID and lifecycle).
• The system returns immediately with a task handle, while the task continues asynchronously.
• Progress and outputs ("artifacts") are delivered later via streaming updates, polling, or push notifications.

This matters for IPSIE because an RP can have a short-lived interactive session (browser/UI) while also running long-lived background work (agents, sync jobs, exports) that relies on non-interactive credentials.

• If "terminate sessions" only means "end UI," background authorization survives and agents keep running allowing the user to return later
• If it means "kill all the things," background work loses the ability to call APIs.

For example, if a user kicks off agents while on the VPN and then drops the VPN connection, a policy should be able to invalidate the session, require re-authentication, but allow the agents spawned from that session to continue. Alternatively, if credential compromise is detected, then a policy should be able to force global revocation of everything the user has done and all of their agents.

Use Cases

Note: Every IdP may treat these as different policies and determine the behavior. Below are just some examples.

Scenario	Scope	Possible Enterprise Policy
User-initiated logout (UI logout / account switching)	Session Invalidation	User clicked logout in the app or IdP. Clear interactive state; in-flight tasks may finish based on RP policy.
IdP-requested termination (security event)	Global Revocation	IdP detected a security issue and requests the RP terminate access. This is the "kill all the things" scenario.
Policy-enforced re-authentication (step-up)	Session Invalidation	Session no longer meets auth requirements (e.g., MFA now required). Force re-auth; revoke only if policy requires it.
Context/risk shift (step-up)	Session Invalidation	User moved to untrusted network; require re-auth to continue.
Context/risk shift (high-confidence compromise)	Global Revocation	IdP has strong signal of compromise; treat as security incident.
Lost/stolen device	Session-Scoped Revocation	Kill that device's tokens. Leave other devices alone.
Abnormal agent behavior	Session-Scoped Revocation	An agent instance starts making excessive requests; terminate that instance without logging the user out everywhere.
Password reset	Global Revocation (common)	Many orgs treat password reset as a security boundary that purges sessions; some may choose Session Invalidation.
Credential compromise	Global Revocation	Unknown blast radius. Revoke everything for this user at this RP.
Employee termination	Global Revocation	Access ends immediately. Any background task that requires user authorization should fail/pause.

Questions for the Group

1. What should SL2 require? Should SL2 require Global Revocation ("kill all the things") as the MVP MUST?

2. Should the IdP signal which scope it wants? A network change might warrant Session Invalidation. A security incident warrants Global Revocation. Should the RP behave differently based on the request?

3. Is Session-Scoped Revocation in scope for IPSIE? It addresses real use cases (lost device, rogue agent) but requires session-to-token/instance binding that is not standardized.

My View

I lean toward requiring two capabilities at SL2:

1. Global Revocation (MUST) — the "nuclear option" for security incidents. This aligns with the group's "kill all the things" consensus.

2. Session Invalidation (MUST) — end the interactive session and allow previously started agents/tasks to continue, but without revoking tokens globally. This will be a common use case in the age of agents: a user logs out or hits a policy boundary, and everything spawned from that session should stop, but the user's other sessions and offline access should remain intact.

I realize there are several related spec (OP Commands, Global Token Revocation, SSF/CAEP mapping) and would like to hear from the experts on them (Aaron, Dick, Karl, Atul) on how these scopes fit with their work.

References

IPSIE Working Group

• IPSIE Levels Specification
• 2026-01-13 Meeting: Consensus on "kill all the things" as a use case
• 2026-01-20 Meeting: "The challenge will be to define the scope of the session." (Dick)

Related Specifications

• A2A Protocol
• OpenID Provider Commands 1.0 (draft 02)
• OAuth 2.0 Global Token Revocation (draft 05)
• OpenID CAEP 1.0
• OpenID RISC 1.0

[dickhardt]

@ttripp thanks for writing this up!

@aaronpk @mcguinness @tulshi

[mcguinness]

If I understand your model correctly, your "Session Invalidation" use case maps to existing OIDC Logout spec behavior correct (https://openid.net/specs/openid-connect-backchannel-1_0.html#BCActions)? A RP can request an offline_access refresh token today and use access tokens for background tasks like data synchronization and continue to do so after receiving an OIDC logout request and closing the interactive session. Your agent use case seems like a specialization of this existing use case.

My feedback is that the market has voted on the SLO behavior and my conclusion was that it wasn't valuable enough to implement and had too many side affects/caveats specific to app architecture and implementation for it to be useful.

Examples:

• Some applications where stateless and didn't have way to process the sid claim in the logout token for a back channel call
• Some applications where multi-product or distributed and couldn't correlation all the child sessions
• Native application sessions often live independently then a web session that was used for SSO from the IdP
• Growth Metrics forced apps to implement some sort of keep me signed in to track behavior/usage independent of IdP

I'm still a bit unclear on how we would write a conformance test and have it be meaningful for the many types of app models/architecture we see deployed in the wild.