Thanks to visit codestin.com
Credit goes to github.com

Skip to content

2025‐11‐18

Jump to bottom
Aaron Parecki edited this page Nov 18, 2025 · 1 revision

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

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.

Clone this wiki locally