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

[Aaron Parecki]

Hi all,

Below are the minutes from the meeting yesterday. Please also continue the
discussion on the open GitHub PRs!

---

# IPSIE WG Meeting Minutes
Date: 2025-01-14

## Attendees

- Aaron Parecki (Okta)
- Dick Hardt (Hellō)
- Sean Miller (RSA)
- Shannon Roddy (self/LBNL)
- Kenn Chong (RSA)
- Jon Bartlett (Zscaler)
- Tom Clancy (MITRE)
- Mark Maguire (Aujas Cybersecurity)
- Filip Skokan (Okta)
- Travis Tripp (HPE)
- Mike Jones (Self-Issued Consulting)
- Mike Kiser (SailPoint)
- Karl McGuinness (Self)
- Brian Soby (AppOmni)
- Pamela Dingle (Microsoft)
- Jen Schreiber (Workday)
- Victor Lu (Independent)
- Nagesh Gummadivalli (Workday)
- Ameya Hanamsagar (Meta)


## Agenda

- Welcome and antitrust policy reminder
- Review PRs
  - https://github.com/openid/ipsie/pull/34
  - https://github.com/openid/ipsie/pull/35
  - https://github.com/openid/ipsie/pull/33
- Review and discuss IPSIE levels updates from last meeting
  - https://github.com/openid/ipsie/blob/main/ipsie-levels.md

## Minutes
- Review of Antitrust policy
- **Reviewing PR 34**: Updates wording to MFA terminology to include
references to NIST, PR was approved and merged
- **Reviewing PR 35**: Reviewed phishing resistant authentication, provided
a definition. Tim Cappalli recommended updating the definition to inculde
channel bonding.
- **Reviewing PR 33**: About enterprise being a resource owner. PR gave
examples of resources (user directories, identity providers, relying
parties etc). Karl McGuinness made the point this was not what we meant by
resource owner last call. The examples are useful, but it was pointed out
that it is misleading that resource owner is an identity provider.
Recommended to continue offline on the GitHub thread, but looking to find a
term already defined by another standard instead of creating a net new
concept. Holding on merging PR 33 and waiting for more edits. "Resource
Owner" creating confusion due to differences in OAuth definitions versus
this use case. George Fletcher referenced there are differences between
SaaS and internal apps. For internal apps, enterprises have complete
control. Pam Dingle recommended we define enterprise as the driving
business force. Pam suggested we say enterprise is the business force that
rationalizes what participants are created. Karl mentioned that enterprises
have a decider role for security decisions and IPSIE should help reduce
friction on trust between resource and vendor. Aaron recommended we write a
new sentence or two to capture what we discussed here. Russell Allen
recommended we incorporate Pam's definition of enterprise.
  - Suggestion for Enterprise from Travis Tripp: An enterprise refers to an
organization that seeks to implement enterprise-grade governance of its
users, including authentication, lifecycle management, and risk mitigation.
It emphasizes the scale and complexity of managing user access and
authentication processes across all applications used within the
organization. By centralizing these processes and utilizing an
industry-standard set of protocols, the enterprise ensures secure
management of user credentials and access, allowing users to manage a
single set of credentials while the organization can centrally control and
monitor access to various applications.
- Aaron recommended for resource owner definition, we shorten it to avoid
conflicting with other accepted IAM definitions of resource owners.
- Pam recommended we add an aspect of policy control to the definition.
- PR 33 was merged.
- Conversation moved onto discussions of levels for lifecycle management
- Karl recommended grant or revoke from central resource, highest maturity
is how do I know what a user can do in the app? That is a harder problem
than can I drive a business process. It is a very different process to know
who can do what in the app versus different automation levels.
- If users have more access then they should have, how do we remediate?
Based off the app's architecture, there could be many different ways to
determine access. Just managing groups is just a piece of the puzzle. They
could have access directly in the app. To raise the security bar we need to
control the blast radius and have the app's local authorization model.
- Aaron asked if there are existing standards that can address this. Brian
Soby mentioned he has never seen a large SaaS app that meets a standard
like ones alluded to.
- Nagesh Gummadivalli mentioned this is a hard problem to solve. If we
define what the applications log into a central place then we can monitor,
but the drift happens outside of the product.
- Karl - companies are spending significant money trying to solve this
problem building custom connectors to address this. With IPSIE if we set a
high standard it could pave the way for enterprise applications to meet
these better standards in the future.
- Travis mentioned how platforms like AWS & HPE GreenLake you can give
session-constrained access in a JIT fashion that only lasts for the
duration of the session. Also, how does conditional access fit in? I.e.
giving access only if they meet certain criteria. Might be possible with
SCIM?
- Mark Maguire: We should shift the burden of complex entitlement
management to the application teams. The application should bear the
responsibility for providing an interface that allows centrally managed
groups to give access within the application.
- Pam: We could just have 2 levels? Aaron: We get to pick. Pam: We are
discussing the management of the account versus authorization. These can be
separate things. There are a lot of ways to skin the entitlement cat. We
dont need to define everything in minute detail, but today there is no
simple pattern that will work in every case. If its too hard to certify
against it could harm this work. 2 levels, and have
authorization/entitlement world be separate / punt on it?
- Dick Hardt: There is a huge value in being able to centrally manage
groups and push that out to apps. When I think of entitlements that is a
big complicated thing, so by changing this to groups it becomes more
streamlined.
- Ameya: Account may have access to certain artifacts/data. There is not
any protocol / standards for guest accounts. Should we include that here?
- Discussion if we should remove Entitlements and not be a separate column.
After account provisioning, is groups the next right thing to tackle?
- Should we have just 2 columns? JIT - which just includes groups and
another which is Asyc, so I can control groups separately.
- Aaron: Should we make level 1 JIT and account creation and level 2 being
able to provision groups?
- Mark: Would that imply that if I am an app and I support JIT and make
everyone as a super user then I am IPSIE compliant? I think the security
baseline should be higher than that.
- We also are not preventing from users logging in directly with their
email, even if the enterprise supports jit, could external entities do
account takeovers?
- Aaron: I like the idea that not only can accounts be created by JIT also
they cannot be controlled in other ways.
- Karl: Agreed, becomes a stronger statement for a security team.
- Aaron: Sounds like this needs more refining. 2 main points: in JIT ensure
users are not created as admins and Karl's comment about ensuring JIT from
IDP is the only way accounts are created - not allowing users to sign up
via email. We need to capture these requirements in the levels.
- Pam: What we are talking about is demonstrating control. Not only can we
do something, but can we do something with security controls that
demonstrates the account creation process is secure. This could help us
define further - not just what you do but also what you don't do.
- Mark: Will take a first attempt at creating a PR that describes behavior
and negative behavior we want to avoid.


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/20250115/99d2487f/attachment.htm>