2024‐12‐10

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