2025‐05‐20 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-05-20

Attendees

  • Aaron Parecki (Okta)
  • Karl McGuinness (Self)
  • Dick Hardt (Hellō)
  • Kenn Chong (RSA)
  • Vatsal Gupta(Apple)
  • Bjorn Hjelm (Yubico)
  • Nick Watson (Google)
  • Jon Bartlett (Zscaler)
  • Jeff Bounds (SailPoint)
  • Filip Skokan (Okta)
  • Jen Schreiber (Workday)
  • Travis Tripp (HPE)

Agenda

Notetaker: Dick Hardt

Minutes

Reminder on IPR and Slack

Events

Dick: AuthCon recap - oversold the event, well attended. Part of API Days. Presented "Less Oopsie with IPSIE". Got good questions, had questions about OAuth. Filed a couple issues on OAuth 2.1. Feedback on IPSIE resonated with people. Call to action was to give feedback in the working group.

Aaron: SaaStr recap - target audience for IPSIE. Many of the attendees were early in their enterprise readiness. Many people had Sign in with Slack as they had a Slack integration. Worthwhile to talk about enterprise readiness at the conference in the future.

Karl: any discussion on MCP?

Aaron: MCP was a hot topic. MCP discussions bring up enterprise security topics that need to be done to have a base for MCP. Resource topics that are bucketed will be relevant.

Travis: Has there been a movement towards A2A?

Aaron: MCP is an OAuth problem and different than A2A, and A2A has deferred authorization to be out of scope.

Travis: How does all this related to IPSIE?

Aaron: IPSIE sets base line requirements for the tools for login. Future discussions on resource profiles in IPSIE. Short term getting a good security baseline.

Karl: Also longer term how IPSIE fits in with other identity efforts

OP Enterprise Extensions

https://dickhardt.github.io/enterprise-extensions/openid-connect-enterprise-extensions.html

Dick: Posted initial draft of enterprise extensions to Connect WG mailing list. Will try to do call for adoption on the next meeting. In IPSIE we have session expiry requirement in the ID token, this draft defines it. Also describes third-party initiated login (e.g. enterprise dashboard) providing the RP with the right information like tenant claim.

Karl: Not yet defined authorization claims for groups and roles. They are ambiguous today in ID tokens causing interop challenges. The need is not yet defined in IPSIE, but we are aware of the gap. Waiting on IPSIE to drive the need.

Travis: Do any of these need to come in to IPSIE? like tenant

Dick: The requirement is partly from IPSIE. Having this specified in Connect enables IPSIE to profile it

Travis: I'm curious on the tenant aspect. I didn't know we had defined a tenant attribute.

Dick: The tenant attribute is in OP Commands, but not yet specified in Connect. Microsoft and Google have their own ad-hoc claim. Let's be crisp on what a tenant is.

Karl: It will be needed in account linking rules when we get to that part.

Travis: I'll read through this.

Dick: "tenant" is an opaque identifier defined at the identity provider.

Travis: will be a challenge when it's a third party integration. Our customers can have many tenants, but there is one primary tenant they associate their domain.

Dick: Not defined as a domain for security reasons of domains expiring. I talked with Dirk at Google, so they could use the new tenant claim for a unique ID instead of hd. The tenant claim is intended to be unique.

Nick: I think this would be useful.

Discussion on full page redirects

https://github.com/openid/ipsie/issues/74

Karl: How does the RP check in with the IdP about access after intitial SSO? Is value to check back with the IdP with a refresh token? Can we allow DPoP for refresh rather than require confidential clients? OP Commands introduced errors that provide state of the account when a refresh is requested so that the RP has context on why the refresh failed for example the account no longer exists at the IdP.

discussion that I participated in and lost track

Karl & Aaron: At end of session, RP does a redirect with prompt=none or does a refresh of the id token.

Karl: opportunity for RP to check in on a regular basis and on path to a continuous evaluation outcome. Refresh flow provides a much better user experience for long lived app access such as email.

Karl: RP can register a refresh grant type. The OP could then take that information to know that an RP can refresh on a more frequent basis and would then set a shorter session lifetime as the refresh is happening in the back channel and not requiring a redirect flow.

Aaron: We should include an explanation in security considerations

Karl: are we requiring DPoP on for public clients?

Dick: overlap with OpenID Connect Key Binding using front channel dpop parameters.

Aaron: DPoP during refresh means you don't require rotating refresh tokens.