[Openid-specs-ipsie] FAL2 - max_age and auth_time for OIDC SL1

[Dima Postnikov]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250618/21f9a117/attachment.htm>