[Openid-specs-ipsie] 2025-02-04 IPSIE WG Meeting Minutes

[Aaron Parecki]

Hi all, below are the minutes from the meeting this week.

As discussed, we've continued to tweak the description of the levels based
on the feedback from the call. Please review them and comment on GitHub or
reply to this email if you have any thoughts in advance of the call next
week!

https://github.com/openid/ipsie/blob/main/ipsie-levels.md

---

# IPSIE WG Meeting Minutes
Date: 2025-02-04

## Attendees

* Dean H. Saxe (Beyond Identity)
* Kenn Chong (RSA)
* Aaron Parecki (Okta)
* Brock Allen (Duende Software)
* Jon Bartlett (Zscaler)
* Hannah Sutor (GitLab)
* Dick Hardt (Hellō)
* Mark Maguire
* Jen Schreiber (Workday)
* Mike Kiser (SailPoint)
* Arnav Choudhury (Independent)
* Tom Clancy (MITRE)
* Ameya Hanamsagar (Meta)
* Russell Allen (NetFoundry)
* Mark Dorey (Ping)
* Shannon Roddy (self)
* Matt Topepr (UberEther)
* Mark Maguire (Aujas Cybersecurity)
* Danny Zollner (Microsoft)

## Agenda

- Welcome and antitrust policy reminder
- Reminder about OpenID Slack
- Review updated IPSIE levels table https://github.com/openid/ipsie/pull/46


Notetaker: Mark Maguire

## Minutes

- Tables of IPSIE definitions redesigned, IPSIE levels now rows and columns
are now the applications / identity services. Identity services could be
anything at enterprise that manages identity (AD, SSO, IGA, PAM, etc)
- 3 sets of IPSIE levels: Session Lifecycle, Identity Lifecycle,
Entitlement Management
- 3 sets of levels are independent from each other (i.e. could be
entitlement level 2 but session level 3)
- IPSIE levels for each reviewed to make sure definitions make sense to
everyone
- Aaron feedback on IPSIE SL2: update "must" to "may" for applications
- Dick recommended we have it say "applications must be capable of sending"
instead of may
- Aaron clarified it has to do w/ regulatory requirements for going through
MFA for RP. Recommended we stick with "may" instead of "must"
- Dick made the point "if we go from must to may" what is the point of an
app being SL2?
- Kenn recommended we keep it "must" to keep it more secure
- George from chat: "Isn’t SL2 for the use case where the RP has a specific
level that they require, and they want to ensure that regardless of what
the Identity Services require, it still must honor it."
- George: how do we accomadate step up? For example, requirement where
phishing resistant token is needed
- Dean recommended we mention enabling step up explicitly in the verbage
explaining the levels
- Dean: For identity services SL2, change "accept policy" to "enforce
policy"
- Dick: what does "session termination" mean in our SL2?
- Aaron: concrete definition - when admin clicks button or shared signals
occurs or etc, identity service wants to log user out of everything. Today
can just fail their next sso, but cannot log them out everywhere. Session
termination means revoking all tokens for the user and logging them out
everywhere.
- Kenn: Basically universal logout
- Dick: "session termination" is basically undo everything the identity
service has done since the user logged in
- Kenn: do we want to include machine logout too?
- Mark:  capture as issue that admins often dont login as themselves - they
checkout pam password and login as that. Do we want to have the IDP send a
request to the PAM solution to change any passwords the user checked out?
- discussion about if I logout of app a should it log me out of app b too?
What if I use google to login to app a, and then logout of google? should
app a also logout? "global logout problem"
- Aaron made the point that this is a CIAM issue but not AM issue
- Dick: user initiating logout from Rp is out of scope - RP controls its
own session but not IDP session
- Aaron: ie if user logouts of workday and presses login, do they need to
auth again to idp?
- Aaron: interop question is, if there is a policy at both ends, how do we
make sure the RP gets what it wants (new auth)
- Kenn: if user logs out of RP, should there be a prompt to ask if they
want to logout of everything else too?
- We could have the RP send the user back to IDP to have them logout
everywhere if they want
- Dean recommended we table and take this up as an issue on GitHub
- SL3 - IDP and RP being able to communicate state changes to each other
- Dick: SL3 says you need to accpet "posture changes" but there are no
requirements to act on posture changes
- SL3 does not mean you have to do anything with the signal, just need to
be able to accept it
- Updated "posture" changes to be "state" changes instead, captured changes
for user and device
- Aaron: SL3 builds on SL2. SL2 requires sessions to be terminated, SL3
allows for updates to be sent back and forth
- Dean: we can add recommendations, but do not want to over define. We are
defining the interop requirements, but we should not require an IDP takes a
certain action based on details shared from the RP.
- Aaron will edit the other levels to match the discussion from today


Aaron Parecki

Director of Identity Standards

aaron.parecki at okta.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250206/230ec3e4/attachment.htm>