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

Aaron Parecki aaron at parecki.com
Tue Jun 17 22:17:51 UTC 2025 

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

More information about the Openid-specs-ipsie mailing list