[Openid-specs-ipsie] 2025-02-18 Meeting Minutes

Wed Feb 19 00:07:21 UTC 2025

Hi all, thanks for the great discussion today. Below are notes from the
call.

I tried to capture the end of the discussion today and submitted a PR to
the levels here:

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

Please review and comment and we'll talk again next week!

---

Date: 2025-02-18

## Attendees
- Kenn Chong (RSA)
- Aaron Parecki (Okta)
- Mark Maguire (Aujas Cybersecurity)
- Filip Skokan (Okta)
- Tom Clancy (MITRE)
- Dick Hardt (Hellō)
- Tim Cappalli (Okta)
- Karl McGuinness (Self)
- Russell Allen (Self)
- Bjorn Hjelm (Yubico)
- Robin Martherus (Cisco/Duo)
- Jon Bartlett (Zscaler)
- Travis Tripp (HPE)
- Mike Kiser (SailPoint)
- Pamela Dingle (Microsoft)
- Brock Allen (Duende)
- Gennady Shulman (Self)
- Jen Schreiber (Workday)
- David Lee ( Self)

## Agenda

- Welcome and antitrust policy reminder
- OpenID Contributor Agreement reminder
https://openid.net/intellectual-property
- Reminder about OpenID Slack
- Review Entitlement Management real-world examples
    - https://github.com/openid/ipsie/issues/51
    - Is there something apps can do to make it easier for the enterprise
customer to manage permissions in the app?
    - Is there enough in common with real-world examples to standardize
this today? Or should we push this out until later?
- Review IL and E levels
    - https://github.com/openid/ipsie/blob/main/ipsie-levels.md

Notetaker: Mark Maguire

## Minutes

- Antitrust reminder
- Slack reminder
- Contribution agreement reminder
- Aaron: Goal (in agenda) is there anything we can do to make it easier for
enterprises to manage entitlements in the app. If there are, is there
enough in common to define requirements.
- Karl: On AuthZen, would be nervous for IPSIE to take an AuthZen
dependency in this time. Externalizing auth is a great way to solve it, but
not enough real world deployments, so nervous to link the two at this point
in time. Only thing proven at scale is management of groups and roles.
- Mike Kiser: Zero standing privilege is not viable in the near term, seems
more like a 5 year ahead thing. Agree with Karl.
- Karl: Might be a way to lay a path to achieve it today and set groundwork
for it to be a PDP. IPSIE should lay out best practices that you can do
today.
- Mike Kiser: Need to say the standardization that allows the management,
but don't tie them into authzen or scim
- Aaron: 2 things were discussed. Authzen versus not and also real time
auth decisions or not. It would be nice to have an agreement for the
initial scope. Are we discussing provisioning permissions of what users can
do or do we want to enable more real time decisions?
- Mark: Like the idea of provisioning entitlements now, leave the door open
for realtime decisions in the future.
- Aaron: How do we find the commonality between groups and roles to make it
a requirement?
- Mark: The gap seems to be what people call it, whether that's groups or
entitlements. As long as we give a clear definition of what we mean, the
way it works at a low level is the same.
- Russell: There seems to be common pattern - in all cases, how policy is
expressed is same pattern. Almost language heirarchy: from simplest (a
role) to higher level (check the attributes of this thing, if it has the
attribute, you mean this policy). Higher level is computing based off
attributes. All different approaches to entitlements is doing one of these
levels for the identity/role/action. Just need to find generalized terms to
describe it.
- Karl: You might have a group but then individual can have direct
assignment inside the app as well. There are direct and indirect
relationships there. There is setting permissions, but you need to explode
that graph and understand it. If we want to answer the problem statement
for the enterprise, "can I prove to an auditor who has what access?" that
is a large scale depenedency. We need to define a smaller container - only
access can be given from the IdP - if both sides can change access then too
hard to handle.
- Tom: To what extent does the enterprise require the visibility and
automation
- Karl: For IPSIE to have meaning, what problem can it solve that is
meaningful? How do we adress long tail, not just the most complex
enterprise app. How do I set a baseline of capability. How do I revoke
access and ensure it is revoked? If we dont provide a path that is useful
to close loop verified access is gone, IPSIE value is decreased.
- Aaron: Goal of group is not to solve everything everywhere. Want to
meaningfully improve baseline in security. Small change in large number of
apps is better than full control over small number of apps. Need to capture
that.
- David Lee: Karl mentioned the biggest thing - we often do not know what
permissions the entitlements are connected to. The reason sailpoint went
with entitlement was to create a more generic term to say "you are
assigning something to someone to give access". This construct allows us to
decide how to assign access. Provide structures and rules about it. Allows
us to move in a better direction and level across.
- Mark: The initial question was is there enough in common with existing
systems to standardize, it seems the answer is yes. Karl mentioned it's
great if you remove the entitlement on the IdP but how do you know if the
application removed it? We previously said there was a requirement that the
application turns off local management.
- Dick: What David mentioned is right. Something Karl mentioned that "data
from enterprise needs to be read only from app." In provisioning, needs to
be controlled from identity service. Accounts should only be created from
identity service. Likewise, part of agreement with app is that only the
identity service can add or remove access. Some attribute about the user
should be mapped to within the app. Need an identity attribute that large
swath of apps all rely on, so enterprise knows if they change it all apps
update. Also, we need to standardize on terms. Need to help enterprises
with hundreds of apps to get handle on. Solving broad swath will make a big
impact.
- Aaron: Sounds like we have some consensus. Back to table of levels, how
do we describe what we put in the entitlements levels. There has been a
discussion about is it achievable / good idea? Sounds like the answer is
yes. "Groups" is that a good name? Is it overloaded? Should there be a
better title?
- Dick: I argue for groups. If we are aiming for long tail, microsoft and
google use groups. People already familiar with. Readily available for very
long tail of organizations. I still think groups are part of identity
lifecycle (people added and removed from groups, attribute of identity).
For that reason, we dont need entitlement management to be its own levels.
We should merge entitlement management levels into identity lifecycle
levels.
- Karl: Flip side of using group as primitive is directly assigning
permission to a user. Group is most generic. As group is mapped to
application concepts, authorization model brought into play. Leaving it at
groups makes no claims abt access statement (group + resource, etc). We
know who is in the set, but don't know how else someone might have access.
"Group" downside is group does not have an authorization context, it is
just collection of users. We need a construct linked to group but not group
itself.
- Dick: So should each app expose its permissions to identity service?
- Karl: Yes. Expose your roles, map your roles to my groups, and have the
mapping at the identity service and not at the application. Role is
application specific. Identity service and complexity happens within the
identity service.
- Aaron: So rewrite requirements that instead of provisioning group
memberships, instead groups expose roles, identity service consumes roles
and assigns to users. Where does that come back to the app? Is it an
attribute on the user?
- Dick: Definitely an attribute of the user. Roles are app specific.
- Karl: Want the app just to know about its context, and identity service
to have a group across those app roles.
- Russell: Onboarding the app, that set of roles becomes a contract between
app vendor and IdP. As an app vendor, we evolve our permission model at a
rapid pace. We enable that speed by evolving domain model without breaking
the role contract. As long as we can stay underneath, we can move at speed.
- Mark: If you look at the flow chart on the github issue, I laid out the
normal flow for mass, scalable app onboarding. 1) can the app use AD/Okta
groups, 2) if not, do they have scim, 3) if not what about webservices?
etc. I think we should tell apps they either need to expose their
permission model and allow an identity service to manage them or they need
to outsource the management to centralized groups like AD.
- David: Do we want to make it easier for what we do today or do we want to
provide a more secure way to do it moving forward? The current workflow is
due to limitations (ad groups was easiest, so we do ad groups). We then go
down the chart (ad group, scim, api, etc). When you look at it, we know
what enterprise does today, lets find a better way to move this forward.
How do we make a standard?
- Karl: Back to framing of long tail and enterpise apps, apps enter in
brownfield, cant lose site of shadow it. AD used to be the identity layer.
Now with cloud based apps, you have people using apps with distributed auth
scenarios, then at some point enterprise takes over management. There are 2
different identity layers needing to be mapped. Would be great if lifecycle
started within enterprise but not practical based on how SaaS ISVs grow.
They have their own identity service in case client has none of their own.
Might not be enterprise managed from day 0. How do we have a more secure
"sign in with google" and make it more secure
- Pam: At some point, what is the success we want to reward? Maybe, right
now, success is any automation at all. You tick the box, you get level 1.
Is level 0 CSV files? Or is that level 1?
- Aaron: Back to long tail comment, need some small improvement over
current state. Not going for perfect world.
- Dick: Building on it, I like the model Karl proposed, but maybe further
out. Start out with JIT at level 1, level 2 app exposes its roles and what
users have which roles. Also, what is anti entropy controls?
- Aaron: Need to figure out how to update the levels. Apps expose roles to
idp and user includes those rules
- Travis: If we try to push definitions up too high, it will decrease
number of people who implement. Role has a lot of dragons, b/c it is a set
of permissions on resources. We also have resource based policies, i.e. to
access specific resource need to MFA.

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/20250218/0783ad1b/attachment-0001.htm>