[Openid-specs-ipsie] IPSIE Meeting Minutes 2025-01-21

[Aaron Parecki]

Hi all,

Below are the minutes from the meeting today. Dean has also already
submitted a PR as promised updating the language of the provisioning
levels, so please review that and chime in on the thread.

https://github.com/openid/ipsie/pull/41

---
# 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

- Welcome and antitrust policy reminder
- Interop event planning
    - Gartner IAM Summit December 8-10
- Review PRs
  - https://github.com/openid/ipsie/pull/37
- Review and discuss IPSIE levels updates
  - https://github.com/openid/ipsie/blob/main/ipsie-levels.md


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





Aaron Parecki

Director of Identity Standards

aaron.parecki at okta.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250121/107375f7/attachment-0001.htm>