Skip to content

2024‐10‐22

Jump to bottom
Aaron Parecki edited this page Nov 13, 2024 · 1 revision

October 22, 2024

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Jahan Moreh (Workday)
  • Wesley Dunnington (Ping Identity)
  • Mark Dorey (Ping Identity)
  • Kenn Min Chong (RSA Security)
  • Sean Miller (RSA Security)
  • Filip Skokan (Okta)
  • Karl McGuinness
  • Paul Querna (ConductorOne)
  • Keiko Itakura (Okta)
  • Dros Adamson (Cisco)
  • William (Nick) Dawson (Roblox)
  • Adam Matthews (Okta)
  • Pamela Dingle (Microsoft)
  • Tom Clancy (MITRE)
  • Mike Jones
  • Nick Dawson (Roblox)
  • Keiko Itakura (Okta)
  • George Fletcher (Capital One)
  • Tim Cappalli (Okta)
  • Bjorn Hjelm (Yubico)

Agenda

  • Welcome and antitrust policy reminder
  • Roll call and introductions
  • Brief overview of external orgs and events
  • Overview of IPSIE charter
  • Recap of last meeting minutes
  • Continuing brainstorming on outcomes
  • AOB

Minutes

  • antitrust statement review by MikeL (OIDF)

  • Introductions

  • Recap of the charter (AaronP)

    • goal: driving interop and security across the enterprise use cases for SSO, provisioning, entitlements, signal sharing, etc.
    • the focus is on interop between the IdP and the apps in the enterprise
    • We do not expect to talk about specific behaviors of apps or enterprise IdPs, rather, we focus on the interconnect between the two
    • focus on the problems with the current set of specs in use

  • Last meeting (2 weeks ago) we brainstormed around the problems we wish to tackle (see the list below)

    • Aaron has started a doc that he hopes to share by the next meeting
    • Dean: IETF Dublin may be a conflict with this meeting.
    • Aaron: We have to postpone due to conflicts with IETF WGs
    • Aaron: We can use the gap between meetings to collect thoughts/ideas. Need more concrete thoughts on the proposals below.

  • PamD: New topic. Clarify one thing from a WG perspective. It's been reported that MS has agreed to implement the spec. Proposing the WG is not an agreement to implement. MS will work in good faith with the community. Please help with press/PR to clarify the intentions of being a proposer would help Pam/MS.

  • Aaron: 100% agree. Difficult to message this to press.

  • Tim: Editors/chairs are merged into a single role in OIDF. Can we discuss / propose formal roles to the OIDF board?

  • Aaron: Great point. Not sure of other OIDF groups with split roles.

  • Tim: Don't need to be as explicit as W3C, but worth divvying up the roles.

  • JosephH: Chair a group, not an editor of the specs. This has been done.

  • Tim: Often assumed that editors are chairs.

  • Aaron: ideally need more than one chair.

  • MikeL: Noted comments on chair/editor split. They're one and the same currently as defined in process. As Joseph mentioned this is not how it operates in practice. State who cochairs and editors are in the repo. Cochairs defined by consensus in the process doc.

  • Aaron: IIW is next week, following week is IETF. Next meeting is November 12, 2024

  • DickH: The week after IETF is WebSummit in Lisbon. 70k people.

Brainstorming Outcomes from last meeting (October 8, 2024)

The below are enhanced with thoughts from the current meeting.

  • Secure by default
    • Ensure hardware-backed phishing-resistant MFA is enforced into apps
      • TimC: Do not support putting any properties of authR in the profile. Support conveying the context. We cannot mandate this. Details of the specific authR is out of scope.
      • Karl: We weren't trying to be specific on the last call. How do you configure an app with the appropriate authenticators?
      • Tim: Read this as only hardware backed
      • Karl: Configured to the appropriate needs.
      • Tim: Configure to an appropriate context and convey that back to the RP
      • WesleyD: How do people envision the world working? Does the RP dictate the requirements to fulfill? Or do we expect to define a set for service providers to honor?
      • Tim: We enforce from the app to the IdP is a nightmare scenario. There is value in saying the app may do something locally (e.g. 2nd factor) if the authentication context is insufficient
      • GeorgeF: A definition of what good looks like is necessary up front. More than one definition of good.Enterprise should set the appropriate context. Enterprise to Enterprise is a different deployment model and may not have the same constraints. How do you work out that gap? Need to define the scenarios we want to solve and what good looks like in each scenario.
      • WesleyD: that's a good description. Inter-enterprise vs. Intra-enterprise?
      • TimC: Define boundaries. There are some things we don't have control over. We're focused on the latter half of what George stated. Not concerned about the intra-enterprise.
      • Aaron: goal is not to dictate HOW apps work, it's to enable interop. What do we need to enable to make everyone happy? e.g. communicate "this is a hardware backed MFA"?
      • SeanM: That's key - this is what good looks like, we need to communicate signals across and let the layers decide what "good enough" looks like. let's not mandate specifi properties.
      • Karl: Bring in the perspective of the SaaS developer working across multiple parties. Simplify it for them.
      • PaulQ: Differentiated user populations have differentiated needs.Higher assurance for admins vs. lower privileged users.
      • Dean: descriving properties of authentication is going to be needed. This work is just getting started
      • George: enteprise wants to ensure a specific assurance, so we need to inform a SaaS app about what the enterprise requires. Think about what we need from both sides - as the app, and as the enterprise. How does one SaaS app propagate the info to another SaaS app downstream?
      • TimC: Let's not go super deep. Are we assuming with this profile that the IdP is the FIDO RP? Where do we draw the line? How do we convey the result?
      • Dean: Agreed, enrollment info is not the highest priority in enterprise.
      • Karl: How do you know that all users are federated?
      • Tim: We need to specify this.
      • Karl: Not all users will be federated
      • Tim: Maybe the profile should mandate domain based restrictions on local accounts?
      • Karl: We need an answer to remove any back door access.
      • KennC: MS has an interesting way to use acr/amr to communicate minimum requirements to authN and which requirements were met during authN. IdP has to determine how to handle the gaps. Can we standardize use of amr/acr in OIDC.
      • WesD: We need a way to get attestation from these apps to get a consistent, zero trust security posture.
      • JahanM: Original charter called out OAuth and other standards that are not end user/human oriented. Are we tackling API authN or end user authN?
      • Aaron: Interesting API use cases in the context of an end user. Maybe move the consent step from the end user to the enterprise? This seems like phase 2 of this work.
      • Jahan: Can we explicitly call this out of scope for phase 1.
      • Aaron: Yes, probably worth calling out. Focus of initial scope is end user.
      • PaulQ: What about end user api keys?
      • Aaron: It's messy. APIs keys can be a shortcut around a proper delegated flow. SSO is the first step of this work, along with continuous access. How does the user gain access and continue to use the app is the framing.
      • Karl: How much legacy app scenarios are pulled into scope? How much do you adapt to how the world works today vs. establishing a boundary of how the world works isn't the best mechanism moving forward.
      • PaulQ: authorize an ssh key (DHS: I missed the details)
      • Karl: devs don't always know the best practices. We can define and evangelize.
      • Dean: For the next few weeks can we go offline and try to solidify the goals/non-goals here. Aaron will set up a github repo to discuss.
    • ensure every account has MFA enabled
    • define the interoperability of authenticator attributes
    • Secure configuration of IdP and RP
    • Enable automated credential rotation
    • Step-up authentication - including what that looks like for SAML
    • "how does a user who shows up at a SaaS app log in with their enterprise IdP by default instead of email reg / shadow IT by default"
  • Zero trust
    • Continuous authentication
  • Zero standing privilege - capability to know that privileges are managed, not unknown and unmanaged
  • Minimizing optionality for interoperability goals
  • Stretch goal - configuration of these integrations (like FastFed?)
Clone this wiki locally