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

[George Fletcher]

Do we already have documented the "enterprise user" story? It seems to me
that the biggest value of IPSIE is to enterprises that are wanting to
integrate different components of their identity system. Are we collecting
use cases/user stories from enterprises on the pain points they've felt and
using that to inform our work in IPSIE?

Thanks,
George

On Mon, Dec 2, 2024 at 6: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
> <https://urldefense.com/v3/__https://github.com/openid/ipsie/blob/main/ipsie-v1-draft.md__;!!FrPt2g6CO4Wadw!KHFJIn25yfkMq0PDWgEOQQuCjiQTDZsBSndr6Pw_8xPintbH5-kv420KiuSqF7W1dx539WGdlQvpysyZFzdsprSMUMdv1QxYmUAiM8wl$>
>
> I've started an agenda for the December 3 meeting here:
>
> https://github.com/openid/ipsie/wiki/2024%E2%80%9012%E2%80%9003
> <https://urldefense.com/v3/__https://github.com/openid/ipsie/wiki/2024**B12**B03__;4oCQ4oCQ!!FrPt2g6CO4Wadw!KHFJIn25yfkMq0PDWgEOQQuCjiQTDZsBSndr6Pw_8xPintbH5-kv420KiuSqF7W1dx539WGdlQvpysyZFzdsprSMUMdv1QxYmcz4KtzT$>
>
>
> ---
>
> # 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
> <https://urldefense.com/v3/__https://github.com/openid/ipsie/issues/4__;!!FrPt2g6CO4Wadw!KHFJIn25yfkMq0PDWgEOQQuCjiQTDZsBSndr6Pw_8xPintbH5-kv420KiuSqF7W1dx539WGdlQvpysyZFzdsprSMUMdv1QxYmQPoqvL7$>
> - Collect initial set of use cases to address
> - Establishing "special topics" areas and meeting schedules
> https://github.com/openid/ipsie/issues/3
> <https://urldefense.com/v3/__https://github.com/openid/ipsie/issues/3__;!!FrPt2g6CO4Wadw!KHFJIn25yfkMq0PDWgEOQQuCjiQTDZsBSndr6Pw_8xPintbH5-kv420KiuSqF7W1dx539WGdlQvpysyZFzdsprSMUMdv1QxYmWSbkMor$>
>
> ## 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
> <https://urldefense.com/v3/__https://github.com/openid/ipsie/issues/6__;!!FrPt2g6CO4Wadw!KHFJIn25yfkMq0PDWgEOQQuCjiQTDZsBSndr6Pw_8xPintbH5-kv420KiuSqF7W1dx539WGdlQvpysyZFzdsprSMUMdv1QxYmQcyve12$>
>   - 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://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ipsie__;!!FrPt2g6CO4Wadw!KHFJIn25yfkMq0PDWgEOQQuCjiQTDZsBSndr6Pw_8xPintbH5-kv420KiuSqF7W1dx539WGdlQvpysyZFzdsprSMUMdv1QxYmc9Jw12E$
>

______________________________________________________________________



The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20241203/cda36b81/attachment-0001.htm>