Skip to content

2025‐04‐22

Jump to bottom
Aaron Parecki edited this page Apr 25, 2025 · 1 revision

Date: 2025-04-22

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (Beyond Identity)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • Mike Kiser (SailPoint)
  • Shannon Roddy (self/lbl)
  • Jon Bartlett (Zscaler)
  • Mark Maguire (Aujas Cybersecurity)
  • Frederico Valente (Workday)
  • Bjorn Hjelm (Yubico)
  • Robin Martherus (Cisco)
  • Travis Tripp (HPE)
  • Indrajith Premanath (GitHub)
  • Usha N (GitHub)
  • George Fletcher (Practical Identity LLC)
  • Konstantin Teslenko (RSA)
  • Qinglan Gao (RSA)
  • Filip Skokan (Okta)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Antitrust reminder
  • If your company has signed a contributor agreement, every person who joins the company needs to have an updated agreement for the company.
  • Recordings
    • the meetings are recorded for archival purposes for the foundation, they are not publicly available
    • AI features not enabled in our zoom tenant
    • meeting minutes are the official record, they should capture substantive discussion/decisions
    • Human-derived notes >> AI notes for accuracy and capturing discussions/decisions
    • Minute takers should capture major points/decisions and any outcomes of the discussions.
    • No policy at the foundation around using AI note takers (e.g. a personal otter.ai bot). Some WGs have made a decision to block these tools, kick them out of meetings.
    • IPSIE WG has not made a decision on this yet. We will revisit this later in the call to make a decision.
  • Aaron: Call for adoption for OpenID Connect SL1 was successful, draft 00 has been published.

    • https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0-00.html

    • Dean: I'd like to close out the SAML discussion to figure where we go next. Recollection from the call is that there are open questions whether implementers will meet the SL1 bar, matching the security outcomes for OpenID Connect SL1, or not.

    • Shannon: As much parity as possible is a goal. But not all aspects can be aligned.

    • Dean: (chair hat off) if we cannot match the security outcomes across both SAML/OIDC at SL1, how do we represent this?

    • Shannon: Parity across two different paradigms is difficult.

    • Aaron: diff between specs working differently and the security outcomes we achieve

    • George: Agrees with Aaron. If we can't match the capabilities, then we need a separate SAML profile with different security properties. May not be viable to have a common profile for SAML/OIDC.

    • Dean: chair hat off - Security outcomes must be matched to call both SAML and OIDC "SL1"

    • Shannon: SAML certs are different than OIDC. Placing the same requirements on SAML and OIDC doesn't make good sense.

    • George: If we can show SAML/OIDC reach equivalent security outcomes, even with different rotation schedules, that would be the goal.

    • Kenn: Do we want to exclude SAML from SL1 due to differences? Many RP apps are SAML, so exclusion is not ideal. Can we influence the SAML specs to bring them to parity on a security capability?

    • Travis: Thinks we should define everything w/ OIDC and then come back with a SAML implementation and identify what the differences are from OIDC. Concerned that trying to get to a least common denominator will make this standard difficult to execute.

    • Aaron: (chair hat off) If implementation changes are required in SAML, it's unlikely to happen. If there are configurable changes to SAML, that's more likely to be accomplished.

    • Shannon: There are SAML impls that can do everything discussed last week, but they are in limited deployment

    • Aaron: Path forward -> interop goal at SL1 for December. Possible path forward: We can focus on OIDC now and keep SAML working in the background. Revisit SAML in a few months.

    • Dean: Chair hat off: I think this is a good path forward, but let's be clear this is not a decision to abandon SAML, rather a decision to focus on getting OIDC to the interop.

    • Thumbs up from Sean, Travis, George. No opinions against.

    • Decision Tackle SL1 for OIDC specifically to get to the interop. Work on SAML in the background. Return to the SAML discussion in a few months.

    • George: SAML experts should call out any OIDC conflicts early in the process to ensure we can identify them and capture them

    • Filip: What if we showcase interop and realize we can't deliver a compatible SAML profile?

    • Aaron: Describe a SAML profile with a different naming scheme (e.g. not SL1) or make SAML meet the same requirements, even if it's impractical to achieve.

    • Shannon: No objection with proceeding on OIDC now. Confusion about matching capabilities across SAML/OIDC. R&E space is looking at how to change their expression of MFA usage in SAML. Updates to the standard for AuthN context. We need to cross polinate.

==========

  • SL1 issues: https://github.com/openid/ipsie/labels/sl1

    • #63 appears complete, we will return ATs but they are only used at the IdP to retrieve identity claims, not to manage resources. (user info endpoint)
    • #59 PAR pushed to SL2, removed SL1 tag
    • #60 Session lifetime in OIDC, this work is being run by Dick in the AB connect group along with tenancy, etc. We need to track this work in the AB Connect group.
      • We should request status updates for the IPSIE meetings from Dick. We'll keep #60 on the agenda to check in.
      • Session lifetime is unrelated to tenancy, however, they are linked in Github. this is unclear at the moment, we may need to open a new issue to clarify what's happening with #60 and #62.
    • #61 - We landed on an answer a few weeks ago. Aaron will follow up and make sure the changes are in the 00 draft.
    • #64 - Dean (chair hat off) - do not make DNSSEC a MUST.
      • Mark - there is no RP verification of the claims in the id token
      • Aaron - do we intend for the RP to validate or are the claims FYI only? Draft includes a list of claims. 3.3.2 RP section does not clarify what must be validated. We can address that.
      • Mark: Can close this issue with respect to DNSSEC, Aaron will take an action on the claims validation and write a PR.

  • Aaron: Uppercase vs. lowercase use of keywords (shall, shall not, must, etc.) change was made in FAPI likey for ISO. Should we use the ISO or IETF versions?

    • Filip: We didn't change this in FAPI because of ISO. Core spec still uses uppercase normative language.
    • George: Touch base with Mark Haine to get guidance from OIDF
    • Aaron will follow up with Mark/OIDF on context for keywords

  • Dean: We need to make a decision on whether to allow/disallow personal AI notetakers

    • George: Not possible to exclude discussions that you don't want in the notes. Proposed to ban them. These bots lack nuance.
    • Dean: chair hat off - I think banning them is the proper choice.
    • Mark: I don't think we should allow them. We might need to revisit in the future as they get better.
    • Aaron: As chair, I hear support for actively excluding the tools and no counter arguments.
    • DECISION Send a note to the mailing list that personal AI bots are not allowed on IPSIE WG calls. We will actively remove any AI bots from IPSIE WG calls. Meeting notes for the WG will be taken by a human. DEAN to email list.
    • Shannon: We may want a rare exception.
    • Aaron: Discussing exceptions as they come up is fine.
Clone this wiki locally