[Openid-specs-ipsie] FAL2 - max_age and auth_time for OIDC SL1
Simon Canning
simon.canning at octopus.com
Tue Jun 17 23:08:55 UTC 2025
In the RP implementations I've been involved in, I've always considered the
prompt parameter to drive the desired UX rather than enforcing any security
policy/requirement. While max_age=0 is equivalent to prompt=login, the
prompt parameter can be multi-valued; for that reason, I'd lean towards
using max_age=0. If prompt=login support were mandated at the OP, you'd
likely want to define what that means for permutations of other prompts
including login.
-Simon
On Wed, Jun 18, 2025 at 8:48 AM Dean H. Saxe via Openid-specs-ipsie <
openid-specs-ipsie at lists.openid.net> wrote:
> Thanks Aaron and Dima.
>
>
>
> If we make the auth_time claim mandatory, how would an RP signal that the
> claim is not fresh enough and the user needs reauthentication for this
> RP? The RP could then set max_age=0 or prompt=login, but that would lead
> to interop inconsistency with both parameters being optional.
>
> If we require both max_age and auth_time, we eliminate any optionality,
> allow both the OP and RP to set the maximum authentication age before
> reauthentication, and provide a consistent mechanism for an RP to request a
> fresh authentication (max_age=0).
>
>
>
> Another alternative is to mandate support for prompt=login at the OP,
> leaving it an optional param for the RP.
>
>
>
> Thoughts?
>
> -dhs
>
>
>
> On Tue, 17 Jun 2025 22:18:05 GMT Aaron Parecki wrote:
>
> > Re MUSTs I made an assumption that the spec should take care of many
> different use cases, not just NIST FAL2 and "I don't trust my OP" subset.
>
>
>
> We are using FAL2 as a shortcut for a bunch of security features we know
> people will want. But this process of going through the FAL2 requirements
> list is to make the decisions about which of these we want to actually be
> in scope for IPSIE. We don't *need* to meet all the FAL2 requirements (and
> we've already decided that some are out of scope).
>
>
>
>
> IPSIE is not intended to cover many different use cases, it is intended to
> cover the specific use cases of integrating apps with an enterprise IdP.
>
>
>
>
> > So you are saying that every time RP will ask OP to enforce it but also
> not fully trusting OP will double check and enforce it too? Just in case...
>
>
>
>
> Sort of yes, but also: currently the two methods an RP has to ask for the
> auth_time claim are the max_age parameter or Extended Claims, and I don't
> think we want to bring in Extended Claims.
>
>
>
>
> I suppose another option here is to just make the auth_time claim
> mandatory, since it is optional in OIDC today, and then just not address
> the max_age question at all.
>
>
>
>
>
>
>
> On Tue, Jun 17, 2025 at 3:12 PM Dima Postnikov <dima at postnikov.net> wrote:
>
>
> Yes, it's about who is responsible for enforcement.
>
>
>
>
> So you are saying that every time RP will ask OP to enforce it but also
> not fully trusting OP will double check and enforce it too? Just in case...
>
>
>
>
> Re MUSTs I made an assumption that the spec should take care of many
> different use cases, not just NIST FAL2 and "I don't trust my OP" subset.
>
> It's just a personal opinion, I will leave it up to you...
>
>
>
>
>
>
>
>
>
>
> On Wed, Jun 18, 2025 at 7:58 AM Aaron Parecki <aaron at parecki.com> wrote:
>
>
> The RP asking the OP to enforce the max_age *is* the RP asking to enforce
> its own policy. It then also gets the auth_time claim to confirm the policy
> it intended was met.
>
>
>
>
> Plus, IPSIE *is* the profile where these would be a MUST. We are trying to
> avoid adding optionality within an IPSIE level.
>
>
>
>
>
>
>
>
>
>
> On Tue, Jun 17, 2025 at 2:48 PM Dima Postnikov via Openid-specs-ipsie <
> openid-specs-ipsie at lists.openid.net> wrote:
>
>
> Hi Dean,
>
>
>
>
> Without too much background on this issue, I feel like we are mixing 2
> approaches:
>
> 1) RP asking OP to enforce max_age policy
>
> 2) RP asking for raw auth_time to enforce its own policy.
>
>
>
>
> I feel like both are not always necessary?
>
>
>
>
> There might be a profile of the spec that has these MUSTs but not a core
> spec?
>
>
>
>
> Regards,
>
> Dima
>
>
>
>
> On Wed, Jun 18, 2025 at 7:16 AM Dean H. Saxe via Openid-specs-ipsie <
> openid-specs-ipsie at lists.openid.net> wrote:
>
>
> TL;DR; - NIST FAL2 requires the RP to be able to specify a maximum age
> since last authentication in its request to the OP. FAL2 also requires the
> OP to communicate the timestamp of the last authentication event to the RP.
> These controls exist to enable the OP and RP to each enforce their own
> business rules around authentication time and need to be considered for
> IPSIE.
>
>
>
> On today’s IPSIE call we discussed the two issues (#89, #90) and a related
> PR which attempt to address these concerns. Following a good discussion
> (located here until the minutes are migrated to the IPSIE Wiki), we agreed
> to take this discussion to the mailing list. In a nutshell, the discussion
> comes down to whether the OP or RP should control whether the
> authentication event has occurred recently enough to be acceptable.
>
>
>
> After listening to the discussion this morning, my perspective is that
> both the OP and RP have an interest in ensuring recency of authentication.
>
> -
>
> The OP’s interest is to ensure that authentication has occurred with
> sufficient recency to allow another federated authentication event to be
> processed. The OP is, absent a signal from the RP, unaware of the RP’s
> recency requirements. Enterprises may choose to enforce this rule centrally
> at the OP.
> -
>
> The RPs interest is in protecting the users and the RP’s brand. The RP
> may not trust that the IdP has been configured in a sufficiently secure
> manner and wants to enforce authentication controls to protect itself.
>
>
>
> In order to ensure both the OP and RP’s concerns are represented, controls
> can be established, and the controls do not reduce interop, I have pushed a
> PR to codify the requirements for the parameter and claim. The PR makes
> three changes:
>
>
>
> -
>
> First, the following lines have been added as a requirement for OPs
> issuing ID tokens:
> -
>
> MUST contain theauth_timeclaim to describe when end user
> authentication last occurred (see Note 4);
> -
>
> Note 4: This claim is required to satisfy the requirements in
> Section 4.7 of [NIST.FAL].
> -
>
> Second, the OpenID providers authorization code flow has been updated
> with the following requirements:
> -
>
> MUST support the max_ageparameter with a values representing the
> maximum number of seconds allowable since the user was authenticated by the
> OP. If the elapsed time since authentication is less than this value, the
> OP MAY choose to actively reauthenticate the user. If the elapsed time
> since authentication is greater than this value, the OP MUST actively
> reauthenticate the user.
> -
>
> Third, the RP must send the max_age as a parameter:
> -
>
> MUST use the max_age parameter in the authentication request to
> specify the maximum allowable authentication age to the OP in seconds. The
> max_age parameter value MAY be determined based upon the business
> rules of the RP.
>
>
>
> I believe that this balances the concerns of both OPs and RPs, does not
> introduce any interop concerns, and allows both the RP and OP an
> opportunity to control the recency of an authentication event.
>
>
>
> I appreciate any additional comments or feedback on the issues and PR
> ahead of next week’s call. Ideally we’ll be able to come to rough
> consensus ahead of the call, allowing the WG to move forward and close
> these issues soon.
>
>
>
> Thanks,
>
> -dhs
>
>
>
> --
>
> Dean H. Saxe
>
> dean at thesax.es
>
> --
> Openid-specs-ipsie mailing list
> Openid-specs-ipsie at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ipsie
>
>
> --
> Openid-specs-ipsie mailing list
> Openid-specs-ipsie at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ipsie
>
>
> --
> Openid-specs-ipsie mailing list
> Openid-specs-ipsie at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ipsie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250618/64eec5bd/attachment-0001.htm>
More information about the Openid-specs-ipsie
mailing list