[Openid-specs-ipsie] 2025-01-28 IPSIE WG Meeting Minutes

[Aaron Parecki]

Hi all, below are the minutes from the meeting this week.

As discussed on the call, Dean has updated the language in the PR and it's
been merged. Dick has also created a PR to rearrange the table like we
discussed.

---

# 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

- Welcome and antitrust policy reminder
- Reminder about OpenID Slack (invite link:
https://join.slack.com/t/oidf/shared_invite/zt-2xcwp65rr-2rInmlLajjq6zcb1G8exlQ
)
- Defining IPSIE Roles
- What is the goal of IPSIE levels
- Review PR 41
  - https://github.com/openid/ipsie/pull/41
- Review and discuss IPSIE levels updates
  - https://github.com/openid/ipsie/blob/main/ipsie-levels.md


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.


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/20250130/07340e25/attachment.htm>