# IPSIE WG Meeting Minutes
Date: 2026-01-13

## Attendees

* Aaron Parecki (Okta)
* Dick Hardt (Hellō)
* Atul Tulshibagwale (SGNL)
* Karl McGuinness
* JD Pawar (Workday)
* Travis Tripp
* Shannon Roddy
* Jen Schreiber (SGNL)
* Sarah Cecchetti
* George Fletcher
* Ameya Hanamsagar
* Bertrand Carlier
* Mark Drummond
* Bjorn Hjelm (Yubico)

## Agenda

- Welcome and antitrust policy reminder https://openid.net/policies/
- Notes & Recording Policy https://openid.net/wp-content/uploads/2025/09/OIDF_Notes-Recordings-Policy_Final_2025-09-11.pdf
- OpenID Contributor Agreement reminder https://openid.net/intellectual-property
- Reminder about OpenID Slack
- invite link: https://join.slack.com/t/oidf/shared_invite/zt-3j8ucodu8-bAHQpkpJ1kcrLWNjWAWw0g
- Session Termination - SL2
- AOB

## Notes

Notetaker: Aaron Parecki

* Aaron: Context for session termination in SL2
* Atul: Are the levels up for debate or are we talking about the mechanisms?
* Dick: We are looking for what specs to use
* Atul: Could use CAEP Session Revoked, would need to define in SL2 that an application MUST terminate the session that was established
* Dick: Is that a defined event now?
* Atul: Yes
* Dick: Is the Session Revoked signal from the identity service?
* Karl: Any publisher can send the event, it has a complex subject identifier
* Dick: My understanding is that it's the publisher saying I've revoked sessions
* Karl: Correct, it says that subject's session is revoked
* Aaron: What if the Identity Service doesn't actually terminate the user's session?
* Karl: The session could be a pairwise session identifier with the RP
* Atul: Session Revoked in CAEP means the transmitter has terminated the session, how you identify the session depends on how you describe the subject. You could make it specific or broad like email or device ID using complex subject.
* Karl: A topic to have debate on... SAML single logout and OIDC single logout, adoption has been poor. The use case we're trying to tackle in IPSIE doesn't have a clear mapping. There's user interactive logout like account switching, there's administratively defined session revocations, security incident response. The first challenge at Okta is the SSO federation has its own semantics of what a session is. A mobile app might launch a web page to sign in to the IdP and then the mobile app's server issues tokens, but the web browser session is lost because the mobile app is using OAuth to talk to its backend. How do you have stable identifiers across these tiers? When you have OIDC to the enterprise IdP but then you issue your own OAuth tokens there isn't necessarily a link back to the IdP.
* Dick: To summarize.. you had 3 dimensions, what's happening in the application (web cookie, access tokens)
* Karl: Derived sessions, how do you build a hierarchy, what are the identifiers and artifacts
* Dick: The second dimension was why does the identity service want to revoke a session, one is the user wants to log out, one is something bad happened...
* Karl: There's some granularity on administrative vs security incident. Could want to revoke only a specific device vs a security incident where you want to terminate everything.
* Dick: The third dimension...
* Karl: The identifiers for things
* Atul: That was the reasoning behind the flexibility in the subjects in SSF, giving the flexibility to target a device or broadly like an email
* Dick: It sounds like you mixed two things, how you identify what to do and what you want to do
* Atul: The session revoked event doesn't say what goes into creating the event, it just says "I'm revoking the session under this scope"
* Karl: For those scenarios you can't say you want to cascade down, it's implementation specific on the receiver
* Atul: Right, we aren't dictating behavior on the receiver
* Karl: The question of how to implement session revoked came up over and over, people don't want to uniformly revoke everything so how to scope what to revoke came up a lot
* Atul: It is posisble for the transmitter to selectively send a session revoked event to certain receivers
* Karl: I'm referring to do I revoke all refresh tokens in O365, what is the intended blast radius.
* Atul: There are 3 dimensions. Breadth of the event, how many receivers/applications are impacted, what are the downstream cascading events which is not addressed by SSF
* George: When we're talking about an async event like SSF, there's a dilemma between how prescriptive it is. That decision is deployment specific. It's an event, but if you want to make it mandatory in a deployment you can.
* George: When it comes to policy, we could be more prescriptive on the publisher side for the expectations for what the RP to do. In a more federated context that becomes more difficult, we have to be careful in that context of where we put the details of what is needed. One dimension can be handled with subject identifier like Atul said, but there are likely other cases with cascading effects that will be more nuanced.
* Karl: Because the event is in the context of the publisher you don't have the context for the refresh token identifier issued to the app. The refresh token at the IdP isn't meaningful.
* Dick: The IPSIE goal is to describe how to do session termination and what the scope of that is. IPSIE's goal isn't to describe how to configure everything, it's to be prescriptive.
* George: We need to be careful about forcing people to implement something just for the sake of the capability when they might already have infrastructure that can do it. We might need multiple ways that are IPSIE compliant to achieve the goal.
* Dick: Having thousands of ways to do it won't meet the goal, but we can have a few paths.
* Sarah: My understanding of shared signals is that it's all informative. Are we saying "I'd like this revoked" or "thou shalt".
* Dick: What Atul and George are proposing is they would expand the semantics of what you can do with shared signals.
* Sarah: It will need to be a two way signal, I need to get the confirmation back about what happened like there are this many tokens left with this lifetime, was the termination successful or not.
* Dick: What would the receiver do with this information?
* Sarah: They would know that if activity was seen from these tokens it's not a new compromise it's the same compromise
* Aaron: For me, it's not about session termination specifically, it's about getting the user to log back in through the IdP before they can continue to do anything in the app
* Bertrand: I agree with George where there are deployments where session termination works various ways. IPSIE is meant to be a plug and play, so we need to be somewhat prescriptive for what each role should implement in order to be plug and play.
* Karl: In IPSIE it's about going back through an enterprise policy point. Since the app is disconnected how do we make it synchronized back to the enterprise. That might be a different verb/noun than session.
* Travis: I have some questions. It needs to be something well adopted, we pay the most attention to what our customers are using, that is Entra and Okta, which carries a lot of weight for what we implement. Users can log in, do things, session revocation is straightforward. They might also go into a lot of apps they federate downstream to...
* ...
* Dick: You described all these different dimensions, but it sounds like we can all agree on at least one of the use cases is kill all the things. There's no ambiguitiy, the user has to start ovedr with the app.
* Karl: I was putting that on the right side of the spectrum. The more we go left on the options the more surface area and application specific concepts there are.
* Dick: Does anyone think we *shouldn't* do the use case where the user is forced to log in? Whatever the user has done to log in, start over and make them log in again. Revoking all access.
* Travis: We call that the kill switch service. We need to ensure whatever command is sent has some specificity, targeting things that are spawned from sessions.
* Dick: It sounds like you're agreeing, you have a kill switch. Kill all the things based on what the RP has done from logging in to the IdP. So a mobile app has an access token issued by the mobile app's backend. That should be terminated too until they SSO again.
* Travis: If a bad actor compromises a session and spins up a bunch of agents and then left, you want those agents terminated too.
* Sarah: How is this different from step-up?
* Aaron: It also applies to non-interactive tokens
* George: Our granularity of use cases is based on how much each role knows about the session graph. I don't have a problem starting with the "kill everything" mechanism. I suspect in reality enterprises probably want more fine grained control. We'll need some way to talk about the session graphs and what they mean in deployments.
* Dick: But you agree that one of the things we should deliver is the nuclear option.
* George: Sure.
* Karl: Security teams today already need to build the session graph, it's a problem statement in the enterprise. The first action is revoke access, then you need to figure out what happened what data was accessed. That happens today in incident response. So we don't have the protocols to automate that knowledge, so it's interesting long term direction. But there's so much clear value on the "kill all" and it can be mapped to a CAEP event or whatever. If there's enough feedback that there is customer value we can just go do that and get it off the list. It adds a lot of value to the enterprise. Answering the nuanced problem statement is worthy long term investment but likely more than what we can do in 12 months.
* Travis: I also think there is value in the more specific "kill my current session" as well as the "kill everything".