Skip to content

2025‐01‐07

Jump to bottom
Aaron Parecki edited this page Jan 10, 2025 · 6 revisions

IPSIE WG Meeting Minutes

Date: 2025-01-07

Attendees

  • Aaron Parecki (Okta)
  • Dean Saxe (Beyond Identity)
  • Wes Dunnington (Ping Identity)
  • Sean Miller (RSA)
  • Dick Hardt (Hellō)
  • Kenn Chong (RSA)
  • Jon Bartlett (Zscaler)
  • Brian Soby (AppOmni)
  • Karl McGuinness (Self)
  • Travis Tripp (HPE)
  • Arnav Choudhury (Self)
  • Tom Clancy (MITRE)
  • Shawn McGuire (Riot Games)
  • Shannon Roddy (Self/LBNL)
  • Pamela Dingle (Microsoft)
  • Victor Lu (Indepedent)
  • Mark Maguire (Aujas Cybersecurity)
  • Apoorva Deshpande (Okta)
  • Tim Cappalli (Okta)

Agenda

Minutes

  • Notetaker: Dean Saxe

  • Reviewed antitrust policy

  • Issue 5

    • Dean: we've discussed the definition of enterprise over the last few meetings, what types of entities actualyl qualify? we have some language around what an enterprise is in the terminology doc. Wanted to come to a conclusion and close this out, have we reached rough consensus on what an enterprise is
    • Karl: what makes the difference in IPSIE compared to standard OAuth is the enterprise is the resource owner rather than the end user. So when we profile specs we need to define constraints of the scope, put additional constraints around privacy and trust boundaries
    • Dean: should we add a sentence saying the enterprise is the resource owner?
    • Karl: I don't know if it has to be that language, but this definition doesn't capture the difference between this and consumer
    • George: in the past, the issue was in order to make short term progress on IPSIE related work, we need to constrain the scope of the domain in which we are trying to solve a problem. I don't have any issues with the definition itself, but I don't feel like it constarains the scope. Maybe we don't actually use the term enterprise, but instead describe the problem we're solving, and also describe which scenarios it doesn't work in. How do we bound the problem we want to solve, and this definition of enterprise doesn't sufficiently define the problem boundary
    • Dean: We haven't thrown out multilateral federation, but we haven't tackled that issue yet.
    • Wes: You mentioned something that was an important clarification. Been wrestling with the role of the resource owner vs relying party. In this ecosystem the three roles are within a boundary. Why is the enterprise dictating policy to the RP when the RP owns the resources?
    • Dean: In general we'll have 1:N IdPs and 1:N RPs, they are assets of the enterprise, the enterprise controls them. Like Karl's language that the enterprise is the resource owner.
    • Dean: Will go back and finesse the definition

  • Issues 24 and 25

    • Dean: Jen had broken out "Notifications" and "Signals", can we close out 24 and roll it up under 25 saying notifications are signals
    • George: when I think of a signal I think of something I receive and do some processing. A "notification" may not be processed.
    • Tim: The term "signal" from SSF, those are explicitly things you receive and are not under any obligation to do anything with it
    • Dean: any objection to closing 24 and just using the term signals? Will plan on closing 24 before the next meeting

  • Aaron: Discussion of IPSIE levels on the last call

    • Main feedback - break this into different tracks, reworked the chart to match the discussion
    • AuthN track
      • 3 levels A1, A2, A3
      • The levels are in increasing complexity/security
      • A2 requires the IdP to communicate the MFA level to the RP, RP can require a specific MFA level and communicate to the IdP
        • KennC: Can you change request to require?
        • Aaron: good question
        • Kenn: how do we resolve conflicts between IdP and RP on MFA levels
        • Tim: if the app has its local MFA level requirements, they must be communicated in the request. IdP must be able to fulfill the requirement. Don't create a shadow credential at the RP
        • Wes: What happens if the IdP cannot meet the RP requirements?
        • Aaron: let's not define business rules that we cannot enforce. Let's incentivize the RP not to require enrolling a local credential.
        • Tim: Can we enforce that the RP must never enroll their own credential? Maybe via certification programs?
        • Aaron: Adding Tim's requirement is important - apps are expected to request a specific mechanism if it goes beyond the IdP default
        • Karl: are we simply articulating acr? IdP metadata should be a base requirement to communicate what the IdP did for authN to the RP. Require this at A1.
        • Aaron: Good baseline for IdP to comm. what happened at A1. At A2 RP can request something from the IdP.
        • Pam: Logout - tightly coupling single logout with the ability to send an authN context. Does this mean that at A2 I need authN context and single logout?
        • Aaron: We can break this into separate levels if needed.
        • Dean: Should we separate logout from the authN levels?
        • Aaron: AuthN levels includes session management - maybe we need to rename this.
        • Karl: This bucket is session lifecycle. The second bucket is "identity lifecycle". AuthN is too narrowly scoped.
        • Dick: Lumping MFA and logout together is challenging. Make MFA an A1 requirement. Make logout an A2 requirement. Is bucketing these issues into profiles premature right now?
        • Aaron: There's a level 1 (A1) becuase of the myriad of ways that people achieve SSO. Intent was standardize the most basic parts of SSO. Then add in MFA negotiation, logout, etc.
        • Aaron: At A1 some implementations will meet this bar. But most will have to do something to hit this low bar.
        • Dick: Agree with Pam, interested in how people feel about lumping MFA and logout together.
        • Aaron: A2 is "negotiated MFA"
        • Dick: A1 can you use single factor at the IdP? FAL2 allows this?
        • Tim: FAL doesn't specify the AAL level.
        • Dick: A1 is SSO, everyone does this.
        • Aaron: A1 standardizes the SSO mechanism. Buyers today can't be guaranteed that there is compatability between IdP and RPs
        • Karl: What about defining practices around DNS, certificate lifecycle, TLS, etc. We can put these into base profiles that will raise the bar over current state.
        • Karl: Do we need to unify levels between IdP and RP profiles? e.g. IdP can support negotiated MFA, but the RP may not use/support negotiated MFA.
        • Aaron: If an IdP isn't able to meet A2 requirements, a buyer knows that they won't get negotiated MFA. If an IdP supports A2 but the RP supports A1, then the buyer has to know that A1 is what is achievable.
        • Dean: IdP and RP may be at different levels. The outcome will be the highest level that both IdP and RP support.
        • Karl: trying to tease out what's required. "Can" should be converted to "must"?
        • Aaron: need to rewrite these to change the orientation from IdP to RP.
        • Pam: this should not be "levels". Shouldn't need MFA to get continuous access. Can we make these levels not based on different types of tools?
        • Aaron: If these levels are session lifecycle management, this is growing the ability to manage the lifecycle. The app could implement continuous authN without MFA, but it would not be A3.
        • Karl: Think about how we write the test cases.
        • Dean: Should we pull the orthogonal concerns into separate tracks?
        • Aaron: That adds complexity
        • Kenn: Can we remove the dependencies so that levels don't build on one another?
        • Aaron & Dean: Unsure how that would work.
        • Karl: Defining a control plane and what is mandatory. The levels are growing maturity.
    • Provisioning track
Clone this wiki locally