[Openid-specs-ipsie] 2025-04-22 meeting minutes

[Aaron Parecki]

# IPSIE WG Meeting Minutes
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

- Welcome and antitrust policy reminder www.openid.net/antitrust
- OpenID Contributor Agreement reminder
https://openid.net/intellectual-property
- Reminder about OpenID Slack
- AI policy for working group meetings
- Community Events
- Review profiles & issues
    - OpenID SL1 published on openid.net
        -
https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0-00.html
    - https://github.com/openid/ipsie/labels/sl1
    - SAML SL1
        - https://github.com/openid/ipsie/pull/65
- AOB


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250428/b6b9ea23/attachment.htm>