Skip to content

2025‐01‐28

Jump to bottom
Aaron Parecki edited this page Jan 30, 2025 · 3 revisions

IPSIE WG Meeting Minutes

Date: 2025-01-28

Attendees

  • Dean H. Saxe (Beyond Identity)
  • Aaron Parecki (Okta)
  • Wes Dunnington (Ping Identity)
  • Filip Skokan (Okta)
  • Kenn Chong (RSA)
  • Dick Hardt (Hellō)
  • Ameya Hanamsagar (Meta)
  • Brock Allen (Duende Software)
  • Jen Schreiber (Workday)
  • Dave Bryant (RSA)
  • Travis Tripp (HPE)
  • Jon Bartlett (Zscaler)
  • Danny Zollner (Microsoft)
  • Shannon Roddy (self)
  • Victor Lu (Independent)

Agenda

Notetaker: Dean H. Saxe, Aaron Parecki

Minutes

  • Antitrust reminder
  • OIDF Slack reminder
    • Not archived, not part of official OIDF records
  • Aaron - follow up from last week
    • need to clear up the scope of IPSIE
    • goal of apps supporting preprovisioning is for companies that support it to be able to use that with an app
    • focus of IPSIE is on the properties of apps and what they support
    • What we've been calling an IdP is not a single piece of software. It is a set of software used by the enterprise to support their deployments.
    • Need to focus on roles instead of discrete components
      • e.g. oauth AS and RS are roles that may be the same piece of software or different pieces of software
    • We are discussing how the identity provider role (which may be multiple pieces of software, e.g. sso, provisioning) interacts with the applications
    • Apps may also be comprised of multiple components
    • IPSIE is defining the interoperability layer between the roles, not discrete components.
  • PR 41

    • Dean: the interaction between ILM (JIT vs pre-provisioning) and how you provision entitlements are on different axes

    • Dean: added a paragraph to describe roles and who we are setting rules for. The profile defines capabilities of the applications/RPs. The enterprise IdP may or may not support all capabilities, which is ok, because not every IdP supports all functionality

    • Dick: I thought the goal was "here's what's in place". Both parties have to have the capabilities to meet a level. It seems strange to say this is only about the RP

    • Dean: Because there are more RPs than IdPs, we need to take the perspective of specifying what's necessary for the RP then IdPs have to match the levels of the RP. An IdP might support IPSIE A1 even though the RP supports A2. As a buyer, I need to buy an application that meets a set of IPSIE levels that I can meet with my tooling today.

    • Dick: The enterprise buys apps and also IdPs, so they need to know what levels their IdPs support

    • Dean: If we define it only for the RP and RPs take on these profiles, then IdPs will say which profiles they meet of the RPs.

    • Dick: Let's look at JIT provisioning. RP needs to support JIT inbound, and IdP needs to support JIT going out. Both sides need to support this.

    • Dean: If the RP supports P1/P2/P3 but the IdP only supports P2, then that's the level of integration you have

    • Aaron: This originated from the discussion of "As an IdP I'll never support IPSIE P2".

    • Aaron: We're defining capabilities that apps need to support, it by definition creates an obligation for the IdP. Audience is RP because there are more of them

    • Dick: More enterprises than RPs, more RPs than IdPs, I think this will be driven by the enterprise needs.

    • Aaron: Not trying to define the security needs (e.g. MFA) for an enterprise. Defining capabilities. IdP must communicate MFA to the apps, but we don't define whether the enterprise requires MFA

    • Dick: two sides, functionality is on both sides.

    • Shannon: My IdP will never do provisioning of users. I have a second product that does provisioning. The phrasing of IdP is what's challenging

    • Dick: this goes back to the initial commentary by Aaron.

    • Shannon: My IdP does JIT. I can also provide group info (entitlements). But I won't preprovision.

    • Aaron: Question to Shannon - does redefining the term IdP as a role (the entire system) address your concern?

    • Shannon: yes. Is P1 -> P3 a progression that the IdP or enterprise has to satisfy?

    • Aaron: That's why we brought in the idea of a progression for apps. On the RP side it is meant to be a progression. IdP doesn't necessarily need to mature to gain the capabilities, the enterprise needs to mature by providing the right tools.

    • Dick: Are we thinking of the IdP as something that does SAML? In the market we think of the IdP as any software providing identity services.

    • Aaron: We use identity provider (as a role) to talk about the whole set of systems

    • Dick: Maybe use Identity Service instead of provider?

    • Aaron: the naming may be causing the concern

    • Dick: Need to focus on both sides, not just the RP. I like the discussion about how they talk to each other...

    • Aaron: How do we avoid the problem of these levels looking like a progression for the enterprise's identity services? e.g. P2 - there's a clear requirement for RPs to meet P2, how do we map that back to the enterprise identity services?

    • Pam: Describe outcomes - what we can then talk about is a maturity model or conformance. We've talked about the things we don't allow to happen, moving into the conformance world. Or maybe a FAPI world...?

    • Dean: Recent updates to the model were conformance focused

    • Danny: enterprise has lots of components that cover their bases for authN, provisioning,etc. This can't be an a la carte menu, need to be able to label things as a conformance level. We may need to make this more granular for the identity service role. Needs to be defined.

    • Dean: Can we focus on the RP conformance at e.g. P1 - P3, and then identity services can meet them at P2, so the deployment is P2

  • Aaron: Goes back to A2 MFA - IdP must accept MFA
  • Dean: Maybe we need to set requirements on both in separate levels?
  • Russell: Can we use different terms for these entities and still make the conformance statements? Later address how we get specific protocols to bind to the conformance objectives.
    • Aaron: Agreed, right idea, need better terms
    • Russell: generic terms in this doc?
    • Dick: We talk about app not RP, maybe we just need to talk about the enterprise instead of IdP
    • Pam: This may be what makes IPSIE different - it takes two to tango. What if we describe interoperating entities instead of the overloaded names. Security requirements apply on both sides because they work together to achieve the goals. If we speak of a interop relationship we can use that lens to look at this issue.
  • Aaron: Next steps?
    • We agree the terminology should change to be higher level - not protocol specific, focus on outcomes
    • Remove the statement Dean added about functionality on the RP side, make it both sides
    • Dean: redefine the roles in the terminology doc to stay away from IdP/RP, maybe enterprise and app
    • Dick: Dimensions in the table can we define "what does the enterprise do" and "what does the app do". Put these on different axes. Focus on capabilities at the intersection which applies to each role.
      • Rows are levels, column for app, column for the enterprise
    • Dick: Flipping it so rows are p1/p2/p3, columns are app and enterprise specific obligations.
    • Aaron: Make small changes on terminology first
    • Dean: Will work on that asap. Then we can rotate the table orientation.
Clone this wiki locally