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

Skip to content

2025‐12‐16

Jump to bottom
Aaron Parecki edited this page Dec 16, 2025 · 1 revision

IPSIE WG Meeting Minutes

Date: 2025-12-16

Attendees

  • Aaron Parecki (Okta)
  • Dick Hardt (Hellō)
  • Jeff Reich
  • Karl McGuinness
  • George Fletcher
  • JD Pawar
  • Bertrand Carlier
  • Bjorn Hjelm
  • Kenn Chong
  • Pablo Valarezo

Agenda

Notes

Notetaker: Aaron Parecki

Recent Events

  • API Days Paris - Dick presented topics including IPSIE
  • Gartner IAM - Jeff and Kenn attended. Lots of AI. No mention of IPSIE at Gartner.

Upcoming Events

  • IETF Shenzen in March

Discussion

  • Jeff: IPSIE isn't known until I bring it up

Work Streams

  • Aaron: Presented work streams broken up: IPSIE Core, SL*, AL*. Core at IPSIE @ OIDF, OpenID at OIDF, SAML at Kantara, SCIM at IETF.
  • Dick: Had a conversation with Jen, excited about driving it at IETF
  • Karl: Forgot Shared Signals. on SCIM, would it be a BCP?
  • Aaron: Shared signals would cover the "session state changes"
  • George: The tricky part will be coordination. If we need to change what's in levels, the change will ripple across a lot of places and may not be easy to pick up. We have to be conscious about even minor changes of the definition could have significant impacts.
  • George: How do we coordinate the conversations? Co-chairs playing the go-betweens could work, but IPR is going to be slightly different. Levels should stay in OIDF.
  • Dick: Yes, the IPSIE core document that describes the levels would stay in OIDF
  • Bertrand: Wondering about SCIM at IETF?
  • Aaron: SCIM charter includes revising core SCIM RFCs. We still need to actually publish the work we have done in OIDF as the SCIM AL1 profile regardless of what else happens.
  • Karl: Where would conformance testing live?
  • Aaron: OIDF develops self-certification tools and resources. Kantara can cover the conformance.
  • Karl: How do we move things forward quickly with SCIM? How do we prevent things from operating all on their own timelines across different standards bodies?
  • Dick: Things can move fast in IETF, some parts are faster than OIDF processes.
  • Dick: Next steps, how do we kick off next year? Why don't we dive into one of the topics we haven't discussed much as the focus for January.
  • Jeff: We need some way for more socialization
  • Dick: I was going to email people who care about this directly.
  • George: What are the critical capabilities within the level that make it useful? We had level 1 and were working towards interop, but collectively decided that there wasn't enough to show in level 1. We still need to have the conversations around what is the meaningful set of profiles and who they are targeted at. Session termination isn't in SL1, so if we haven't finished SL1 is it ok to talk about 2?
  • Dick: I have a different view around why we didn't do interop. Interop doesn't provide value because we already know how to make OpenID things talk to OpenID things. Conformance testing showing whether it does the right thing when someone does the wrong thing is where the value is. To move things along, we can dive into the details around session termination on including exactly what it means. To finish SL1, we haven't done enough in SAML to get them to line up.
  • George: I would like to see something like who is SL1/2/3 targeted at? That would help us when we run into something and wonder which level it should go into. Also helps figure out who we message the levels to. Messaging SL1 to security-conscious enterprise won't work, they will care about SL2 and 3. But lots of small businesses would benefit from SL1.
  • Dick: I don't think it's so much of "who" as it is "if you're doing X and Y then you should use SL*".
  • Karl: There's a general agreemeng that we need to do a better job of external communication. Let's define the progressive set of capabilities than SSO. Once we have the list of defined capabilities we can get feedback on whether we should push the capabilities up or down the levels. Let's spec out revocation, then debate whether it should be in level SL1 or 2.
  • Bertrand: Both points are valid. We need to understand the value that each level brings and who that is targeting. We have many audiences for this work.
  • Dick: To build on what Karl was saying, let's build something and share it and get feedback
  • Bertrand: We need to make sure every level is relevant
  • Karl: The question for the market is does the market acutally want revocation in level SL1, I'd like to get to that conversation. We just haven't made enough progress on even getting SSO.
  • Dick: Does everyone think session revocation is a good place to start in January?
  • George: I like the way Karl is framing it around sets of capabilities. When we were talking about SSO, the way we had written it before was if you get an access token and use it then you're not compliant, which is a problem. So if we treat them as capabilities it will help us.
  • Dick: Any concerns with the plans for spinning up Kantara working group and moving SCIM work to IETF? Nope. We have a plan, we can adjust the plan as we go. We have a plan for what to work on when we come back in January.
  • Aaron: We'll resume Jan 13
  • Dick: We'll kick off with session termination in January. Anyone can invite people to the session termination discussions in January.

Clone this wiki locally