FAL2 - Section 4.7 requires the use of the auth_time claim

[deansaxe]

Section 4.7 in SP800-63C Rev4 draft states:

The IdP SHALL communicate to the RP any information the IdP has regarding the time of the subscriber’s latest authentication event at the IdP, and the RP MAY use this information in making authorization and access decisions.

IPSIE SL1 should make the auth_time claim required in the id token to resolve this gap.

[teddyber]

Should IPSIE specify how this behaves in case of IdP chaining? I'm thinking more specifically of a setup like:

• app1 federated to idp1
• app2 federated to idp2
• idp2 federated to idp1 (idp2 acting as a RP)
• (this is an example of sharepoint federated to EntraID itself being federated to Okta)

If I first access to app1, I get authtime set to t0 by idp1 and sent to app1
If I then, 1 hour later, access to app2, idp1 should send t0 to idp2 (provided session is still on). Is that an authentication event from idp2 pov? Should app2 receive t0 or t0+1h?
IMHO app2 should receive t0 (except if idp2 does some additional MFA?) and IPSIE should require an IdP to transfer any authentication time it received if it's acting as both RP and IdP

[deansaxe]

IPSIE has not tackled IdP chaining to date. See #95 regarding IdP proxies.

[deansaxe]

We discussed this on the June 24, 2025 call and determined we needed additional information regarding the use of risk based authentication. See our notes.

Via IDPro slack, Justin Richer (an author on 800-63C) was engaged to ask about the authentication requirement. Summarizing his response here:

• The intent was to capture "the thing that starts a session" (e.g. authN)
• Risk engine evaluation may be considered an authN event, but it's implied that these details are part of a trust agreement. Both parties should know from that agreement what constitutes an authN event

My takeaway is that the 'auth_time' claim should always be paired with an amr claim to distinguish the mechanism used for authentication at the time specified in the auth_time claim. i.e. If reauthentication happened via the risk engine and no other authentication credentials were verified, the time of the event should be paired with amr=rba (risk based authentication from the IANA registry).

I appreciate feedback from others on this before doing any further writing.

[deansaxe]

From the July 1, 2025 call, we need to consider additional context. If a claim includes amr=phr,rba the RP cannot distinguish which amr was used at the time specified in auth_time.

Should we consider further enterprise extensions to be able to bind the amr claims to the specific times when they occurred?

[deansaxe]

From the July 1, 2025 call, we need to consider additional context. If a claim includes amr=phr,rba the RP cannot distinguish which amr was used at the time specified in auth_time.

Should we consider further enterprise extensions to be able to bind the amr claims to the specific times when they occurred?

See my comments here where I extend this idea.

[deansaxe]

@aaronpk I suggest that we close this issue since the PR has been merged. The remaining work is to determine how to handle the prompt (#92) and multiple amr and auth_time claims (#96).

[deansaxe]

The following comment is now #97.

Should IPSIE specify how this behaves in case of IdP chaining? I'm thinking more specifically of a setup like:

• app1 federated to idp1
• app2 federated to idp2
• idp2 federated to idp1 (idp2 acting as a RP)
• (this is an example of sharepoint federated to EntraID itself being federated to Okta)

If I first access to app1, I get authtime set to t0 by idp1 and sent to app1 If I then, 1 hour later, access to app2, idp1 should send t0 to idp2 (provided session is still on). Is that an authentication event from idp2 pov? Should app2 receive t0 or t0+1h? IMHO app2 should receive t0 (except if idp2 does some additional MFA?) and IPSIE should require an IdP to transfer any authentication time it received if it's acting as both RP and IdP