Skip to content

2024‐11‐19

Jump to bottom
Tim Cappalli edited this page Nov 20, 2024 · 2 revisions

Date: 2024-11-19

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Sean Miller (RSA)
  • Karl McGuinness (Self)
  • Erik Gomez (JGSW)
  • Mike Kiser (SailPoint)
  • Kenn Chong (RSA)
  • Mark Maguire (Aujas Cybersecurity)
  • Dick Hardt (Hellō)
  • Mike Jones (Self-Issued Consulting)
  • Travis Tripp (HPE)
  • Wes Dunnington (Ping Identity)
  • Jon Bartlett (Zscaler)
  • Tim Cappalli (Okta)

Agenda

Minutes

Notetaker: Dean

  • OIDF Antitrust statement
  • Github thread for outcomes - https://github.com/openid/ipsie/issues/2
    • A handful of items added before the meeting today
    • will inform the special topics breakouts
    • Karl
      • aggregates high level goals
      • secure by default for a suite of capabilities
      • brings new apps into the enterprise in a secure config - authN, session management, zero trust, etc.
      • self-service apps need to be considered (e.g. signin with Google)
      • incremental adoption
        • how do we make apps enterprise ready without replacing the legacy technologies (e.g. SAML)
      • Interop - how do we reduce the overhead to enable a single implementation works everywhere with a secure by default stance
      • Remediation - MFA/identity proofing/etc return back to the enterprise
      • multi-tenant SaaS/IdPs
      • Control plane for lifecycle management
      • interop practices for zero standing privilege
    • Aaron - how do we break this into tiers based on existing vs. new specs
      • How do we develop specs to reduce the non-standard items?
      • Karl: What do we have vs. what's missing needs to be explored. Codify existing patterns when they are good.
    • Travis: struggle with table stakes level of alignment on how downstream apps operate and for customers
      • Need progressive certification capabilities
      • this will reduce the need to negotiate capabilities in a business context
      • SSO profile
        • there's a lot of legacy SAML, we need a way to categorize these apps
      • Single logout/session revocation
      • user lifecycle management
        • SCIM issues doesn't handle async processes well, doesn't scale well
        • JIT vs sync for SCIM?
        • Dean: Join SCIM WG @ IETF https://datatracker.ietf.org/group/scim/documents/
        • Dick: How does all this work together? This is not a SCIM issue, but an IPSIE issue.
        • Dick: Might be useful for us to think at a higher level, current items seem tactical.
        • Aaron: How SCIM and OIDC work together is in scope as a best practice
        • Mike: Dick stole my thunder. SSO + SCIM is in scope. Async may/may not be in scope at SCIM IETF. Shared Signals in SCIM is also in play here.
      • extended capabilities - MFA on demand, how do we standardize around this.
      • Risk signals/consumption - his company doesn't want to have to do the calculations, how can they obtain contextual information from upstream/downstream systems
      • Entitlements are challenging due to different authZ systems
      • API access
    • Aaron: JIT provisioning through OIDC is also a mechanism for provisioning beyond SCIM
    • Aaron: added tactical items
      • IdP init login user experience (e.g. launching from tiles @ IdP)
      • Integration between SaaS/IdP so that the security of the flow does NOT assume a correct RP implementation
        • IdP enforces security options
        • Example: PKCE to protect against auth code injection attack
          • Nonce check assumes the RP actually does the nonce checking, IdP does not know if this is implemented correctly
        • likely more examples
    • JonB: user behind a cloud proxy/secure service edge, their location may not change as their IP is changing, limits IdP awareness
      • can't do IP reputation, for example
      • Dean: sounds like a shared signals claim...
      • Jon: thought about it... but may not work in every case
      • Karl: SSE is a deployment model, so how do we reduce the choose your own adventure we have today
    • Lee: want to avoid IPSIE being a relay for every app up and downstream
      • how do signals get propagated everywhere they need to be?
      • Sean: agrees with Lee
        • can add new signals, but we shouldnt allow the augmentation of existing signals
      • Lee: IdPs aggregate/normalize already, what's reasonable?
      • Dean: to recap, there are lots of signals from different places, but targeted to different endpoints, how to you collect them to make good decisions and how to distribute back out?
      • Lee: maybe hub and spoke? Maybe not? Single source of truth? How do we figure out what the pattern is.
      • Karl: put some constraints on how we view this
        • similar to multiple IdP support
        • many to many is difficult, how do we simplify?
        • opportunity to have a point of view, we may not solve all challenges
      • Russell: ties this back to last weeks discussion of levels
        • how do we tell our customers what level of IPSIE we achieve if we have an IdP as a middle man in our transactions
        • Aaron: If you use something changing your interface to the world, that's what you're compliant with.
        • Karl: if you're built on a platform and you implement more capabilities in your app, you'd have to push requirements into the platform
      • Travis: Likes Lee's point of not having to be the central relay
        • can set up pub/sub of signals
        • Dean:is this a "directory" to configure the signals for a set of services?
        • Travis: possibly
    • Aaron: breakout sessions - let's strategize
    • Dean: Took an action item to set up task forces. What are the things we need to work on, and how do we ensure we are coordinating the work to avoid non-interoperable outcomes.
    • Dean: Today I've heard SSO, application authorization, user sync, signal sharing all come out in the conversation today. Haven't had a chance to integrate Karl's note into the list yet. So does this list make sense, if not what changes?
    • Kenn: We should come up with one specific use case that these task forces will tackle. For example SSO through the IdP, what does this mean for the different topics. Let's agree on one particular use case first. Proposed starting scenario: As a new user, I want to be onboarded to the IdP for the first time, securely enroll for my first credentials, and use that to sign-on to my first app.
    • Dean: One of the challenges is that use case crosses multiple buckets, maybe ok. I do like the idea of use cases under each buckets, so we can also identify cross-cutting issues.
    • Dick: Maybe elaborate more on what SSO or application authorization would do
    • Dean: For example SSO, we need to address issues like step-up, communicating acr/amr values, and how do we partner with signal sharing group to say that there are signals that then require step-up or killing a session.
    • Dick: One of the challenges for people rolling out an application is there's a lot of things, but the way this is laid out is these are still silos.
    • Wes: Let's lay down some concrete use cases
    • Mark: When I look at proposing how we're talking about it vs what's in the charter, I haven't heard entitlements or lifecycle management mentioned yet
    • Gennady: If we're trying to move forward, SCIM is a patch of things because someone else can't do things. When you're synchronizing an account you sync personal information, and you don't know where the information ends up, vs JIT provides the attributes just in time.
    • Dean: If we want to get to interoperable profiles, it might be that the profile takes a pointed perspective on what a SCIM provider must support, both server and client perspective.
    • Wes (in chat): if we come up with best practices and vendors don’t support them, its a pressure signal for them to support it
    • Gennady: Signals of privacy
    • Tim: We haven't zoomed out yet, one thing that isn't explicit yet is that we are picking winners. We need to pick protocols. We would be doing a disservice if we don't take a strong stance on protocols. This is the only chance we have to get the industry off of SAML. There are a lot of homegrown and legacy systems on SAML that will break, but people won't care until it breaks, and it's our responsibility to move things forward. Would like to have a deeper conversation about this next week. Maybe v1 has only OIDC. We should not document a profile that is the status quo.
    • Dean: This is in some ways picking winners. But we need to be careful about not excluding entire industries based on protocol. Even if we say down with SAML it will still take years to move off of it.
    • Tim: I think we need to draw a line and say IPSIE compliant means OIDC.
    • TLDR of the discussion - we should be choosy about the protocols we put into v1, we cannot support every protocol and every option. Aaron suggested that we look at what SAML does well, e.g. in the R&E space that Shannon supports, and see if we can bring those options into OIDC. (added by Dean after the meeting)
    • Mike: It's up to us to decide our scope. I would advocate that we not spend our efforts trying to improve the interoperability of SAML. Others can do that if they choose. We'll be more effective if we choose a single target and put all our efforts there.
  • Aaron: We did not close out on the task forces, follow up next week. May be a light week due to US Thanksgiving holiday.
Clone this wiki locally