Skip to content

2025‐07‐15

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

IPSIE WG Meeting Minutes

Date: 2025-07-15

Attendees

  • Aaron Parecki (Okta)
  • Dean H. Saxe (independent)
  • Filip Skokan (Okta)
  • Kenn Chong (RSA)
  • Bjorn Hjelm (Yubico)
  • Mark Maguire (Aujas)
  • Dick Hardt (Hellō)
  • Bertrand Carlier

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Antitrust reminder/notewell
  • Dean will present an IPSIE update at the SCIM WG session at IETF 123
  • July 29 call is cancelled for IPSIE WG
  • Interop planning - please use the poll to indicate your availability for the interop
    • Kenn - When will we talk about what the interop requires?
    • Aaron - we'll demo interop between different implementations. Spec will be concrete enough to implement for IdP/RP. During the event all IdPs will try to interop with all RPs, checking specific functions.
    • Aaron - plan will be developed in the near future after the spec is ironed out.
    • Aaron - original plan was to do the interop @ Gartner IAM, but we no longer have this option, so we decided to align to a nearby time
    • Dick - why not January?
    • Aaron - Because of time off in December, this may not actually buy us more time/attendance.
    • Aaron will add January dates to the poll.
  • Call for Adoption for Common Requirements Profile
    • Aaron - this takes all the common requirements and moves them into a single doc. Call for adoption ends on the 23rd. Comments so far in support of adoption. Please add your comments to the thread.
  • Enterprise extensions work
    • Dick - Work continues in the AB Connect group, Dick is actively pushing PRs on the enterprise extensions. He will cross-post to the IPSIE list to ensure visibility/engagement
  • FAL2 Issues
    • Dean - Account Resolution PR
    • Dick - Still working on PR to describe how this is used in OP Commands. Will post to the list when done, discussion will happen in AB Connect group
    • Dean - Issue #89 requires the use of the auth_time claim. Dean made updates to OIDC SL1 draft to add the auth_time claim. The simple case of one amr and one auth_time is covered. The more complicated situation of multiple amr claimss has not yet been addressed. Would like to close this now that we've resolved this part. Closed.
    • Dean - Issue #96 multiple auth_time and amr claims. How to distinguish which auth_time is related to which amr? Would like to find someone who can carry this forward, to define a new optional claim.
    • Aaron - Who is relying on this information to be present?
    • Dean - No feedback on the call. TODO: Send an email to the list requesting feedback on who is running into this issue, and if not needed will table this for SL1 for now.
    • Mark - What are the scenarios where we see several amr claims?
    • Dean - At t0 authenticate the user with the primary authenticator. At t+5min the user is reauthenticated but only risk-based, then updated the amr to say "phr+rba" but it's unclear about whether the auth_time claim is updated, and if it was updated, does the new time apply to rba or phr? How much of a real world problem is this?
    • Bertrand - I don't want to have only the rba amr, I want to see both rba phr. I'm not sure if there's a real world need for the auth_time for each amr. The auth_time could apply to the whole set of amr values. A bank could require prompt=login if the auth_time is too old. It might only be needed in a closed system though. Fair to ask if this is a real world problem to have this level of detail.
    • Dean - Summarizing, you want to know when the primary authentication happened, but the time of the rba isn't necessarily important.
    • Bertrand - Yes in the scenarios I've seen. Some home grown systems have implemented their own claims to solve this.
    • Dean - Should IPSIE place further restrictions on the auth_time claim to define it as the time of the primary authentication.
    • Bertrand - Where in the spec is rba defined? It can mean a lot of things.
    • Aaron - Setting aside rba, what should happen with auth_time when there is two factors like password + phr
    • Dean - IPSIE could define rba as not affecting auth_time. Could start there, then see where people run in to further blockers.
    • Aaron - An end to end scenario is the RP asks for a phr authenticator and max_age, then needs to confirm that the request was met by the IdP. Need to make sure there is enough information in the response for the RP to make that determination.
    • Aaron - Concern with defining a new data structure is it will effectively be always optional, whereas we could reasonably strictly define when auth_time is updated.
    • Bertrand - I don't see a real world need for the full array of amr+auth_time
    • Mark - The purpose of SSO is to go from decentralized to centralized, one password policy at the SSO provider, like outsourcing the security to the IdP. So having the RP check the security is backwards. If an RP wants to ask "have you authenticated the user in the last hour" that's fine, but leave it up to the IdP to decide what that means.
    • Dean - I've had customers ask for the ability to determine the last time authentication occurred, but also to do that step-up and confirm that step-up occurred and the time of X. So they can ensure before doing some privileged action they can ensure the session is fresh.
    • Dick - People ask for all kinds of things, they don't always need it. The requirement is what Dean is saying, I might let someone do things without a lot of confidence, but when they do a critical thing they need higher confidence. I'm worried about the high fidelity signal in what's described here, seems too hard for many RPs to process.
    • Aaron - Also seen that scenario asked for. RP doesn't require a particular method initially, but then requires something specific on more sensitive actions.
    • Dean - TODO work on language
  • Issue #92 - prompt parameter
    • Dean - The prompt parameter has an intersection with max_age. prompt=login is roughly equivalent to max_age=0. Not sure the best thing to do here, but we need to remove the optionality around the prompt parameter.
    • Aaron - What is the current ambiguity?
    • Dean - prompt is optional
    • Aaron - Can an OP pass certification without supporting the prompt parameter?
    • Filip - The certification suite does require prompt is supported and defines behaviors for the values. The conformance profiles sometimes require more specific behavior on "SHOULD" options in the spec.
    • Dean - So IPSIE could define these behaviors as MUST
    • Filip - The new test suites have the ability to warn instead of fail, so now prompt=login could warn instead of fail on the behavior.
    • Dick - I'm lost on what the issue is
    • Dean - OIDC Core says "max_age=0 is equivalent to prompt=login". Do we need to define anything else around the prompt parameter to constrain its use to ensure all the OPs work the same way regarding the prompt parameter. Do we need to remove the SHOULDs?
    • Dick - So it's the "SHOULD" in prompt=login that's the problem
    • Aaron - Is it valid for an OP to receive prompt=login and silently redirect to the RP? The language in Core can be read two ways.
    • Dick - IPSIE could require OPs to support prompt=login
    • Kenn - If we support prompt=login we need to reauth the user, if authentication fails then reply with an error?
    • Dean - yes.
Clone this wiki locally