Skip to content

2025‐01‐21

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

IPSIE WG Meeting Minutes

Date: 2025-01-21

Attendees

  • Aaron Parecki (Okta)
  • Kenn Chong (RSA)
  • Sean Miller (RSA)
  • Mark Maguire (Aujas Cybersecurity)
  • Dick Hardt (Hellō)
  • Dean H. Saxe (Beyond Identity)
  • Filip Skokan (Okta)
  • Frederico Valente (Workday)
  • Karl McGuinness (Self)
  • Shannon Roddy (Self/LBNL)
  • Jon Bartlett (Zscaler)
  • Danny Zollner (Microsoft)
  • Ameya Hanamsagar (Meta)
  • Tom Clancy (MITRE)
  • Travis Tripp (HPE)
  • Mike Jones (Self-Issued Consulting)
  • Pamela Dingle (Microsoft)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Antitrust reminder

  • Interop planning

    • Gartner IAM summit wants an IPSIE interop event
    • December 2025 near Dallas, TX
    • goal: Define enough of IPSIE to get demos of interoperability
      • subset of levels
      • something concrete, not complete
      • not neceesarily in prod
    • Aaron and Dean - see if we can have a demo ready for Gartner IAM and interop testing between different products by Dec 8, 2025
    • We need both IdP and RPs to take part
      • at least 2 IdP and 2 RP to show a matrix of interoperability
    • KennC will review with RSA leadership team
    • DickH could create pressure on what IPSIE is - having to define this too early. We need to get something stabilized.
    • Aaron determine a date that we need to make a committment to an actual event, planting seeds now
    • Aaron we don't need to complete all the levels, etc. We can choose how much to demo on the interop to ensure that we're not biting off more than we can chew
    • Pam: talk about what interop means - is this certification? What are we testing?
    • Aaron: Don't expect certification this year. Expect to be able to demo features that we describe, e.g. P2 revoking sessions in the app.
    • SeanM: Consider having one non compliant tool in play to show what happens when it doesn't work as planned.

  • PR 37

    • Dean: This PR changes entitlements/group/provisioning to metadata updates where metadata wasn't firmly defined. Want to hear from mark about the change to metadata.
    • Mark: The metadata isn't the important part. The main question was whether we actually need 3 levels, so this mostly moves things into the first two levels, then added metadata updates back to level 3.
    • Dean: What I saw was provisioning/deprovisioning users, groups are brought in level 2. Does this make sense to everyone?
    • Danny: I'm just getting up to speed but I don't think so. Updating basic attributes of a user seems like a base level requirement.
    • Karl: This doesn't seem to track the conversation from last week. Last week we were arriving at entitlements and authorization is a different problem statement than lifecycle management. The need to handle the account lifecycle is a different problem than authorization. That's why entitlements wasn't quite how we were positioning it.
    • Mark: You're correct, P3 wasn't based on last week's conversation.
    • Tom: The levels are valid use cases rather than relatively more/less secure. These are kinds of bundles of optionality. It strongly informs what would be in the protocol, but it would have some shoulds/mays rather than hard groups of permitted functionality.
    • Dean: Based on your comment, do you think the way this PR isn't the right approach, is there another framing of the levels we should be considering?
    • Tom: This seems different than the AAL question, we get that phishing resistant is important as a banded threshold, and hardware binding is another, those are established leveling things. In the authorization realm, there's more of a spectrum of different valid approaches that depend on other features in the ecosystem.
    • Karl: We were starting to talk about the security outcomes the enterprise gets. The important part of the first level is the IDP gets to own account creation, there's no side channel. So there's a business process in place that says all account creation originates by assertions from the IDP, there's no sign up with email side channel. So we keep losing sight of what controls the enterprise is trying to assert.
    • Dean: I like the framing of assurance, it's giving us guidance on how to mature our assurances, as opposed to the mechanism.
    • Dick: Building on Karl's comments, I think in IPSIE all we want is MUSTs. To clarify Karl's comment, we need to capture that JIT is the only way not just possible. We want to be crisp about this.
    • Dean: Yes, part of the goal here is to reduce optionality.
    • Pam: Another way to look at this, right now we're saying JIT is a level and SCIM is a level, which is a technical but not business or security way of looking at it. What if we talk about the spirit of these, step 1 is controlled joiner process, you're controlling how someone joins. The next level is controlling the leaver, controlling the security around the joining and leaving.
    • Dean: How do we reframe this?
    • Aaron: Let's focus on joiner/leaver - on demand, ahead of time, remove the optionality from the system. Focus
    • Dean: We should reframe the table around the controls to establish, like you must only be able to join through an IDP driven mechanism
    • Mark: Karl mentioned restricting account creation, it's in the description but not in the table.
    • Dick: My comment was the same as Karl's, IDP should be the only one doing the provisioning. Level 1 is JIT, level 2 adds sync/async but doesn't exclude JIT.
    • Mark: I agree with Pam's comment, we need to define the spirit of the security rules.
    • Dick: The challenge is we wind up in the situation we're in today, with too many options and bespoke integrations. In the spirit of writing a profile we're trying to narrow the optionality. I think we have to provide rules as opposed to guidance.
    • Aaron: I don't want us to start with defining protocols. We're defining the outcomes that we're expecting in this table/narrative text. Next we follow with specific protocols - here's how you use SCIM/SCIM Events to accomplish X outcome. This is in contrast to NIST which speaks only to security outcomes.
    • Dean: I'd like to see more text of the control statement type, "App MUST allow users to be provisioned before they sign in"
    • Aaron: Another aspect is attributes on the account - not necessarily authZ attributes but attributes like name, email, etc.
    • Karl: We're coming back to lifecycle of the account J/M/L. Enumerating the session and identity lifecycles will help us make a lot of progress.
    • TravisT: When doing JIT, should there be an ability to configure automated user deprovisioning if the user hasn't used the app in X days?
    • Ameya: Wrote an issue about this https://github.com/openid/ipsie/issues/39. May depend on business processes/business needs to determine whether the user gets deprovisioned?
    • Dean/Aaron: what's the interop story for this?
    • Ameya: a uniform way to expose account inactivity is a base level requierment. Incorporating the business logic in the app itself is a step up.
    • TravisT: Interop issue - SCIM gives a concrete mechanism, OIDC doesn't enable a user lifecycle event. How can this be expressed?
    • Dick: What's deactivation?
    • Travis: Some of my customers use SCIM, some use JIT. Want to specify how long until they are deprovisioned.
    • Dean: Two controls - one cost driven, one security driven, both by deprovisioning users in apps
    • Travis: Agrees.
    • Dick: Pick this apart. When someone logs in, we don't want the app to let the user in after X days? Second, deprovisioning due to cost.
    • Travis: Some apps allow users to create an access token, allowing users to access the app without SSO (e.g. mobile app).
    • Aaron: This is a session lifecycle issue
    • Dick: GitHub has this issue - local keys to make commits, but you may only SSO in on an irregular basis. Someone must remove you from the org manually/SCIM to stop usage.
    • Travis: is there a standard attribute that comes along with the JIT?
    • Aaron: This is session lifecycle
    • Travis: Web session vs. non-web sessions
    • Aaron: this is a generic session issue which is different from deprovisioning which removes access entirely.
    • Dick: maybe 2 attributes - deprovision after X days, force relogin after Y days. Two separate management attributes
    • Travis: Faces pain with customers now on this issue due to lack of interop
    • Dick: This is a piece of functionality that is interesting and non-standard today
    • Karl: Put licensing out of scope. Too many issues that are app specific. Stick to security. Getting back to terminology - ephemeral access/accounts/credentials - there's a TTL that defines these instead of a business process that allows management. Lacks standards today - needs a standard set of terminology. The problem is side channel access points not related to the web SSO / web session.
    • Aaron: That sounds like something to add to the lifecycle table
    • Dean: will work on the table to frame the statements as control objectives
Clone this wiki locally