Skip to content

2025‐08‐05

Jump to bottom
Aaron Parecki edited this page Aug 5, 2025 · 1 revision

IPSIE WG Meeting Minutes

Date: 2025-08-05

Attendees

  • Aaron Parecki (Okta)
  • Sean Miller (RSA)
  • Dick Hardt (Hellō)
  • George Fletcher (Practical Identity LLC)
  • Dean H. Saxe (self)
  • Karl McGuinness (Self)
  • Jon Bartlett (Zscaler)
  • Mark Maguire (Aujas)
  • Bjorn Hjelm (Yubico)
  • Jeff Bounds (SailPoint)
  • Alex Chalmers (Self)
  • Kenn Chong (RSA)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • IETF Update
    • Dean: Aaron presented SCIM at IETF 122 in March. Dean presented at IETF 123 catching up on where we are, inviting members to review the proposed SCIM IL1 document.
    • Mark: was there any feedback from the meeting?
    • Dean: haven't seen feedback yet
  • Interop Planning - too few responses on the poll, 6 responses, 2 are the co-chairs. Strong preference for January dates. Aaron will pick a date in January since they got equal votes.
  • Call for adoption for common requirements has passed (all positive responses)
    • need to publish the draft on openid.net
    • Aaron and Dean to do the needed work to publish on their weekly planning call
    • Aaron has already pushed a draft to remove the common requirements from OIDC SL1
    • SCIM requirements should pull out anything that is in the common doc
    • IL1/SL1 need to include language to pull in the common requirements doc. See the OIDC SL1 draft for possible language
  • Enterprise Extensions update
    • No update at this time
  • FAL2 Issues

    • Issue #92 prompt parameter

      • Dean: Previously discussed prompt=login and max_age=0. Reviewed OpenID Sessions. Two issues: session management at the OP, and the ability of the RP to force logout. We haven't really talked about session management at SL1 other than "application specific lifetime must be set by the assertion".
      • Dean: question for the group: do we need to define session management at the OP at SL
      • Dick: Strange for the RP to be able to make session management requests at the OP without a global logout from the RP. Should not spec session lifecycle at the IdP in the absence of global logout. Dick's perspective is that we need to focus on session management at the RP, not the IdP.
      • Karl: Question to Dick: When we put session requirements in SL2, you would expect IdP and RP focused requirements?
      • Dick: At SL1 there's no discussion of global logout, don't need to worry about session lifecycle at the Identity service. Do we need session lifecycle at SL2? open question.
      • Karl: There's logout at the RP/IdP at SL1, but it's undefined in SL1 today. We're not definining any interop requirements here?
      • George: What does "logout" at the RP mean in a federated env? To George this means they are ending the RP session. RP is cleaning up its context of the user's session at the RP. (Thumbs up from Dick.) What does the RP mean when they send "prompt=login" Can we describe the behaviors we expect instead of using ambiguous terms?
      • Karl: Agree. Applications own their own sessions, they don't impact the IdP session. The sessions are independent.
      • Dean: Suggest we update the levels doc to describe the session independence?
      • Sean: Does this mean there is no unified logout?
      • Dean: Yes
      • George: In favor of adding a session management model to the levels doc. Session relationships are rouhgly the same in SAML/OIDC. Define a session model for IPSIE. We have discussed the RP's AS going back to the IdP to see if the session is still valid. IdP is a "primary" session, establishes a "secondary" session at the RP. We could establish connectivity between these sessions. We don't today force a logout at RPs when the IdP session is ended.
        • Once we describe the global model for IPSIE we can then document what parts are implemented at each SL* level.
      • Karl: Likes George's proposal. We'll have the same consideration at IL* as well. Need a state model for both.
      • TODO: Add an issue to write this model for the levels doc. (George will take this on).
      • Karl: We have the check session behavior, need to define it's use at SL*
      • Dick: Levels does not contain global logout language. SL3 has SSF, SL2 allows IdP to tell the app to logout before a session ends. Need to tease out more in the IPSIE levels about the login requirements/re-login.
      • George: We can develop the session model description in the levels doc to add clarity to the capabilities at each level.
      • Jeff/Jon/Sean both like the call out on session management and interactions at each level.

    • https://github.com/openid/ipsie/issues/100

      • Karl: Many deployments in the real world require IdP init with SAML to get the right UX. This is through an app portal. If SP Init is required at SL1, this will block these deployments from becoming IPSIE compliant. Propose that we meet the world in it's current state.
        • User intent is lacking in IdP init, can be included through an MFA prompt
        • Deep links are a possibility but lack interop
      • Aaron: "What's the actual threat we're trying to prevent?"
        • Can we determine what the threat is and address the threat when using IdP init?
      • Kenn: Encourage SL1 adoption by not being too prescriptive here. Like's Aaron's proposal to identify the threats and how we can mitigate them
      • Alex: Nothing we're proposing prevents non-ipsie compliant services. Is this a regression to allow IdP init for interoperability?Questions about how we describe platforms - are the platforms IPSIE compliant? Are the connections defined by their compliance?
      • Dean: Federations can be compliant, platforms can support compliant federations and non-compliant federations.
      • Karl: Supports the idea of federation level compliance. Biggest concern is supportability of an applicaiton in a real world deployment. If an app can be deployed IPSIE compliant, but the UX doesn't allow for IPSIE compliance, we have an issue. This could dilute the value of IPSIE. Need to discuss this relative to the federation threat model.
      • Dean: We should create an IPSIE threat model and use this to describe what threats are mitigated across different SL*/IL*.
      • Karl: Threat model is a good idea. Focus on deployability.
      • TODO create an issue to define a threat model. (Dean)
      • Dick: Agrees with Karl - need to enable enterprises to deploy solutions in the way they are used to. SAML should be able to operate at SL1.
      • Dean: TODO update the levels doc regarding FAL2 compliance to ensure it's clear that we don't take on all of the technical controls.
      • Aaron: Phrase this as "IPSIE Level SL1 gets you part of the way to FALx"
Clone this wiki locally