2025‐04‐01 - openid/ipsie GitHub Wiki

IPSIE WG Meeting Minutes

Date: 2025-04-01

Attendees

  • Dean H. Saxe (Beyond Identity)
  • Aaron Parecki (Okta)
  • Mark Maguire (Aujas Cybersecurity)
  • Dick Hardt (Hellō)
  • Shannon Roddy (LBNL/Self)
  • George Fletcher (Practical Identity LLC)
  • Frederico Valente (Workday)
  • Filip Skokan (Okta)
  • Karl McGuinness (Self)
  • Brock Allen (Duende)
  • Jen Schreiber (Workday)
  • Tom Clancy (MITRE)
  • JD Pawar (Workday)
  • Kenn Chong (RSA)
  • Matt Topper (UberEther)
  • Robin Martherus (Cisco)
  • Bjorn Hjelm (Yubico)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Antitrust reminder
  • Slack reminder
  • IIW next week - no meeting
    • Unconference, no planned sessions. Aaron / Dean will likely propose an IPSIE general info session. Others welcome to propose sessions
  • Aaron:
    • Two docs - OpenID Connect and SAML Profiles have been drafted
    • Next step - call for adoption on one/both
    • Current status is independent submissions, need 2 week adoption call on the mailing list. Adoption does not mean they are complete, rather a starting point for further discussion
    • Dick: Followed up on acess tokens and no confidential clients, can you pull those from the draft before a call for adoption?
    • Aaron: Yes, still following up on discussion
    • Dean: we reached consensus on no access tokens, no confidential clients at SL1
    • George: My understanding as well. What's left up in the air is can I have a confidential client at SL1?
    • Aaron: clarifying question: is the intent to allow a confidential client?
    • Dean: Conclusion was to use public clients, confidential clients not banned
    • Aaron: chair hat off, this allows optionality that is not necessarily in the best interest of the profile
    • Dick: Landed last time that IdP can support both, but RP does not need to support confidential clients
    • George: If we're only thinking of the RP, this makes sense. But from an enterprise perspective, this does not make sense. If I want confidential clients, do I have to be SL2 across the board? Does this limit the set of RPs I can use?
    • Filip: Public clients + no access tokens - do you have a particular flow in mind?
    • Dick: No AT at SL1 was where we landed on the past few calls.
    • Filip: Compliance doesn't specify anything about ATs at SL1?
    • Dick: Yes, not profiled at SL1
    • Filip: SL1 -> SL2 transition with different flows?
    • Karl: Slightly different recollection: scopes limited to identity claims, can't request scopes that would grant access to other resources. Code flow, PKCE, identity claims, no AT.
    • Filip: Claims must appear in the assertion?
    • Karl: Or user info
    • Aaron: So there is an AT, but only allowed to get access to user info?
    • Karl: yes. Same lifetime on both tokens.
    • Aaron: Makes sense to me
    • Karl: No AT for RS
    • Filip: Need to be explicit where the identity claims are obtained. Prescribe whether all identity claims are in identity token or user info or both. Prefers disabling user info.
    • Dick: Some clients are implemented to call user info instead of the idtoken
    • Filip: some clients won't call user info. Claims must be the same across user info/idtoken.
    • Aaron: If we want the profile to match Karl's description, we need language about the AT. Need to add text to constrain the AT and what it can access.
    • Dean: I think we can do a call for adoption with the current doc, push PRs after adoption
    • Dick: Less friction in change now, vs. change after adoption. A quick set of changes is recommended. Specifically focus on the AT changes.
    • Aaron: Will do a quick update to resolve this.
    • Dick: JWT for client auth needs to be resolved.
    • Aaron: are we OK with having both public and confidential clients at SL1? Which combos of allowed/supported on IdP/RP are required?
    • Dick: Karl on the last call said you can do more than what's specified at SL1 (e.g. confidential client)
    • Aaron: Can we make this better than the unspecifed state in OIDC?
    • Dick: Unsure what the value of client authN is when using PKCE
    • Aaron: Assurance that the client is the correct piece of software, struggling to find examples in an enterprise. In SaaS apps, they inherently have their own resources and will issue ATs to access these resources.
    • Dick: Managing a secret is a lift for an RP
    • Aaron: Not the argument I'm hearing which is we need to support public clients because we don't care about the integrity of the software
    • George: If I'm an enterprise I want to know that the Slack mobile is the correct app (for example). Cases where there are public clients because of low risk to the enterprise. Vast majority of enterprise services are a virtual perimeter of the enterprise. In that context, we want everything to be a confidential client. There has to be a way for an enterprise to require a confidential client.
    • Dick: confidential clients must either be in an SLx or not. Example of OPKSSH - this is the cloudflare OpenID SSH flow - requires a public client because it's running on the CLI.
    • Aaron: Public clients still need to be registered
    • Karl: We need to think about SaaS and internal apps as well. SaaS apps have an onboarding flow for clients, onboarding confidential clients requires shared secrets which creates challenges, and they are not terribly secure. A switch to private key JWT is a big lift for most.
    • Aaron: Onboard with no client secrets - would like to skip straight to private key JWT.
    • Karl: Not at SL1
    • Aaron: too much of a lift for SL1, may be reasonable at SL2. What can we do to provide some assurance of app identity at SL1? Registration of redirect URL, disallow localhost or custom schemes.
    • Dick: OPKSSH has no redirect URL, uses localhost
    • George: If keys are ephemeral and there is no callback, how do you distinguish?
    • Aaron: there's a client ID
    • George: If everything is ephemeral, spoofing is trivial
    • Karl: ID assertion bound to a pub key, present to a server for authN
    • Sean: Pattern in the enterprise where AWS ALBs are used for redirect URIs (e.g. Atlanssian). Agrees with binding to DNS, but using ALB load balancers for that.
    • Aaron: Registering redirect URLs is not possible?
    • Sean: Not DNS bound. ALB is whatever the name is .regionname.aws.
    • Karl: can have a static registered callback URL.
    • Sean: Instance based.
    • Aaron: In OpenID, there is a client ID that is registered at the IdP with 1..N URIs listed that do not change
    • Filip: moving away from confidential clients we lose the ability to not register redirect URIs.
    • Aaron: Trade off, enterprises need some level of assurance. Prefers DNS-based URI scheme, no wildcards. No native apps are showing up and doing SSO.
    • Karl/Aaron: Except internal native apps.
    • Karl: There's a path forward with DNS based registration. Don't get rid of DNS options and jump straight to private key JWT.
    • Aaron: Not trying to capture the way the world works today
    • Dick/Karl: both agree that private key JWT is a large lift vs. many deployments today
    • Dick: SL1 brings other assurance controls
    • Karl: DNS security in the browser is how WebAuthn works. proves origin to limit theft of assertions.
    • Aaron: trying to capture - SL1 requires support of public clients by IdP, clients don't have a requirement to be public/confidential. Have to require redirect URLs, disallow localhost/custom schemes. SL2 would then require private key jwt, drop the redirect URLs.
    • Karl: Sounds right. Question about whether the localhost ban is an issue
    • Dean: Sounds right to me.
    • Filip: Are we still requiring public clients to use the PAR endpoint?
    • Karl: Goes back to FAPI discussion. Unclear why we would want to require PAR. You could use PAR...
    • Filip: as we move to SL2 need to handle public keys, update to use PAR to authN the client before a redirect.
    • Karl: Is that a hard requirement? PAR should be about security. Is there a constraint we need around authN the request?
    • Filip: convenience of not having to register redirect URL, we need to discuss this as we get to SL2.
    • George: Should we collect enterprise deployment requirements to help us? Do we have enough requirements today? If we do SL1 but it has low adoption, is it valuable?
    • Dean: Good group of people here, do we think SL1 is sufficient for adoption?
    • Dick: Wants to make SL1 easy and accessible
    • Karl: So much shadow IT, we want to make this adoptable, usable, baselines the long tail of apps. Most key enterprise apps should get higher than SL1. Baselining secure SSO for an acceptable level of constraints. Every step above drives security ROI.
    • George: At some point we need to provide clear guidance for RPs to target SLx from the start. This will drive the value for the enterprise.
    • Dick: That's pretty enterprise specific - two different companies use the same app differently. Benefit is to give people levels to achieve specific security goals.
    • Karl: Slack is a good example, maybe starts at SL1, but as it becomes a critical tool it needs to achieve SL2/3.
    • Dick: Differential pricing possible at SLx
    • George: What if RPs hear that SL1 is sufficient and enterprises want something more? How do we build the guidance to encourage building beyond SL1? This builds a sufficient ecosystem for growth/differentiation.
    • Dick: Do we need enterprise guidance telling them what to ask for based upon their needs? Clear levels remove friction vs. bespoke security controls, drives simplified audit.
    • George: Concern: Enterprise says, I need SL2, but the RP says, "SL1 is good enough", won't meet the needs.
    • Dick: today enterprises present sec. requirements which makes it hard to sell
    • Aaron: Has a path forward to update the OIDC SL1 proposal then do call for adoption on the mailing list. Make sure you respond on the mailing list.