Skip to content

2024‐11‐26

Jump to bottom
Aaron Parecki edited this page Dec 2, 2024 · 3 revisions

IPSIE WG Meeting Minutes

Date: 2024-11-26

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Wesley Dunnington (Ping Identity)
  • Filip Skokan (Okta)
  • Dick Hardt (Hellō)
  • Karl McGuinness (self)
  • Daniel Nagy (Twitch - djnagy@twitch.tv)
  • Jon Bartlett (Zscaler)
  • Kenn Chong (RSA)
  • Mike Jones
  • Tom Clancy (MITRE)
  • Pak Foley (Riot Games)
  • Shawn McGuire (Riot Games)
  • Nagesh Gummadivalli (Workday)
  • Apoorva Deshpande (Okta)
  • Brian Soby (AppOmni)
  • Mark Dorey (Ping Identity)
  • Victor Lu (Independent)
  • Tim Cappalli (Okta)
  • Pamela Dingle (Microsoft)
  • Vincent Denny (Okta)
  • George Fletcher (Capital One)
  • Mike Kiser (SailPoint)
  • Shannon Roddy (self)

Agenda

Minutes

  • Antitrust reminder
  • Minutes by Dean H. Saxe
  • SAML discussion on Slack and Developer focused review added to the agenda
    • Tim: goal with the dev focused user story was to focus us https://github.com/openid/ipsie/issues/6
    • Aaron: Focus to start the work is good. This scopes to new integrations. This makes the initial problem space easier by leaving out existing implementations.
    • Dean: Narrowing focus is good, let's not forget about existing implementations
    • Aaron: existing can treat themselves as "new", if they want to be IPSIE compliant
    • Tim: older implementations can then figure out how to snap to the ideal state. This allows us to work backwards.
    • Karl: No issues with focus on greenfield. New a smaller story with focus on value to the ISV first.
    • Aaron: This is reasonable.
    • Tim: if you have the resources to implement all of these use cases, great. We need a required and optional line in the requirements. This should come later in the process. Find the cut line and define it.
    • Nagesh: changes to the user state need to be reconciled upstream/downstream as a new story.
    • Dean: I like the idea of starting down this path, then defining a line of required vs optional, to Karl's point of making implementations not have to do 100 things, but that can come later
    • Dick: The first line will freak out new app devs - this is premature
    • Aaron: Maybe we separate out the group provisioning
    • Karl: agrees
    • Tim: this is not a 1:1 mapping of everything needed. THink about this in terms of where the future cut line is
    • Dick: Looks like the first thing I have to do is user provisioning
    • Aaron: We have general agreement (or it appears we do) about v1 being for new applications (lots of thumbs up in the Zoom)
    • WG Decision: v1 is for new applications
    • Dick: What do the SAML folks think about this?
    • Wes: This does not specify SAML/OIDC
    • Tim: That's by design - we haven't picked protocols.
    • Aaron: SAML support discussions indicate a lot of concern about existing deployments/use cases and ensuring they continue to work
    • Dick: OIDF WG - if the core login protocol is SAML, why is the work happening here? We're biased toward OIDC. Do we need a task force around OIDC and one around legacy (SAML)?
    • Karl: SAML doesn't complete the set of capabilities needed. Modernizing an implementation for an IPSIE profile has to come together in some scenario where the dev can migrate off SAML.
    • Tim: Reason for v1 focusing on new deployments is that his experience is hearing "we cannot change our SAML deployments".
    • Dick: 2 audiences - new things vs. existing things based on SAML. Can they add new security features and still use SAML?
    • Tim: let's decide later what it means to be IPSIE compliant (e.g. protocols that are supported)
    • Karl: Is deprecating SAML the goal? It's going to be there forever, should we drive people away from SAML?
    • Tim: We have brand new SAML implementations
    • BrianS: enterprise contracts mandate SAML due to customer demand
    • MikeJ: To Dick's question about SAML - the home of SAML (OASIS SSTC) is closed. They are not doing more SAML work. Other bodies could pick up this work. Mike is not advocating for this. Many implememtations are in stasis. New deployments are the long tail.
    • Pam: Strong objection to the idea that we cannot focus on non-OIDF standards. We focus on best practices in the industry. We can be opinionated, but not biased. This proposed user story makes a ton of sense, we need a second story focused on admins. A migration story is needed for when SAML cannot/should not be used any longer. This allows admins to be prepared for the transition. Pam will write the user story.
    • Tim: Replace dev with admin and this is the same story. We are picking winners.
    • Pam: Diff between admin and dev - admin chooses a winner, we give them paths to make an easy choice. Giving two paths with a pathway to migrate (e.g. from SAML to OIDC) opens the most doors.
    • Tim: Admins shouldn't have to worry about protocols. They want to integrate in the best way possible and be IPSIE compliant
    • Aaron: People can ignore our guidance and still build SAML. What are we writing down that
    • Dean: Agree with needing to focus on greenfield while giving a pathway to allow legacy and new SAML apps to migrate to OIDC in the future with ease
    • Dick: Wants this to become what people say they need and raises the bar. Is concerned about the existing running infra.
    • Aaron: proposal is to start with the discussion of net new, we won't stop there.
    • Dick: What's the problem with having two side by side groups working on OIDC and SAML side by side.
    • Aaron: Not enough time to take that approach, need a first document to have a useful discussion.
    • Dick: start with a clean sheet, then use that to look at existing deployments. Concerned with language that IPSIE is a clean sheet implementation.
    • Aaron: we need to be careful that greenfield is not the only focus of IPSIE
    • TomC: from the new perspective of IPSIE we have to consider the existing installed base. SAML profiles have not been maintained over time. Tom added examples to issue 6. Wants to understand the comparable SAML profiles for IPSIE. SAML profiles are under supported now - how will IPSIE have different outcomes?
    • Tim: Transition use case, agree 100%. We don't need to write everything as standards, we can write deployment guides, etc. Need a north star to transition to.
    • Pam: Agreed. WG should consider the membership of the WG and need to bring in the SAML-focused people to make sure they understand how we include them/their perspective (e.g. InCommon). Make sure we keep them involved from the outset.
    • Dean: I've been talking with Shannon R and Matt T, I agree we should reach out and clarify our intentions, that is we're not trying to erase SAML. Happy to reach out to them to make sure we can deliver that message and invite their participation, even if SAML is not our first priority.
    • Karl: Need to do better in the charter to handle hybrid/migration scenarios.
    • Dean: How do we update the charter to include this.
    • MikeJ: Updating charter: WG consensus on new charter, send to specs council for approval.
    • ACTION ITEM update the charter to include SAML / Transition from SAML to OIDC/IPSIE. Engage with SAML community on this effort.
    • ACTION ITEM Continue discussion on Issue 6 Developer User story
    • Aaron: Someone needs to propose text for the charter update so we can get agreement.
    • Aaron: On issue 6 (proposed dev story)
      • feel free to take a chunk of the bullet points and define specifics for new builds: protocols, security, interop
      • example: know whether the authN level was met via some kind of claim
      • Let's dive in.
      • Dean: these are the two near term work streams.
      • Aaron: short week in the US, not enough time to expect progress. Check in on progress next week to bring in text
    • Dean will take the action to sync with SAML community.
    • Aaron: propose we start a file in repo to collect text for Issue 6
    • Aaron: how do we achieve the levels of security/outcomes defined in IPSIE in deployments that do use SAML? We need to define the security/outcomes first.
    • Dick: Are we saying SAML should migrate to OIDC?
    • Aaron: Some simple deployments are on SAML because that was the default, these might move. But there are complex implementations that may not migrate.
    • Dick: If it's working, why break it?
    • Aaron: We need to write down the list of goals we want to achieve, once we have it, it will become apparent that some existing deployments of SAML don't meet those goals. We can then define either migration off SAML or updating the SAML deployments.
    • Dick: Why do we want an upgrade path for SAML?
    • KennC: let's not focus on protocol migration. Let's focus on secure enterprise deployment. Define how we migrate you to IPSIE compliance for a more secure option.
    • Aaron agrees - security outcomes are the goal
    • Karl: agrees with Kenn/Aaron. What are the things that a modern deployment needs to meet the security bar. Defining properties/best practices.
    • Aaron: Wrapping up. Agreement on general path and action items (see above).
    • Aaron will add the charter to the repo for individuals to issue PRs for updating the text.
Clone this wiki locally