2025‐03‐25 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-03-25

Attendees

  • Dean H. Saxe (Beyond Identity)
  • Jon Bartlett (Zscaler)
  • George Fletcher (Practical Identity LLC)
  • Shannon Roddy (Self/LBNL)
  • Mark Maguire (Aujas Cybersecurity)
  • Frederico Valente (Workday)
  • Blake Lewis (okta)
  • Sean Miller (RSA)
  • Aboobacker MK (GitLab)
  • Keiko Itakura(Okta)
  • Tom Clancy (MITRE)
  • Jen Schreiber (Workday)
  • Dick Hardt (Hellō)
  • Pat Buffolino (Paramount)
  • Robin Martherus (Cisco)
  • Karl McGuinness (Self)
  • Travis Tripp (HPE)

Agenda

Notetakers: Jen Schreiber, Dean Saxe, Tom Clancy

Minutes

  • IPSIE at IETF in SCIM working group
    • SCIM could be used in IL controls
    • Dean to act as bridge between SCIM wg and OIDF/IPSIE
  • IL1 - SCIM - Jen & Mark Maguire to work on an initial profile
    • Karl suggests to check out FastFed
  • SL1 issues
    • Dick: no updates from AB connect
    • Issue #60: how to let idp dictate RP session lifetime in OIDC
      • Karl: many use cases for this but no clear way with dynamic access management to do this. do we want to go back to AB and define a generic method?
      • Dean: we are talking about directives from the OP that the RP MUST follow/take action from. this is different from SSF.
      • Dick: likes focus on session on session timeout. proposes to do so in AB wg
      • George: been talking to SSF authors, the idea that a signal is not a directive may become gray. we shouldn't discount using SSF for this purpose, it could be leveraged.
      • Dean: what is the intersection here? ssf? directives?
      • Karl and George want to tackle this in a generic way by starting with the action itself (like session timeout)
      • Dick: if we want to specify the session timeout, then it should be specified in the token
      • Dean: worries about using SSF for SL1 because of effort to implement.
      • Consensus: Include a claim in the id token (go back to ab connect wg) to define session length for SL1.
      • Consensus: Roll changes for IPSIE into one document for ab conect wg. put time limit on this so it doesnt delay anything for IPSIE
    • Issue #61: Confidential clients. Do we want to require confidential clients? SL1? SL2?
    • Issue #63: Access Tokens
      • Karl
        • ATs are not necessary for SSO
        • if we focus on SSO, can we profile to reduce the requirements to PKCE, TLS, etc. using a public client at SL1.
        • Risk is balanced by not having long-lived access
        • Aim is for max deployability, confidential clients adds overhead that may not be supportable at SL1
      • Dick - aligned with Karl's thoughts
      • George
        • in an enterprise B2B scenario, what's the expectation if they don't want to support public clients at SL1? Are SL1 confidential clients possible?
        • Is public vs. private orthogonal to SLx?
      • Travis
        • Supports what Karl said above
        • Confidential clients don't work in all of his customer situations
        • Looking at different session types - UI, CLI, etc
        • Which concept are we discussing?
      • dean - Sounds liek a web context
      • Dick - responding to George
        • what if someone wants a confidential client? Have to be prescriptive
        • SL1 requires disabling confidential clients?
      • Karl - end customer doesn't define IdP/RP as the security boundary
        • Travis was talking about the CLI app as the client/session (e.g. github app)
        • app level session context is first party, created by the IdP session
        • Customer is interested in the outcomes
        • What if an app needs more than what the IPSIE SLx profile offers?
          • e.g. needs access tokens? Do I need DPoP?
        • Real world use cases may not map cleanly to SLx, so how do we handle these?
          • raise the bar for everything?
          • Downside is a lot of overhead for every client
      • Dean - how do we leave the door open to SL1 with confidential clients?
      • Karl
        • IdP requirements are MUST - public client
        • IdP MUST support private client at SL1
        • push more requirements on IdP and less on RPs
      • George
        • I think of the enterprise as the primary driver for requirements
        • Is it valuable over the long term for an RP to say I'm good enough as a public client?
        • Are we looking at this from IdP, RP, or enterprise perspective?
        • If enterprises are only ever only going to start at SL2, what is the value of SL1?
      • Dean
        • IdPs--what do you think?
      • Karl
        • There's value in Sign-in with Google for phishing-resistance -- there's a lot of security stuff outside the IdP boundary that provides security value
      • Dean
        • We seem to think we can include public clients at SL1 and confidential clients at SL2
        • For access tokens, we seem to think they are also SL2 and above... (Dick agrees)
        • "At SL1, IdPs MUST support public clients; if you are issuing access tokens, you must require SL2"
      • George
        • I agree with the risk lens for access. Which is why I’m not sure public vs confidential clients is even relevant to IPSIE
        • We seem to be saying we won't leverage FAPI for SL1
        • If there's no requirement for sender-constrained access tokens, public or confidential doesn't matter
        • Like Karl said "if public client is accessing _, the IDP must do _"
      • Dean
        • Consideration: what if you want to require SL1 but your business requires confidential client
      • George
        • How the client got registered will determine whether it's confidential or public
        • It's fundamental and determines the rest of the requirements
        • You can specify the requirement for client authentication and the rest is determined
      • Karl
        • IPSIE profile needs to follow through on the combinations of optionality by supporting a la carte
        • The thread modeling become complex -- you may as well just adopt FAPI
        • The ROI for a la carte is slim
      • George
        • FAPI 2 for xL2, not at xL1
      • Karl
        • capture this clear decision
      • Dean
        • Need to make this more clear at SL1
        • We don't need to make the decision for xL1, today
        • Dick agrees -- different for APIs not specific to SL1