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

Tue Jun 17 22:48:02 UTC 2025

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ipsie/attachments/20250617/501c69c5/attachment-0001.htm>