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

[Aaron Parecki]

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