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

[Aaron Parecki]

Hi all, below are the minutes from the meeting this week. As discussed
please leave a comment on this new GitHub issue with examples of how you
currently manage entitlements:

https://github.com/openid/ipsie/issues/51

Talk to you next week!

---

Date: 2025-02-11

## Attendees
- Dean H. Saxe (Beyond Identity)
- Aaron Parecki (Okta)
- Dick Hardt (Hellō)
- Sean Miller (RSA)
- Kenn Chong (RSA)
- Dave Bryant (RSA)
- Wesley Dunnington (Ping)
- Russell Allen
- Mark Maguire (Aujas Cybersecurity)
- Robin Martherus
- Aboobacker MK
- Brian Soby
- Russell Allen
- Jen Schreiber
- Victor Lu
- Tom Clancy (MITRE)
- Ameya Hanamsagar
- Travis Tripp (HPE)
- Shannon Roddy (self)
- Jon Bartlett (Zscaler)
- Pam Dingle (Microsoft)

## Agenda

- Welcome and antitrust policy reminder
- OpenID Contributor Agreement reminder
https://openid.net/intellectual-property
- Reminder about OpenID Slack
- Review IL and E levels
https://github.com/openid/ipsie/blob/main/ipsie-levels.md


Notetaker: Dean H. Saxe


## Minutes

- Antitrust reminder
- Slack reminder
- Contribution agreement reminder

- Discussed table of levels at the last meeting, focused on SLn levels
    - made sure the descriptions were formed in terms of requirements of
what each role has to do
- Today, focus on ILn / En levels
    - Aaron rephrased IL/E levels in the same format
- Dick: question on process / comment on IL levels
    - Are Aaron and Dean both chair and editor?
        - Aaron: in OIDF this is pretty normal for chair/editor roles to be
shared.
        - Dean: We welcome more editors if there are any willing partners
    - Dick: Likes the model where the chairs and editors are independent
(e.g. IETF)
    - Dick: How do we separate meeting management from Dean/Aaron
participation
    - Aaron: It's challenging to get people to contribute at editors.
Working on content because it appears that's the expectation of the group.
    - Dick: Wants to see us be productive, hard when editors and chairs are
the same people.
    - Sean: Haven't seen a lot of external PRs.  No concerns from Sean.
    - Dick: Past meetings have been dominated by the co-chairs/editors.  No
concerns
    - George: No requirement for chairs and editors to be independent
people.  WG decides what is best, what works for the WG.
    - Aaron: Right now we're defining the framework, not the profile.
- Dick: Separating ID Lifecycle from entitlements is not in our best
interest - should be a single dimension.
    - Aaron: goal of separate tracks is that products can grow along each
independent track.
    - Dick: Groups are inherently attributes of users and vice versa.  You
can't provision a group without users, so this appears as an extension of
groups.
    - Travis: You can have groups without users.  Users can be added
independently of group creation
    - Dick: groups aren't useful without users.  Dick thinks that
users/groups are on the same dimension.
    - Russell: Is group an overloaded term?  Entitlement track is about
authZ, groups tend to be how we discuss authZ.
    - Dean & Aaron: Agree with Russell
    - Aaron (as contributor): are groups the right construct for this level
of authZ that we're discussing.  Should we instead talk about roles &
entitlements as the draft in the SCIM WG discusses.  Is this the proper
path?
    - Travis: Enterprises care about users/groups in most cases.  Associate
entitlements to an identity or attribute of an identity, in which sense a
group is an attribute.  Associate a group to an entitlement then attach
user to group which grants entitlements.
    - Dick: agrees. Mapping in the app between user attributes and authZ in
the app.  AuthZ is contextual to the app.  Entitlement is therefore
contextual to the app and the user.
    - Aaron: The entitlements are mapped in the identity service.  What we
need is a way for the app to publish what entitlements it exposes.
Published into the identity service where they can be assigned to
users/groups.  This is very different from what we've written today.
    - Travis: IPSIE level should say we support groups.  Support the
context/concept of groups
    - Sean: Concept of groups is more abstract - roles/groups/etc. Managing
access/entitlements is the thing to expose
    - Dick: We need groups, they are core. Thinks groups are part of the IL
mapping.  Maybe we need something else mapping attributes to functionality.
    - Aaron: What do you want the app to be able to do based on group sync?
How do we define the interop behavior between ID service and App?
    - Dick: ID service isn't creating groups in app. Exposing groups it has
at the ID service.  App is consuming the groups.  ID service decides which
to expose to the app.  Creating groups at applications implies that they
only exist at the app and not the ID Service.
    - Aaron: If apps consume groups from ID service, what do they do with
them?
    - Dick: Decides how to map them into the app
    - George: Directionality issue to decide with respect to assignment.
Someone has to say, "George can do X within app Y."  Could be due to group
membership where enterprise admin says "group X gets these privileges at
App Y". Alt, Identity service sends its authZ model to the app.  Assignment
happens at the ID service.  We can't leak secret groups to apps.
roles/Attributes are incompatible with graph based authZ.  Where does
assignment of capabilities happen? App? Identity service?
    - MarkM: Nomenclature difference based on where we come from.
Entitlement is the superset of group/role/profile.  Need to define
nomenclature.
    - WesD: We need a lingua franca between the systems.  There are
multiple possible use cases - how prescriptive do we wish to be? We need to
tease out provisioning from entitlement.  Thinks groups/entitlements should
be in the IL levels.
    - Dick: group is an attribute of the user. Maybe En needs to be authZ
lifecycle.
    - WesD: Group is one way to get entitlements.
    - Dick: Works for smaller orgs.  Roles are like groups... AWS Roles are
very specific account oriented things.  (Dean side note: Model is not
universal across all systems)
    - Pam: agrees with Dick.  Many ways to do this work.  Maybe this is
going too far? There are many ways to solve the problem and they may be
equally secure.
    - Aaron: Makes sense.  Focus on secure, interop profiles.  As we get
into authZ management, there are many ways.
    - SeanM: I was getting at the same idea.
    - Dean: At what point do we decide this is a big challenge that we
cannot solve easily?  Maybe we punt on this and focus on IL/SL for now.
    - Travis: Agreement.
    - MarkM: Difficult issue.  Not sure we achieve our goals if we don't
solve how to manage authorization within apps at the Identity services.
    - Russell: Concur with Pam, this is a conformance statement.  At a
later stage we should define how to achieve a specific conformance level
through specific protocols/mechanisms.
    - Pam: This is a directionality conversation (agrees with George).
Value in saying, "here's how to sync groups securely".  Repeat for roles,
etc.  If we define entitlements many people may not be able to conform
today.  Need to understand whether people can adopt this model. Maybe
there's a groups level 1 and a roles level 1 to put a stake in the ground
for how we get to a level 2 on both.  Doesn't penalize someone for opting
out of these levels.  Can define based on what we believe is current best
practice.
    - Aaron: helpful framing
    - WesD: OIDF strength is that every requirement is a testable
requirement.  Cannot be vague.  All levels must have a concrete set of
tests.
    - Shannon: SAML - expresses groups, entitlements, etc. as attributes.
Finding apps that can consume these and use them is rare in his experience.
    - Aaron: Asks Shannon, can you tell your apps how to uplevel by
consuming this information?
    - Shannon: Agree on the goal, sceptical on whether apps will get
there.  Asking people to be proficient in IAM when they are not.
    - Aaron: We need to make it as easy as possible for the apps/non-IAM
oriented admins
    - Shannon: Do we have service providers at the table
    - Russell: Yes, me.  Agree with Shannon. One of our big challenges is
our authZ model is bespoke to our app.  No good mechanism to expose this
model to the identity service.
    - Dick: Tell us more.
    - Russell: Our model is atypical. Set of resources that we control
authZ to, CRUD permissions per resource.  Multi-tenant, so we need to
impose tenant level authZ boundaries. Resources are hierarchical, high
level roles give access to subsets of the resource tree.
    - Dick: Is all management of authZ done at the app?  Do you consume any
authZ from the identity service?
    - Russell: Managed internally only.  May get federated role, not
permissions at an atomic level. Depending on the part of the app, there may
be no ability to assign permissions from the identity service.
    - Dick: We need some coarse grained controls - role/group - for authZ.
    - Russell: developing a SCIM server designed to allow selection of
attributes to sync (?).  Would be helpful to not have to sync all
attributes.
    - MarkM: we're all biased by our past experiences. E1/2 feels like
40-50% of systems could meet these levels regardless of protocol.  Most
modern apps allow provisioning.  Set standards that allow an IdP/IGA to
provision authorization without defining a mechanism.
    - Aaron: Getting to interop.  2 phases: high level issues first, then
specific implementations.  If we have many different mechanisms, we have
not achieved interop.
    - Travis: happy to share some use cases at a future meeting.  Echoes
Mark's statement.  Needs an interface to provision authZ for users.  We can
be opinionated on the mechanism.  Groups is the most common interface
Travis sees in real world deployments.
    - Pam: We're getting to a thru-line.  Interop - what are you asking
your Identity services to do?  Are you asking for attributes?  Is there a
security pattern for how they are sent to the app? Maybe we work thisby
considering what any service provider wants from an identity service to
attack known security risks?

- Aaron: what's the next step?
- Dean: Collect docs on how authZ is managed in different tools.
- Aaron: review those next week.  Aaron will create an issue for people to
add their data to.




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/20250211/560a0fa1/attachment-0001.htm>