2025‐05‐06 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-05-06

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Mike Kiser (SailPoint)
  • Tom Clancy (MITRE)
  • Alex B Chalmers (self)
  • Brian Soby (AppOmni)
  • Shannon Roddy (Self/LBL)
  • Karl McGuinness (Self)
  • Dick Hardt (Hellō)
  • Kenn Chong (RSA)
  • Sean Miller (RSA)
  • Jon Bartlett (Zscaler)
  • Jeff Bounds (SailPoint)
  • Filip Skokan (Okta)
  • Gennady Shulman (Self)
  • Bjorn Hjelm (Yubico)
  • George Fletcher (Practical Identity LLC)
  • Nick Watson (Google)
  • Anatoly Podstrelov (Self/EDETEK)
  • Robin Martherus (Cisco)
  • Usha N (GitHub)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • SCIM PR update on the initial IL1 draft
    • Karl: We don't have a clear lifecycle for the users in SCIM, we should define a required lifecycle operation. What are the lifecycle operations we support and how does the profile support them?
    • Jen: This was one of our big blockers - having this lifecycle will help us move forward.
    • Karl: provided a proposed lifecycle in a comment on the PR
    • Dean recommends Karl sends email/slack regarding lifecycle, MikeK concurs and will help
  • FAL2 PR:
    • Dean describes the current state of work and asks for some help in reviewing these require
    • Karl: What about the trust agreements?
    • Dean: Not clear how to handle these
    • AlexC: Business agreements may be sufficient? Unclear how we call out the specific requirements as to what a trust agreement should be. Agrees with avoiding referencing US-centric security guidelines like 800-53. Dean suggests Alex writes this as a PR.
    • Karl: Thinking about how to handle these trust agreements without exploding scope
    • TomC: Gov't hasn't really put a lot of work into the FAL requirements, not as much as AAL. e.g. 800-217 PIV federation adds requirements to 800-63, for example. Many regulations evolving at the time, not a lot of historical data on FAL requirements implementation.
    • Dean: Need to clean up trust agreements work at some point, not the priority for getting to an interop
    • AlexC: Started reviewing the FAL doc vs SAML SL1 profile as well
    • Aaron: Focus on the interop requirements, not policy. Other items are out of scope.
    • Karl: Focus on privacy and identifiers.
    • Dean: Pairwise identifiers - in or out of scope. Unclear at this time.
    • TomC: DoD has a ICAM federation framework that is being used internally. This allows for interop across a broad set of external partners. Gov't federation use cases at the enterprise are focused on PIV, this is a template on top of the 800-63 requirements. Created a description of a PIV txn, but there are missing pieces still. Aligned with the federal gov't moving toward phishing resistant authN via federation. acr work is driving this information from IdP to RP.
  • Open Issues
    • #62 - update from Dick, nothing new to report.
      • Dick needs time to write up the doc for AB Connect
    • #69 - DPoP
      • ATs are part of SL1, but only to retrieve identity claims from userinfo endpoint. Currently sender constrained in the text.
      • Filip: Not requiring this in SL1 makes the step to SL2 harder, but DPoP does not add value in SL1
      • Aaron: Will we use ATs in higher levels that require DPoP?
      • Karl: Not OP side, RP side.
      • Aaron: Perhaps the OP never needs DPoP in this case.
      • Filip: If APIs are out of scope, no DPoP is fine.
      • Karl: If the OP side needs a new endpoint that may require DPoP.
      • NickW: Is it possible to write the spec so that DPoP is only required if you're using something beyond the userinfo endpoint
      • SeanM: Previous concern, DPoP as a requirement vs. mTLS
      • Filip: Through PAR + DPoP you can do authZ code binding (idea from Pieter Kasselman). RT for public clients is relevant.
      • Karl: Seems like an SL2/3 requirement to harden the system
      • Filip: RT in SL1?
      • Aaron: We don't say anything about RTs in SL1
      • Dean: Should we say something?
      • Karl: No offline scopes is how he recalls the discussion
      • Filip: If we have API access in other levels or use refresh tokens, need to revisit DPoP and authZ code binding
      • GeorgeF: If we don't allow RTs we disallow mobile clients.
        • Aaron: What do mobile clients get from RT with the OP?
        • George: getting tokens to talk to the backend.
        • Aaron: OP is the identity provider, not the RS that the mobile app is using. The OP has no resources beyodn the userinfo endpoint
        • George: I've deployed this pattern before. We are forcing a deployment mechanism where the mobile client RS must federate with the IdP AS. Need to understand the implications of this choice and constraints.
        • NickW: if the OP and RS are the same, why not allow ATs?
        • Aaron: Not describing a one party interaction (e.g. 1st party AS to 1st party app)
        • Nick: Can the OP issue ATs for userinfo and calendar, for example? This is forbidden as written
        • Aaron: Not in scope for IPSIE.
        • Karl: Things start looking like FAPI if we mix in Resource Servers. I just want to sign in a user and not worry about resource access. Separation of duties to meet minimum requirements to make this deployable and secure.
        • Nick: Maybe the intent should be clarified in the intro
        • ACTION ITEM Update intro to make this more clear.
        • Karl: future placeholder: We'll need to specify a third IPSIE category for API access that is beyond SLn and ILn. Need to formalize this as well for resource level access.
        • Aaron: If we know that a resource level access profile is coming later, it makes this easier to define without DPoP/RT.
        • ACTION ITEM Come back at a later date to create a resource level access profile. Dean will create an issue to track this.
        • Resolution of #69: Consensus is to drop DPoP and RT from SL1 in favor of a future resource level profile.
          • George: Question about RT and how it might be used for "session still valid" at the OP. Thinking about mobile clients and the mechanism to check whether the OP session is still valid. Do we rely on SSF or other mechanisms?
          • Karl: Suggests implicit requirement in SL1 for session revocation. Not using the RT pattern leads us down the path toward SSF/OP Commands for SL1 deployments. Wants to create the most simplistic deployment pattern.
          • GennadyS: RT not always used by mobile. Example of large form submissions that take many hours of work. Don't want users to reauthN in the middle of a form.
          • Aaron: We're not discussing the AT/RT for access to a resource. Nothing in IPSIE stops this for SPAs.
          • Gennady: Discussion about the network location fo the client and authZ decisions
          • Aaron: Profile doesn't have any enforcement, building blocks are there to allow others to build this functionality if needed.
          • George: Very few things support SSF/OPCommands at this time. turning on RT support is simpler for most deployments vs. adding new functionality. Agrees that we should focus on simplicity, questions value of RTs vs newer standards that are coming out.
          • Karl: SaaS doesn't always chain back to the OP, don't have the right machinery.
          • Aaron: We're trying to tighten the links between these components. We will discuss next week.
          • ACTION ITEM Aaron will open a new issue regarding the RT for discussion next week.