Skip to content

2025‐09‐16

Jump to bottom
Aaron Parecki edited this page Sep 17, 2025 · 1 revision

IPSIE WG Meeting Minutes

Date: 2025-09-16

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (self)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • Bjorn Hjelm (Yubico)
  • Dick Hardt (Hellō)
  • George Fletcher (Practical Identity LLC)
  • Buster Doney (self)
  • Jon Bartlett (Zscaler)

Agenda

Notetaker: Dean H. Saxe / Aaron Parecki

Notes:

Interop event planning

  • Kenn: Generally like the idea, but January might be too early to achieve all SL2+SL3
  • Dean: Ok to demonstrate only some portions, and not asking to develop anything new before January
  • Dick: Seems somewhat vague and handwavey. Would want to demonstrate confidence in the security of SSO, not just the capability. Interop is not super interesting, compliance is. To have compliance tests, this WG needs to figure out what the spec is. Compliance test for SL1 would be potentially more interesting.
  • Karl: Example - take a popular app like Salesforce, you can write bridges and adapters to make it work for the use case, the point of IPSIE is to make those use cases standard and not require custom code.
  • Karl: Question for Aaron to follow up on, Okta has an internal deployment of Salesforce and solved some of these capabilities. Can Okta IT document best practices around this.
  • Aaron: I can track that down, it might include more than what we currently documented in SL2/SL3, but want to include other perspectives
  • Karl: If someone can document what was done, we can pull what is relevant to the levels currently.
  • Dick: People don't understand how challenging it is to operate at a security level today, so by documenting everything you had to do, then it becomes interesting to show you get that at one of the IPSIE levels. Correct?
  • Karl: That would be an impactful message.
  • Buster: We were evaluating cloud IDPs, we looked at Okta, they used an OIDC SDK to integrate with Okta to see scope and custom claims. How do we envision people building individually or using more standardized code?
  • Dean: Depends on the RP, some RPs will use existing libraries, others will build their own.
  • Karl: The reason why what you did worked is Okta did conformance testing for OIDC, so you can take an SDK that implements a profile and it works with Okta out of the box. The end state is we would want SDKs for IPSIE capabilities.
  • Buster: So the ask is each RP comes in January with their own development?
  • Karl: The way it was proposed wasn't about implementing specs, it was about demonstrating the capability some other way like custom webhooks or integration code. That demonstrates the high cost/maintenance that we are trying to reduce with IPSIE.
  • Buster: I was curious about the level of effort for RPs to participate in January
  • Dean: Will depend on what capabilities exist today with RPs. If you look at capabilities beyond SL1, there are more differences in implementations and custom code.
  • Dean: Should we proceed with demonstrating SL1 at the interop?
  • Kenn: Leaning towards supporting SL1 demo in January
  • Sean: I'm struggling with showing what we achieved by doing this at just SL1
  • Dean: That's the problem with having downscoped SL1 to meet the current capabilities of IDPs/RPs
  • Dean: Is there value in demonstrating SL2/SL3 capabilities using existing things today in January? No comments.
  • Karl: We haven't talked about IL1. You can get more security outcomes with apps with IL1.
  • Aaron: We haven't previously talked about it because there wasn't a draft. The adoption call closes next week. Want to address Dick's email from before the call about account deactivation.
  • Sean: I thought Dean's proposal made sense, but not sure it is realistic for January. Agree that conformance testing is the more exciting demonstration.
  • Dick: The conformance testing is the end goal, the interop didn't seem as interesting.
  • Dick: Should we rename Identity Lifecycle to Account Lifecycle?
  • Dean: Want to be careful that the discussion around this doesn't devolve
  • George: We need to be clear about terms and what they mean. For me account can include multiple identities. But maybe in an enterprise it is 1:1 with human.
  • Karl: I've found RPs speak more in terms of "accounts" but IDPs more "identities".
  • Aaron: Since we want to optimize for the larger RP account that's an argument for "accounts".
  • Karl: There is an identity lifecycle that contains account lifecycles within it.
  • Dean: Suggest to write it as a PR on the levels document.
  • Dick: My other email, a large portion of the value of doing account lifecycles is deprovisioning. There's many ways to provision (upload a spreadsheet, manual, etc), but not deprovisioning in time is a security risk. Maybe we can lower the bar for "AL1" to just be deprovisioning. The first level would be it can deprovision, we would move provisioning into the second level.
  • Dean: Interesting propsal, I like the security focus.
  • Dick: The current IL1 is both provisioning and deprovisioning. Trying to lower the bar so there is value in meeting IL1/AL1 in just deprovisioning.
  • Karl: The challenge with provisioning is every application has different licenses and business processes. A lot of apps they wouldn't enable automatic provisioning because of the business process challenges. Deprovisioning avoids those concerns.
  • Jon: Maybe we can make it clearer in the profile documents that these meet specific IPSIE levels.
  • Aaron: ...summarizing...
  • Dean: We may need to also revisit the timing of the event
Clone this wiki locally