Skip to content

2025‐07‐08

Jump to bottom
Aaron Parecki edited this page Jul 9, 2025 · 1 revision

IPSIE WG Meeting Minutes

Date: 2025-07-08

Attendees

  • Dean H. Saxe (self)
  • Aaron Parecki (Okta)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • Shannon Roddy (self/LBL)
  • Alex B Chalmers (self)
  • Mark Maguire (Aujas Cybersecurity)
  • Bertrand Carlier (Wavestone)
  • George Fletcher (Practical Identity LLC)
  • Jeff Bounds (SailPoint)
  • Bjorn Hjelm (Yubico)
  • Travis Tripp (HPE)

Agenda

Notetaker: Dean / Aaron

Minutes

  • Antitrust policy reminder & Contributor Agreement
  • SL1 Profile interop
    • working on a December date, Gartner does not have capacity for IPSIE this year
    • Poll for interop date options - https://whenavailable.com/invite/bN6AdzU027LQPjeLQ4F7
      • If these dates do not work for you for whatever reason, please reach out to Aaron and Dean
    • Okta to host in the SF office, half to full day event
    • Will enable remote presentation
    • Goal is to settle a date by the end of July.
    • Aaron to email a summary of the discussion to the mailing list and slack
  • Dick was not in attendance, no WG status on the enterprise extensions

OIDC SL1 intro

  • Dean: PR #3 on SL1 profile, updates intro to clarify use of OIDC. Discussed last week and made a couple further changes. Are we comfortable with the changes now?
  • Mark: "require" isn't necessarily as clear as "mandate"
  • Alex: Similar concern. Maybe the last sentence about refresh token/dpop is even required
  • Dean: I want to be clear that refresh tokens are optional, maybe we need to be clear about when they are optional.
  • Alex: That might be better broken up into the body of the document rather than the introduction
  • Sean: I like keeping it in the intro but I like the idea of using the word "optional" and fleshing out the use cases of when it would be used.
  • Aaron: I think we can come up with a quick edit. "As a result... are optional"
  • Sean: 👍 and we can expand this in the body
  • Mark: 👍
  • Dean: Aaron can merge when ready. Sean and Alex if you want to add more clarifying text in the doc please do.

Sidecar doc

  • Dean: Sidecar doc for common requirements. I updated it based on feedback so far. We would like to see whether this is at a point it can be adopted by the working group. Doesn't mean it's perfect, but it's far enough along to adopt and then collectively make updates to it. That will also allow us to go to the SCIM/OIDC/SAML profiles and pull out all the common requirements since they are captured here. Looking for questions/feedback on this.
  • Dean: Aaron are you comfortable starting a call for adoption?
  • Aaron: Yes

FAL2 issues

  • Dean: FAL2 requires the IdP to issue an auth_time claim. It also requires the ability for the RP to specify the requested auth time. For OIDC, this has resulted in another issue about the prompt parameter, which is equivalent to auth_time=0. This resulted in another issue that the auth_time claim doesn't necessarily correspond to the amr claims. For example auth_time=0 with phrh, at time +5 min we have a reauth based on risk which doesn't require hardware. We then have multiple amr claims (phrh, rba), so what does the auth_time claim refer to? What I'd like to do is separate out the requirements for max_age and auth_time and prompt, then separately come back to the multiple auth_time/amr claim question.
  • Dean: PR #4 adds a few statements to the OIDC SL1 profile. "MUST contain the auth_time claim". This doesn't address which event this refers to. Also added a note that this is related to NIST FAL. Also adds that the OP "MUST support max_age parameter" but not requiring the RP to send.
  • Mark: Taking a step back, the value of IPSIE is when the CISO buys a new SaaS app it will be compliant. So not making the RP validate max_age undermines the value. Why not have the RP be required?
  • Dean: I think that's backwards. max_age is RP request to the OP. What is returned in the ID token is the auth_time claim. So the RP MAY send the max_age claim "this is the longest time I want to allow".
  • Mark: I think a burden on the RP would be more helpful. If I'm a CISO i'm going to trust ping/entra/okta/etc. What I don't trust is the 1000 SaaS apps I'm using. So if they are IPSIE SL1 I want to know they are doing the validation.
  • George: What I'm hearing is we shouldn't require the RP to send a max_age, but if the RP does then they need to validate that the returned auth_time is valid for the max_age they sent.
  • Mark: At minimum I agree. But I would be ok requiring the RP to use max_age.
  • George: There's a bunch of UX implications of leveraging max_age. This hits both the RP and OP. I could see requiring the RP to support the capability of max_age, but you don't want the app to always send max_age, you only want it in certain contexts.
  • Dean: What I see is max_age being used by the RP saying to the IdP that I only want to issue the ID token if the max_age is less than X. It's a risk mitigation step for the RP.
  • Aaron: I think it's the session_expiry claim that gets Mark the control needed
  • Mark: Good with me.
  • Travis: The way you put it seems much easier for an RP to implement where it delegates the policy enforcement to the OP. Will we have SL2 that is more restrictive?
  • Dean: I don't recall conversations that got this deep in SL2 about things like the RP must send max_age.
  • Dean: Do we think this PR #4 is sufficient to merge this?
  • George: I'm good with this.
  • Aaron: Will merge now
  • Dean: Next: auth_time * amr mapping. We need an extension to the core spec that allows mapping auth_times to amrs so we know what happened at what time. A first attempt is in this comment. Does this make sense? Is there a better formatting? Who can carry this forward to write this as an extension for the AB Connect group?
  • George: Meta question. The initial ID token was auth_time=X and amr=phrh. Then the RP requests max_age, and gets a new ID token and new auth_time. Why not make the amr valid for only the auth_time in the ID token. What you lose is the overall authentication context. But I'm not sure we even have a way to request the full session context over the lifetime of the session. That's a much bigger conceptual object than auth_time and amr.
  • Dean: My concern is say I log in to the IDP at T0, I go to RP1 at T+5, then at T+10 I go to RP2. Between initial login and T+10 a risk auth happened. Would the ID token have only rba or would it have a claim that I initially used a phrh and then did rba?
  • George: The semantic object you're looking for is the session authentication context history. OIDC has no concept of an authentication context session history. I'm a bit worried about getting a little of that by creating arrays of auth_time and amrs if there are other elements that would be desired. It makes me wonder if we should go back to AB connect and ask if we should have an extension that enables the RP to request a full session context history which becomes a new object. Then auth_time and amr would be specific to the most recent auth event.
  • Dean: I don't think we're too far in how this should look.
  • Bertrand: I have the same concern as George, are we trying to invent something that should be done in AB Connect? I think we should have a simple auth_time claim for compatibility. What should the order of the amrs be?
  • Dean: Yes we will not define this here, the intent is if we need this kind of thing we would build the extension in the AB COnnect group. But good point about having the auth_time claim for backwards compatibility.
  • TODO: Dean to pull https://github.com/openid/ipsie-openid-sl1/pull/4#issuecomment-3029279185 into a new issue
  • TODO: Verify the ability/need for IdPs to add this to their products @aaronpk. Make sure this is an actual, concrete issue that needs to be solved
  • George: If you think about auth requirements it's pretty critical for making authorization requirements. If it's not in the ID token then how does your PDP make a decision? Understaing the full authentication session context history is pretty critical from a dynamic perspective.
  • Dean: I agree, as we see more movement towards continuous authentication, we'll need this data to be much more clear to make good decisions.

prompt parameter

issue #92

  • Dean: I'm not sure what to do with prompt in IPSIE to avoid having multiple ways to request reauth.
  • George: I agree that historically we treated max_age=0 to be the same as prompt=login but I'm wondering whether that is the right thing to do. prompt=login should require that the user sees some challenge. The question is whether the user MUST/MAY/SHOULD/MUST NOT see a challenge.
  • Aaron: So you're saying we should specifically define the behavior of the combination of max_age and prompt?
  • George: Right, either we need to disallow prompt, or define the behaviors. I know there are some people who would want to use max_age=0 with no prompt to mean if the IdP can silently update the authentication status then that's ok. But there are also cases where the RP wants the user to be prompted. We need to put out of scope "is this really George". We can allow for a mechanism to require the user engage in the user interface some way.
  • Dean: George would you mind commeting on this issue or push a PR?
  • George: Can you tag me in the issue?
  • Dean: 👍

RP initiated federation

  • Dean: At FAL2, RP-initiated federation is required, and IDP-initiated is not allowed.
  • Kenn: Can someone explain RP-initiated vs IDP
  • Dean: It's the difference of where the transaction starts. Shannon can you elaborate on the risks of IDP-initiated?
  • Shannon: There's a good article about why you shouldn't do IDP-initiated. I'll see if I can find the article.
  • Alex: IDP-initiated is a holdover from SAML 1.1. The problem is you're sending a SAML response out in the wild without being asked for an auth request.
  • Shannon: It's also known as "unsolicited". In other words the RP didn't solicit a sign-in request so it has no way to know if it's valid.
  • Aaron: Want to call out the UX experience that causes people to think they need IDP-initiated, creating a portal at the IDP where you can click an app to launch it. That is also possible with RP-initiated, it just requires the IDP to tell the RP to start an auth request. Described in OIDC as "Third party login" https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin
  • Shannon: There are still some SaaS apps that don't support RP-initiated at all.
Clone this wiki locally