# IPSIE WG Meeting Minutes
Date: 2026-04-14

## Attendees

* Aaron Parecki
* Dick Hardt (Hellō)
* Andy Barlow
* George Fletcher
* Takuma Yoshimura
* Bjorn Hjelm
* Mark Maguire

## 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-3pivn9jz4-x5ru_Fux~yjLh4LY9rNj2A
- Upcoming Events
- https://github.com/fedidcg/meetings/wiki/2026-List-of-Identity-and-Related-Conferences-and-Standards-Development-Events
- OpenID Foundation Workshop prior to IIW
- IIW - April 28-30
- EIC - May 19-22
- OAuth Security Workshop - May 27-29
- Identiverse - June 15-18
- IETF Vienna - July 18-24
- SCIM
- Session Termination - SL2
- AOB

## Notes

Notetaker: Aaron Parecki

### SCIM

No SCIM editors on the call today

### Session Termination

* Dick: How does the IdP signal to the RP that it wants to reestablish a session. On the previous call, we came to the conclusion that the OpenID Connect log the user out has the wrong semantics
* Dick: Karl proposed could we use those from the identity service to the app to say reestablish session. The semantics of identity service to app is kill the session, but not do anything after that. That led us to say the command to reestablish session needs to have some other mechanism, which we need anyway for "kill all the things".
* Karl: On logout, there's a question for IPSIE, there is a use case for logout which is to switch teh account at the IDP, which is different than revalidate. That use case still exists but we haven't talked about it in IPSIE yet.
* Dick: Should we file an issue to capture that?
* Karl: Yes
* George: We expect if the IDP wants to kill everything everwhere they would iterate through all the apps and send the message individually
* Dick: Is everyone aligned with not using existing logout like we talked about last time
* Karl: We're not using logout for SL2 to force the RP to revalidate the session
* Karl: The question I had was are we still confident that SL2 is both of these commands? Currently SL1 is an expiry in the assertion that the RP should revalidate. SL2 adds both commands as mandatory conformance.
* Dick: To reiterate, the "kill all the things" has more value.
* Karl: I would never want the RP to only implement revalidate. Revalidate is an optimization
* Dick: Wearing my developer hat, if I have code to kill all the things, then killing some of the things isn't hard to do. Killing all the things is harder.
* Karl: It seems like where the world is it seems to make sense to not create new things for SL1. Since we need a new protocol implementation for this, it should be in SL2.
* Aaron: I agree
* George: :+1:
* Karl: Next thing in the doc. There are JWTs that have expiration dates but might not have backing states in the RP to revoke immediately. The question for "kill all" or revalidate is should IPSIE have max timeframes for these to cap the max lifetime of un-expired tokens.
* George: At SL2, waiting for an hour for everything to be killed feels like we haven't met the security properties we're looking for. So either the value should be much shorter and people use refresh tokens to avoid UX interruptions, or they need some state mechanism.
* Karl: The first question is should IPSIE define lifetimes, then we can argue what the lifetime is.
* George: Or should SL2 define requirements for blocking tokens. If not, then SL2 doesn't really get me anything if I send "kill all the thigns" and tokens are still valid for some relatively long amount of time.
* Karl: So pick the interval that is reasonable
* George: If the IDP has sent kill all because they detect malicious behavior you want everything killed now.
* Aaron: So what's the definition of now?
* George: If we say it's 1 minute, that means too many tokens are issued
* Karl: You would write the requirement to have tokens revoked in some amount of time
* Aaron: So I'm hearing a firm desire to have tokens killed in some short amount of time like under 5 minutes.
* Dick: But the current logout command doesn't say to invalidate refresh tokens
* George: If we can't have some short amount of time in SL2 then we would need to in SL3
* Karl: So you're saying you want to define a window in SL2, but it doesn't need to be as aggressive a window as SL3
* George: I'll acquiesce to establish a window in SL2. My hope was SL2 would be strong enough that the large high-risk enterprises could leverage it and it would be sufficient. I don't believe an hour is sufficient.
* Aaron: It sounds like there are a couple things to separate out. There is a clear desire to define a window in SL2.
* Dick: There's also a difference between the half life and the max expiration time
* Mark: We had a scenario where the provisioning got backed up for an hour because too many events were sent. So far we've been focused on the RP receiving the query it needs to disable. But with a lot of transactions at once it's only moderately useful if the IDP isn't churning through it at a good rate.
* Karl: If the IDP has a queue of commands to issue to all the RPs, and that queue takes X amount of time to process, how do you establish the time to process the command at the IDP level. SL2 doesn't talk about when the IDP triggers the command, it just gives the IDP the ability to.
* Mark: From an enterprise perspective, if an RP responds fast but there's a backlog at the IDP then it's only minimally useful.
* Mark: Back to the original question, I think it's a good idea to define a window even if it's a wide window for SL2.
* Dick: So we have consensus on defining a window for SL2. So the next question is what's a reasonable window. A common practice in the industry is an hour for access tokens, but lots has changed and now we might need faster.
* Aaron: If we have the ability to reissue tokens without major UX disruption I think we can go down a lot lower. For clarity we're talking about the RP tokens, not RP-to-IDP
* Karl: The guidance will be dependent on whether the tokens are client-bound or not. One of the main threats with longer timelines is it's possible to buy tokens on the dark web and replay them, the value of replaying them is diminished when they are proof of possession. The second comment is from conversations I've had is shrinking the window is a significant cost for operating the infrastructure. One way is to dynamically adjust lifetimes to offload the refresh logic to be performant within a risk calculation. The factors are user experience, security, and scalability of the infrastructure. It's difficult for IPSIE to be too aggressive. I'm ok with pushing that level of conformance to SL3. I'm concerned about pushing too many access token requirements in SL2 when you have to accept some TTL window. I would argue that more ROI driven investment is DPoP.
* Aaron: One option would be to define different windows for POP tokens vs non-POP.
* Aaron: We haven't actually defined an attacker model for IPSIE yet.
* Karl: We probably need to do that.
* Dick: George do you think having different timeframes for SL2 and SL3 would work for people?
* George: The point Karl brought up with device bound tokens is super relevant. I don't feel like an hour for a non-device bound token is valid for SL2. But an hour for device-bound seems more reasonable. That's a critical factor in addressing the threat. The main threat is reuse of a token that should not be used. If it's bound to the device, the device should have killed it, the likelyhood that it appears from somewhere else correctly signed is relatively low.
* Karl: When Okta had to solve this problem when it was breached, this all had to come together. They wanted to put IP range restrictions, machine bound, MDM, layering all of this to get to the kill all the things outcome. The only way you'll solve it is to layer everything, and it was a pain to get this to work across vendors.
* Dick: So there could be a longer time window if the tokens are device bound.
* Karl: I support that.

Summary:

* There will be a max lifetime for revoking tokens in SL2
* There will be a shorter lifetime in SL3
* There will be a shorter lifetime for non-device-bound than device-bound
* These are outcomes, worst case, not literal token lifetimes. Implementation is up to the RP and can be revoked sooner if you have stateful tokens.