2025‐04‐29 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-04-29

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Jon Bartlett (Zscaler)
  • Filip Skokan (Okta)
  • Mark Maguire (Aujas Cybersecurity)
  • Dick Hardt (Hellō)
  • Travis Tripp (HPE)
  • Keiko Itakura(Okta)
  • Hirsch Singhal (GitHub)
  • Karl McGuinness (Self)
  • Tim Cappalli (Okta)
  • Usha N (GitHub)
  • Wes Dunnington (Ping)
  • Shannon Roddy (Self/LBL)
  • Alex B Chalmers (Self)
  • Bjorn Hjelm (Yubico)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Antitrust & Contributor Agreement reminder
  • Dick added AuthCon.io to the list of upcoming events
    • Dick is speaking about IPSIE
  • JPMC Open letter discussion link
    • relevant to IPSIE
    • call to action for SaaS providers to increase their security when integrating with enterprise companies
    • OIDF is considering a response to this doc - relevance of IPSIE, AuthZen, AB Connect WGs
  • SAML recap
    • Want to make progress on OIDC profile, prioritizing this work
    • we aren't spending meeting time on SAML at this time
    • it is not clear that we'll be able to meet the same security profile for SAML, so it's unclear if we call it SL1 or something else
    • Dick: Agrees with focus on OIDC right now. We won't get industry interest without SAML.
      • Raises concerns that we need to support SAML at SL1 to bring the industry along.
      • Dick: If SAML can't meet SL1, what do we do? Without the same features as OIDC at SL1, it's not the same thing.
      • Aaron: Can we develop a SAML profile with an upgrade path to move to OIDC?
      • Dick is concerned about the practicality of this idea
      • Mark M. - need clarity. What does SAML need to do to meet SL1? If it meets the requirements is it as secure as OIDC at SL1?
      • Can we meet FAL2 with SAML?
      • Dean: First pass, yes, but I need to discuss with SAML experts.
      • Tom Clancy (in chat): The main "gap" for FAL2 tailored for PIV transactions is injection protection using backend flow--need to specific artifact binding-type SAML profile.
      • Dick: Can we agree that the high bar for SAML is SL1? Wants to ensure SAML can meet at least SL1 so that we have a profile at SL1.
      • Shannon: My IdP can meet FAL2 based on a quick review
      • Aaron: Need more concrete patterns to show how a SAML impl is configured to meet SL1
      • Dick: Tighten up SAML as much as possible w/o adding new features should be the goal.
      • Karl: How do we make this easier to sell to PMs in SaaS companies who already invested in SAML and don't use OIDC. Thinks FAL2 compliance is a huge lift.
      • Aaron: So the SAML profile lays out what it means to be secure, can identify the cost to upgrade vs moving to OIDC.
      • Aaron: Is anyone willing to spend time to document what the implementation changes needed are to meet FAL2?
      • Alex C: Will review SAML vs FAL2 once Dean writes the FAL2 issue. Shannon will assist.
      • tom C in chat: NIST SP 800-217fpd includes tailoring of FAL 2: SP 800-217, Guidelines for Personal Identity Verification (PIV) Federation | CSRC
  • Issues
    • Aaron reviewed 61 & 63, confirmed text was updated in SL1 OIDC draft, closed issues
    • 68 - ISO vs IETF keywords
      • original idea for ISO was to use their keywords in FAPI
      • ISO has adopted OIDF docs using IETF keywords
      • Aaron has a PR with the keywords changed to ISO
      • Dean can review and accept if there are no disagreements. None heard, Dean will review.
      • s/shall/MUST/ for IETF keyword alignment
    • 64 - discussed last week, keeping the SHOULD for DNSSEC
      • draft did not include idtoken validation
      • Aaron added a PR
      • (Dean: This is required at FAL2, iirc)
      • Mark confirms this looks good.
      • Dean can review and merge, no disagreement heard on the call
      • this will allow us to close 64 once merged
    • 60 & 62 - related issues that are going to AB/Connect
      • we agreed previously about moving these to AB/Connect
      • Dick was going to follow up
      • Dick: in AB/Connect looking for info on how to define tenancy
        • Dick has writing these claims in his queue.
        • He will bring this to AB/Connect for adoption
        • Filip: Tenant going to AB/Connect, session lifetime doesn't seem like it needs to go there.
        • Aaron: If IPSIE needs to add features to a spec, we should first try to do that in the spec's original WG if the feature is not specific to IPSIE.
        • Filip: This will be misused by RPs, forcing prolonged lifetime for the idtoken...
        • Aaron: Not discussing idtoken, but it's an interesting point. Is this an IPSIE specific feature?
        • Karl: general session management in OIDC is where this likely belongs. Related to SSF. IPSIE defines constraints on how lifetime is implemented, OIDC is incomplete with session management. This brings clarity.
        • Dick: discussion around idtoken additions belong in the WG handling idtokens (e.g. ab/connect). Doing the work in AB/connect gets a broader set of eyes on the changes. Proposed spec is "OIDC Enterprise Extensions". Will leave this open to add other additions for SLn as needed
      • Aaron: We'll keep this as a standing item to check in on.
    • 67 - acr claim
      • currently required in SL1 sec 3.3.1
      • what do we do to describe the acr when a string does not yet exist to describe simple authN?
      • Dean: chair hat off - don't bind to AAL2, figure out terminology for "MFA" that we can use. Don't require phishing resistance, even if we know it's a good requirement.
      • Karl: there is value in providing both acr and amr, would still be able to indicate what methods were used even if they don't meet a context class. Do we fall back to the amr problem where it's subject to interpretation? phr is a clear level of outcome, everything else is subject.
      • Aaron: if an RP requires MFA, they can know it has been met. SL2 must repect the 'amr' request. Aaron suggests SL1 requires both 'acr' and 'amr'.
      • Karl: this tracks with my memory.
      • Aaron/Dean: We need to capture this change in an issue and change the SL1 profile. Need to determine what happens if no context class is met (as in this issue).
      • Aaron: idtokens from IdP must ALWAYS have amr & acr.
      • Karl: only amr in the idtoken
      • Filip: if a claim is empty/null it should be missing instead of empty. May not be allowed in JWT.
      • Aaron: What does OIDC say about when acr is included? Is that sufficient for IPSIE?
      • Aaron will write a PR.
  • AOB
    • Dean: SCIM - need to get to work on IL1. Mark is working on a rough draft with Jen. Need more use cases defined, clarified for a minimum bar
    • MarkM is working on a draft with Jen, will share soon.