Skip to content

2024‐10‐08

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

October 8, 2024

Attendees

  • Aaron Parecki (Okta)
  • Mike Leszcz (OIDF)
  • Dean H Saxe (Beyond Identity)
  • Karl McGuinness
  • Mike Kiser (Sailpoint)
  • Joseph Heenan (Authlete)

Notes

  • Mike L introduced the antitrust statement
  • Aaron introduced the charter and problem statement
  • Dean - should we put together specific enterprise use cases to solve and figure out how to plug the piece together?
  • Aaron - agreed, but worried about deep diving too far on use cases
  • Karl - what are the outcomes we are trying to define? “enterprise” isn’t detailed enough, but also worried about analysis paralysis
  • Aaron - focus on secure by default and interoperability
  • Dean - been seeing a lot of WS-Fed even with SaaS
  • Karl - I’d advocate to not go down that route because MS IdP does support OIDC
  • Karl - enterprise outcome is strong multifactor authentication to all my applications. so if the application is using SAML, how do I ensure that and how do I do step-up in SAML.
  • Dean - how do we get to parity between SAML and OIDC so we can communicate the same message about the authentication strength - those are clear good outcomes for enterprises
  • Dean - Properties of the authenticators - whether credential can be shared or not shared, phishing resistant
  • Karl - is this different from the attributes defined in NIST?
  • Dean - NIST hasn't defined a way to communicate the specific properties looking for and what was used. Will present about this at Authenticate next week with Pam.
  • Step-up outcomes that Pam has been working on with SAML, maybe can continue that work here
  • Karl - how to consistently layer OIDC configurations on top of SAML integrations - to avoid needing to require upgrading SAML to OIDC for SSO
  • Aaron - also handling differences with user identifiers between SAML and OIDC
  • Dean - we should take a pointed stance on what user identifiers should be to minimize bad outcomes, e.g. avoiding email address as identifiers
  • Karl - it's an account linking problem, when a SaaS app goes from self service signup to linked to the enterprise IdP. apps have to implement logic to solve this, so usually fall back to email
  • Mike K - how to interweave shared signals and SCIM events
  • Karl - the broader goal is keeping things up to date, the menu of options available is too large at the moment
  • Dean - timeliness is a challenge
  • Dean - how does FedCM play into this?
  • Karl - "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"
  • Aaron - how do we get more SaaS vendors in the conversations?
  • Aaron - next meeting is during Authenticate and Oktane, so next meeting will be Oct 22

Brainstorming Outcomes

  • Secure by default
    • Ensure hardware-backed phishing-resistant MFA is enforced into apps
    • 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