Skip to content

2025‐02‐04

Jump to bottom
Aaron Parecki edited this page Feb 4, 2025 · 2 revisions

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

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
Clone this wiki locally