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

[Dean Saxe]

 Aaron,

There was one more item from last week that we should follow up on: changes
to the charter to include SAML and/or a transition from SAML to
OIDC/IPSIE.  On the call tomorrow, let’s remind folks that they can issue
PRs against the charter as discussed on last week’s call.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
Principal Engineer
Office of the CTO
Beyond Identity
dean.saxe at beyondidentity.com




On Dec 2, 2024 at 1:03:40 PM, Aaron Parecki via Openid-specs-ipsie <
openid-specs-ipsie at lists.openid.net> wrote:

> 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
>
>
> --
> Openid-specs-ipsie mailing list
> Openid-specs-ipsie at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ipsie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20241203/45559408/attachment-0001.htm>