[Openid-specs-ipsie] 2025-11-18 IPSIE WG Meeting Minutes

Tue Nov 18 18:31:42 UTC 2025

Hi all, thanks for joining the call today.

As a quick summary, we confirmed Dick as the new co-chair of the working
group, thanks!

We will not be meeting next week or over the holidays, so the remaining
calls for the year are Dec 2, 9, and 16.

The OpenID Foundation staff would like us to capture our goals for 2026
along with any asks for foundation resources (conformance suite
development, etc), so let's plan on discussing this on the next call.
https://docs.google.com/presentation/d/1j9S6U3IGyySL51_ndMc8mjmZH8b492jxMDQdceW1W-c/edit

Minutes from today's call are below.

---

# IPSIE WG Meeting Minutes
Date: 2025-11-18

## Attendees

* Aaron Parecki (Okta)
* Dick Hardt
* Pablo Valarezo
* Karl McGuinness
* Jon Bartlett (Zscaler)
* Travis Tripp (HPE)

## Agenda

- Welcome and antitrust policy reminder https://openid.net/policies/
- Notes & Recording Policy
https://openid.net/wp-content/uploads/2025/09/OIDF_Notes-Recordings-Policy_Final_2025-09-11.pdf
- OpenID Contributor Agreement reminder
https://openid.net/intellectual-property
- Reminder about OpenID Slack
- Chairs update
    - Dean stepped down
    - Dick volunteered to take his place, pending WG confirmation
- Community Events
    - Past: Reports back from Authenticate / IIW / IETF 124
- Upcoming call schedule
    - No calls: Nov 25, Dec 23, Dec 30, Jan 6
- Updates on work done since the last call
- How IPSIE can mitigate attacks: defining a shared attacker model
    - Attacks (phishing, token theft)
    - Mitigations
        - Single sign-on
        - Provisioning and deprovisioning
        - Continuous session security
        - Strong auditability (logging and alerting)
        - TBD?
- AOB

## Notes

* Dick confirmed as co-chair
* SCIM session at IETF had 2 proposals for managing AI agents
* SAML Update
    * Karl met with Shannon to talk about SAML
    * SAML2int - under Kantara. 3 specs that drive interop in SAML today
    * https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
    * https://kantarainitiative.github.io/SAMLprofiles/fedinterop.html
    *
https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html
    * What would the overlap between SAML2int and OpenID Connect?
    * We could take a stance that IPSIE SL1 requires SAML metadata, but
many SPs don't support that today
    * Working group question - where do we want to push the industry forward
    * Karl: SAML metadata is additive, net new layer to add to SP. This
would be new work to be IPSIE compliant. Without SAML metadata, no key
rollover possible.
    * Karl: Three changes from SAML2int: No SAML logout requirement, no
assertion encryption to align with OIDC SL1, signed authn request for
public clients. Most other things in SAML2int aligned.
    * Karl: Proposing path forward: SL1 built on SAML2int with the changes
to align with our SL1 profile. This may require some changes from SPs, but
mostly are around metadata requirements.
    * Further notes:
https://github.com/mcguinness/ipsie/blob/saml-sl1/saml-sl1.md
    * Jon: Why not require single logout in SL2?
    * Karl: We can discuss that for SL2, trying to align on SL1 now. Lots
of issues with single logout, could folks be compliant using other ways?
    * Dick: Generally agree with the idea of leveraging existing work from
this community. Does this cover other things we talked about like DNSSEC
and TLS?
    * Karl: TLS yes, DNSSEC was not. Section 15 has a table showing the
delta between IPSIE profile and SAML2int
https://github.com/mcguinness/ipsie/blob/saml-sl1/saml-sl1.md#15-saml2int-delta-table-normative-deltas
    * Karl: Microsoft also has a conformance profile:
https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol
no dealbreakers here, so Azure is already mostly there
    * Karl: Question for the group, is it worth pursuing this as a path
forward?
    * Dick: Is this widely deployed?
    * Karl: I don't know of any SAML2int RPs that aren't R&E
    * Dick: Does the SAML community view this as a relevant spec?
    * Karl: Shannon says the community views this as gold standard of what
SAML should be
    * Dick: Would this be the same base for SL2 and 3?
    * Karl: Looking at this as additive. Do we view things like SAML
encryption as aligned with SL2? If SL2 and 3 require confidential clients
that would align.
    * Dick: Echoing back, there's a number of things we'd relax for SL1,
some things not relaxed for SL2, and maybe additional mechanisms needed for
SL2 and SL3.
    * Aaron: I assume Shannon is aligned?
    * Karl: Shannon would like SL3 to be full SAML2int
    * Jon: You mentioned another standard to align with?
    * Karl: The oasis doc talks about identifier normalization. Looks like
OIDC. Cleaner than the SAML name identifier used today.
    * Karl: Hearing no objections with the current plan
    * Dick: Any concerns?
    * Jon: I like it, minimal investment
    * Dick: Would also be great to capture the rationale for these
requirements.
* Aaron: Shared attacker model
    * Karl: There's value on clearly defining the security outcomes.
    * Aaron: Two main threats I see are token theft and OAuth phishing
    * Karl: Might be useful to separate session cookie theft from access
token theft. We've mostly been talking about sessions so far, so "token
theft" may not cover these.
    * Travis: These examples have been the topic of many of my
conversations over the last month.
    * Aaron: So instead of demoing SSO, we demo how we recover from token
theft. More broadly we anchor the discussions around the scenarios
ratherthan individual protocols.
    * Travis: Karl can you expand on the cookie statement again?
    * Karl: "token theft" is broad, you can consider a session cookie to be
a token. We've been dealing with session management and session assurance
since cookies are bearer tokens. Because DBSC isn't widely deployed we need
additional mechanisms to signal back and forth. Would be useful to call out
session assurance goals.
    * Dick: These are high level attacks, lots of things can help against
phishing.
    * Aaron: I was thinking about this as the current IPSIE specs in scope
can help fight these
    * Dick: I was thinking more from the CISO perspective if we go there
and say we are helping solve phishing they might be thinking of much more
broad things. The talks I gave about IPSIE was to practitioners, they love
the idea of interoperability and knowing what functionality they get with
IPSIE.
    * Karl: The enterprise today has their app catalog with varying
capabilities, there are lots of extensions of specs. How do you align a
roadmap of what apps should be adding to their product, and how the WG
defines conformance around aspects of the spec. I didn't see it as going to
tackle phishing resistance, but that's why we spend time talking about
acr/amr so you have context.
    * Jon: Agree with Karl, identifying the gaps that are missing. We
should be trying to make it more difficult to steal tokens.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20251118/639a2839/attachment.htm>