[Openid-specs-ipsie] 2024-12-10 Meeting Minutes

Tue Dec 10 18:14:10 UTC 2024

Hi all, thanks for the great discussion today. Below are the minutes from
the call, also posted on GitHub:

https://github.com/openid/ipsie/wiki/2024%E2%80%9012%E2%80%9010

---

# IPSIE WG Meeting Minutes
Date: 2024-12-10

## Attendees

* Aaron Parecki (Okta)
* Sean Miller (RSA)
* Kenn Chong (RSA)
* Karl McGuinness (self)
* Dick Hardt (Hellō)
* Frederico Valente (Workday)
* Anthony Giliberti (Capital One)
* Jon Bartlett (Zscaler)
* Travis Tripp (HPE)
* Victor Lu (independent)
* Jen Schreiber (Workday)
* Tom Clancy (MITRE)
* Filip Skokan (Okta)

## Agenda

- Welcome and antitrust policy reminder
- Review PRs

## Minutes
Aaron - Review of meeting calendar (1 more for the year)
Aaron - Last week discussion on refining use cases, open PRs to refine the
use cases
Review of github.com/openid/ipsie/pull/15 - George not present to dive into
framing, agreed to merge changes

Review of github.com/openid/ipsie/pull/16 - Matt recreated pull request
with expanded use cases with cleaner diffs
Aaron - How to we decide next steps on how to tackle and what order?
Aaron - Need to dive into a granular discussion by breaking up into
separate pull requests that can be commented on. Right now it is too large
to tackle all at once
Jen - agreed on the approach to move things along
Jen volunteered to break things out into separate issues
Aaron - The goal as an admin of an enterprise company is to know if they
chose the secure way to pull in an applicaiton. Does it meet the bar that
has been set for the standard or not? This is without diving deep into
specifications. In order to achieve scale this needs to include
interoperability but at a high level those details are hidden.
Karl - it is almost like a compliance algorithm you need to meet
Aaron - exactly
Frederico - is interoperability the goal of this group?
Kenn - for compliance step by step approach, level 1 has mfa in front of
all apps, level 2 all apps have sso, level 3 can receive a shared signal
and perform a task like universal logout
Frederico - so you are suggesting the interoperability matches the levels?
Kenn - correct
Dick - All the layers do their part independently and the combination of
the idp and the app bring the compliance
Aaron - we need to be clear to distinguish spec compliance versus
regulatory compliance
Not every app has to behave the same internally. we are talking
specifically about how apps and idp integrate
Russell - Dick just covered what i had to say.  As an app vendor, would
like to see more balanced wording so it is not so enterprise centric.
Result of IPSIE would encourage app vendors to achieve the levels
Karl - Enterprise is the demand side (buyer/consumer) which is driving the
requirements which is driving the vendor to support it. why would an isv
implement it? Wont allow an application to be used in my environment unless
it supports x
Aaron - do you frame it differently Russell
Russell - he agrees and wants to produce something that comforms to the
spec. Just dont want to miss something coming 100% from the enterprise side
Jen - hearing multiple actors (vendors, enterprise, app, idp and rp)
Dick - combination of the ap doing the part, enterprise saying it wants
idp1 to do level 1 and app to do level x
Aaron - everyone is working in service of the customer. it is the same
customer who is choosing the apps, idps, ..  What does it mean to be level
1, level2, ...
Dick - combination of what the app, idp, ... does. Are we missing something
from Russell's comment?
Russell - no, all covered by comments
Aaron - lets split the bulletpoints in the issues list into separate
tickets and figure out what happens in level 1, level 2, ... Whats the bare
minimum, extended features, level/category for migrations,
Karl - what are the vectors that mature as we go through the levels?
What happened to levels of assurance with NIST is there something to learn
from that? Binding to the strength of the authenticator became harded to
put in levels. We are mixing life cycle concerns with session management
concerns, traditional idp concerns, federation. Do these all mix into one
level or how do we handle them?
Aaron - levels would bring in new capability at various levels. SSO is
pretty core (level 1) to get into the application but doesnt include
groups. group management would not be part of level 1. level 2 might be the
reverse of SSO
Karl - groups in your example is an optional function. what do you need to
authenticate, how well you do authorization is not directly related to that
Aaron - MFA both directions - idp communicating to app level and the app
level being able to request it. i think that might be level 2 because even
without that, standardized sso is useful. each level should have some new
functionality that adds value on its own.
Karl - an example might start off with TTL based expiration and a higher
level you can issue a command to drive it, maturing your ability to manage
it. Each level adds more security controls to manage. Just saying you
support SSO doesnt address strength of authentication, length of the
session, identity account bindings
Aaron - next thing is are these sequential or different paths you can take
along this. level 1 logging in, level 2 strength of how you login, level 3
session termination/reversing the login (full management of the lifecycle)
Frederico - Question about how shared signals comes into play? Shared
signals would help with login and account lifecycle - how that is achieved
Are we thinking about signals for logoff flows?
Aaron - Trying to define the levels based on the outcome to achieve rather
than the protocols (how)
Karl -provided an exmaple of the NIST table that shows changes between
AAL1, AAL2, AAL3 explaining each level and what changes
Aaron - some outcome in the table like verifier impersonation, replay
resistancen. Identity statements becomes a requirement at level 1. Shared
signals enables some other feature in higher levels.
Karl - is authorization the same table, IPSIE becomes a combination of
authenticatioh and authorization levels maybe
Kenn - agree if we organize by different concerns
Frederico - start at foundational level
Tom - they are othoganl, vectors of trust. the technical profile about how
the protocol works doesnt need to include all the specific assurance
characters of the vectors. Those may be specific to the environment.
Aaron - reviewed diagram with Customer Enteprise, Enterprise Identity
Provider (IDP), Saas App (RP) to discuss terms and relationships. The
interop is between Idp and RP to play together so the customer knows the
apps they use will work and be as secure as needed for their IdP.
Jen - who is our audience for the profile?
Aaron - 3 audiences - developers (Idp) , developer (RP), customer
Karl - security compliance team inside the enterprise would want to be able
to map the security controls provided to IPSIE to their internal framework
of how they are managing their internal model. the artifact they are
looking for is understanding the different vectors that i need to demand
those or categorize what we have or are missing
Jen - these coulld be 2 docs - 1 is the security controls, and the other is
the technical profile of how that is implemented. Meets the developers and
customer/buyer actors
Tom - The intent is to apply tailoring to the security features by defining
FAL plus - types of authentication are defined and then tailoring against
AAL2. NIST SP800-63 section 5 (digital identity risk management and
tailoring process). Tailoring FAL -> technical profile for OpenID/OAuth 2.0
Tailoring IAL and AAL -> semantic profile for OpenID, OAuth 2.0 claims
(acr/amr, vtr/vtm)
Karl - agreed with Tom where the subset is defined. we are then addressing
gaps with tailored add ons
Kenn - Proposed

    Level 1 (Access to resources must be protected with MFA)
    Level 1.1 - Resource must allow user to setup at least 1 MFA method
    Level 1.2 - Resource must allow user to support credential recovery
using an MFA method

    Level 2 (Access to different resources within the same org must support
SSO)
    Level 2.1: Able to configure assurance levels for between groups of
applications
    Level 2.2: Ability for users to consent/revoke claims shared between
IdP/RP

    Level 3 (Management of active sessions)
    Level 3.1: Able to support Single Logout
    Level 3.2: Able to receive Shared Signals and act on them (i.e logout
if user is compromised)

Aaron - Fundamental assumption is IPSIE requires SSO. Do others agree?
Jen - can you define SSO - concept versus protocol
Aaron - users do not login to applications directly. If they do login
directly that is a shadow IT account which we are trying to prevent
Karl - we want a centralized management of sessions and apps dont have
their own implementations of credential management, session management.
want a single place where you can implement policies and session
management. dont want it embedded in the resources themselves. security
standard here - gaps in moving the needle forward on security maturity,
backdoor access for tokens are where you get attacked. customers need to
have a way to udnerstand what the apps can do and tailor the security based
on the risk of the resources.
Russell - do we need a requirement that if you are a certain level you do
not have any backdoor access
Karl - I would love that
Kenn - how realistic is it that an RP doesnt have a backdoor in case
something goes wrong
Karl - there is a proces to do that ie. breakglass tenant recovery
Jon - but that breakglass tenant recovery should have some restrictions on
it
Aaron - we will meet again next week. following 2 weeks we wont meet
Need to come up with a description of the levels and sublevels.  Aaron
liked the AAL example table
Any volunteers to take a first crack at creating the framework to start
talking about the levels?
Aaron volunteered to take a first stab at it. Jen to create a bunch of
issues in GitHub for discussion

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/20241210/f9efbd7d/attachment.htm>