[Openid-specs-ipsie] 2024-11-26 Meeting Minutes

[Aaron Parecki]

Hi all, below are the minutes from the meeting on November 26. The main
takeaways were:

   - We agreed that the initial IPSIE work will focus on new deployments,
   creating a document that describes what we see as an "ideal" enterprise
   integration.
   - We will then use that document to inform what a migration path for
   existing deployments to get to that end state would look like.

The main action item out of the call is to expand on the "developer user
story" we discussed on the call. I started a structure for that in GitHub
so that we can send PRs to it.

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

I've started an agenda for the December 3 meeting here:

https://github.com/openid/ipsie/wiki/2024%E2%80%9012%E2%80%9003


---

# 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 at 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

- Welcome and antitrust policy reminder
- SAML gap analysis https://github.com/openid/ipsie/issues/4
- Collect initial set of use cases to address
- Establishing "special topics" areas and meeting schedules
https://github.com/openid/ipsie/issues/3

## 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.



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/20241202/d0b8a712/attachment-0001.htm>