Skip to content

2025‐08‐12

Jump to bottom
Aaron Parecki edited this page Aug 13, 2025 · 2 revisions

IPSIE WG Meeting Minutes

Date: 2025-08-12

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (self)
  • Dick Hardt (Hellō)
  • Kenn Chong (RSA)
  • Sean Miller (RSA)
  • Alex B Chalmers (self)
  • Jeff Bounds (SailPoint)
  • Bjorn Hjelm (Yubico)
  • George Fletcher (Practical Identity LLC)
  • Karl McGuinness (Self)
  • Travis Tripp (HPE)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Note changes to IIW date
  • Interop - January 29, 2026 in San Franciso @ Okta HQ
    • Goal for interop: SL1 profile testing with implementations by IdP/RP.
    • Concrete milestone for WG progress, demonstrates actual implementation
    • Pairwise testing between RP/IdP, validate against the test matrix
    • See the SSF interop data for an example of what the outcomes are (need link!)
    • Aaron to work with OIDF to publish a blog post re: IPSIE Interop
    • We will support remote AND in person participation to encourage attendance
    • Specific timing TBD, start ~9 AM PST, end TBD.
    • End of September we want to have a draft published that we plan on testing against.
  • Published the common requirements profile https://github.com/openid/ipsie-common-requirements-profile
    • Dean closed a number of outstanding issues that were resolved by publication of this draft
    • Aaron will try to push an OIDC SL1 profile update soon which removes any duplicate language
  • Connect WG status update by Dick
  • FAL2 issues
    • Dean: RP-initiated federation issue #100 has a long discussion. Can someone propose language to discuss. This doesn't impact OIDC SL1, only SAML SL1. We can put this off until after we publish OIDC SL1.
    • Issue #93 - subject identifier global uniqueness. issue #101 dean will get done in the next week or so. This is likely important to the SL1 interop.
    • Issue #95 - assertion presentation via a proxy. Bertrand offered to write some text. Dean: suggest this is not critical to interop at this time.
    • Kenn: example of IdP chaining. Is this like signing in to a Microsoft account with a Google account?
    • Dean: example from Amazon. When Whole Foods was acquired, WF has its own IdP and RPs, Amazon corporate has its own. A common solution was to federate from Amazon's internal IdP to a Whole Foods IdP. Chaining OIDC or SAML assertion.
    • Dick: The thing in the middle acts as an RP up to the IdP, and an IdP to its RP. So wouldn't each connection need to be IPSIE compliant in order for the whole thing to be?
    • Dean: Yes, we haven't defined what data are we propagating down the chain, what values are retained? Do we allow protocol translation - SAML to OIDC.
    • Dick: Whatever we define in SAML SL1, then we need an equivalent of amr in both OIDC and SAML, so if we translate between then they use the same value, so it seems straightforward. I don't understand the challenge.
    • Dean: If you wrote that down, I think we would have a nearly complete answer when it's the same protocol on both hops, but still a challenge when there's a protocol translation. Shannon indicated there is some work from Microsoft about translation.
    • Dick: Figuring out how to do the protocol translation is important.
    • Dean: Because we won't have a SAML profile for the interop event we don't need to deal with that right now. However we should resolve it for OIDC.
    • Dick: My concern is we might need to change SL1 for OIDC to have a consistent functionality between OIDC and SAML. We might need to revise OIDC SL1 if we put off SAML until after the interop event.
    • Dean: The biggest thing I can see now is IdP vs RP initiated flows, there might be others.
    • Dean: Let's identify gaps in SAML
    • Karl: IdP chaining has many different deployment models. Depending on the model will influence the flow of claims. Acquisition is one. Broker as a silent operator. Only in a few of these do you want the RP to have the context of the root IdP. In others you want to obfuscate that there is an upstream IdP. We need to scope down the scenario we are trying to spec.
    • Karl: Use case, since auth_time claim is a single value, which one wins? If the upstream IdP validated a single factor, but the next one validates a different, what is auth_time? The RP might or might not want full context.
    • Dean: Can you document these patterns in issue 97?
    • Karl: What do we do about the interop event? I would hope that these are net new behaviors for deployments that are chained. So when there are multiple revisions of the SL1 spec, I would expect more behaviors to be defined, but not necessarily for the single RP-IdP.
    • Aaron:
    • Karl: From a deployment perspective, there are significant interop challenges doing reauth in a multiparty deployment. They are MFA gaps.
    • Aaron: We should focus on just the single RP-IdP link now, because that's a net improvement over today, and will ensure more of the auth claims are available at each hop.
    • Dick: I can see challenges when someone along the chain is doing additional authentication. But if it's IPSIE SL1 between each chain, as long as we move the data that's part of SL1 then it should be compliant.
    • Dean: Let's write some proposed language.
  • Dean: SCIM IL1 Profile
    • Dean: There is a proposed IL1 profile with a lot of discussion. I'd like to get some folks to review this asking yourselves the question do we think this is ready for working group adoption.
    • Karl: I think it's ready for adoption.
    • Jeff: I can review.
  • Dean: Next week, unless we have any significant feedback, we can start the call for adoption.
  • Aaron - Interop event, start thinking about what you want to be tested in the interop and if there are any open issues that must be addressed.
  • Karl: in OP Commands, the identity resolution is related. The RP can tell the OP what its identifiers are for the accounts it has, the OP can pass one of the identifiers to the RP in a sign-in assertion, so the RP can use its own local identifiers, then it doesn't need to use the sub claim. Useful in a brownfield deployment with existing identifiers. There's a proposal in there how to do it. You can do it today with SCIM, but the missing piece is specifying the local identifier in the assertion, which is a potential candidate for Enterprise Extensions. When should account resolution rely on this value vs the sub claim? A lot of the attacks in RPs today are around account resolution. This path forward allows any IdP to take over an account that exists in the RP today. There's a potential collision issue if an RP uses two IdPs. The question is how do we want to tie accounts to an IdP, when should an RP know to use iss+sub or iss+sub+tenant or local identifier?
  • Dean: Will add a note to issue #101 that it doesn't deal with brownfield. Then let's sync on the language in enterprise extensions.
Clone this wiki locally