2025‐03‐04 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-03-04

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Dick Hardt (Hellō)
  • Mark Maguire (Aujas Cybersecurity)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • Jen Schreiber (Workday)
  • George Fletcher (Independent)
  • Russell Allen (Self)
  • Alex B Chalmers (Independent)
  • Jon Bartlett (Zscaler)
  • Wes Dunnington (Ping Identity)
  • Nagesh Gummadivalli (Workday)
  • Mark Dorey (Ping Identity)
  • Travis Tripp (HPE)
  • Robin Martherus (Cisco)
  • Victor Lu (Independent)

Agenda

  • Welcome and antitrust policy reminder
  • OpenID Contributor Agreement reminder https://openid.net/intellectual-property
  • Reminder about OpenID Slack
  • Update on upcoming call schedule
  • Recap initial draft of IPSIE levels

Notetaker: Dean H. Saxe

Minutes

  • Antitrust policy reminder
  • Call schedule updates - no call for March 18 due to IETF
    • IIW week schedule TBD, likely to cancel or move to a new day to minimize conflict
  • Aaron: Update on last week
    • OAuth Sec Workshop in Reykjavik
    • Aaron & Dean did an unconference session on IPSIE current state and upcoming goals
    • good feedback from the audience
    • Updated table to NIST SP800-63 rev4 draft based on feedback at OSW. We had been discussing in the context of rev4 already, so this was a minor nit.
    • Updated the session lifetime SL1 for clarity
    • Minor nits / copy edits in the most recent update to the levels table and text
    • Ready to start authoring guidance
  • George: Added an issue around SL3, we can discuss offline.
    • George: SSF can be commands, can be informational
    • Dean: SSF is designed as informational, never commands. Is this correct?
    • George: There are informational signals, some of them are commands in context.
    • JenS: SSF expresses what the transmitter has done, not what the receiver should do. "I have logged out the user" is a statement, not a command. Should receivers do the same action as a result of receiving the event?
    • George: Async delivery - can send any event.
    • Jen: Expresses the action taken at the transmitter. But SCIM events is more action oriented.
    • George: If the enterprise sends a terminate session, the app must terminate it. (George refers to SL3, but this is defined at SL2)
    • Aaron: Defining levels without protocols to avoid this issue. We haven't defined protocols yet. SL2 defines the explicit termination, SL3 communicates state changes, not intended to be explictly acted upon.
    • George: Step up @ SL2, should add downgrade the session state at SL2
    • Pam: Not a single sign out protocol, this is a negotation. Commanding the app take the data into consideration. Pam thinks session termination at SL2 is a bad idea.
    • Aaron: not discussing SSF
    • Pam: negotiating termination of sessions, not taking orders.
    • Aaron / Dick / Dean: All disagree.
    • Dick: identity service wants to kill all the things
    • Pam: We want the outcome to be session termination, not that every command results in a termination. We need loose coupling.
    • George: Enterprise is getting risk signals, e.g. about device state. device is now jailbroken. IdP wants to tell all RPs that the user is logged into that they need to terminate a session and guarantee the outcome. There's a contractual obligation.
    • Dean: there's a difference between commands (SL2) and state updates (SL3)
    • Pam: Withdraws the concern
    • MikeJ: OpenID Back channel logout uses a sec event as an imperative command, not a signal. IPSIE should use the existing logout mechanisms and not define a new one.
    • Aaron: chair hat off. Trying to approach this as putting pieces in place for the overall workign of the system. Defines the outcomes, not the mechanism. WHen the Identity Service needs to explicitly terminate a session, the app needs to respond accordingly.
    • Aaron: can't use backchannel logout exclusively b/c of refresh token
    • Sean: Level is communicating expectations. Signal is just a message, receiver can do what it wants. IPSIE level helps set the expectation of receiving messages. Is this correct?
    • Dean: We've defined outcomes, not the mechanisms yet.
    • Aaron: need to define how things work... last week we said we'd begin on SL1/IL1. These shared signals concerns don't exist there, it's plain SSO. Work on SL1/IL1 in parallel. How do we approach this? Aaron is happy to map OIDC to SL1. Can work on a draft for next week to review.
    • Aaron: We can set up smaller group working sessions to work on these.
    • Sean: goal is the interop. Can we work toward that
    • Aaron: Yes, working toward SL1/IL1 or maybe just SL1 for the interop. Need a date for an implementers draft. Working backwards.
    • Dean: Need to understand process
    • MikeJ: To do an impl draft
      • Working backwards from approval date
      • 1 week of voting
      • 45 days foundation review
      • 2 weeks of WG last call
      • total ~10 weeks from editor WGLC to a published draft.
    • Dean: How much time is needed to implement?
    • Aaron: Prod not needed. Demo that something works - could be on a single dev laptop or beta. Just need the ability to test.
    • Mike: How much time to implement the implementers draft? Don't gate implementations on the draft. Encourage people to build early and provide feedback. Create a positive feedback loop to close out on the implementers draft.
    • MarkM: If apps support SCIM, you're probably already IL1 compliant.
    • Aaron: jumping into protocols. Next stage is defining how to use SCIM to accomplish IL1 (for example). Elimination of options, removing insecure parts.
    • MikeJ: Interop target can be a draft and not a published implementers draft. Published draft for interop building and review period can go side by side.
    • Aaron: Is there enough motivation do to both IL1/SL1 for interop?
    • Dean: Is anyone concerned about trying to get to both IL1/SL1 for the interop?
    • Russell: Until we have protocols, it might be to early to say
    • Pam: For vendors supporting SCIM and SSO, it should be pretty straightforward. What's the value prop
    • Aaron: is this too easy to achieve? Security aspects could influence outcomes, not zero work for implementers.
    • Pam: MS might not disable specific items globally
    • Aaron: That might be client specific.
    • Pam: Configuration to demo the properties is different than stoppinfg offering a feature
    • Aaron: In okta, configuring client with OIDC, checkboxes for different options. What we need to demo is a way to configure at SL1. Enables customers to only turn on the specific SL1 features if they want
    • Dean: Can there be the easy button to turn on a compliant implementation? that's the goal.
    • Travis: Do we need to be able to turn off non-compliant implementations?
    • Aaron: Think of it from the enterprise buyer perspective, they want to be able to buy a set of security guarantees if configured in a specific way. FAL2, for example, is the catch all for a number of these config concerns.
    • George: Get a specific security profile and guarantees that identity services and apps work together seamlessly.
    • MarkM: If you have a button to check to say allow/disallow. Assume all new SaaS apps that allow SL1/IL1, but old apps do not. That could be a worse option. Secure by default has the levels on, and allows the ability to disable secure options as needed.
    • Aaron: Implications on product design. Make sure product has the features to meet ILx and SLx. Second, integrations aren't accidentally insecure.
    • MarkM: Looks different from the IdP and app perspective
    • Aaron: Need to get to the details of protocols to figure this out.
    • Dean: We can be opinionated that products should be secure by default, but we cannot be prescriptive.
    • Aaron: When we specify an implementation, it means the implementation cannot do the opposite
    • Pam: Specifying positive and negative tests makes it easier to implement. Taking things away is different from ensuring they're not configured.
    • Aaron: We can make the option not possible for a specific entity (e.g. integration with an app) while not removing the option from ALL integrations.
    • Pam: Everyone should be able to select their desired implementation. Is it governance that tells you you're not IPSIE compliant?
    • George: Flagging as IPSIE compliant is very prescriptive, but not all RPs need to be IPSIE compliant (e.g. legacy apps). If an enterprise wants 100% compliance, the enterprise bears the cost of ensuring everything meets that bar. This is not about stopping people from doing non-compliant integrations
    • Dean: The integrations are IPSIE compliant, but the products may allow you to be non-compliant.
    • Aaron: Will try to write an OIDC SL1 spec
    • Pam: Will start on the SAML SL1 spec.
    • Dean: When I see PR's I will publish an agenda for next week.