multiple `auth_time` and `amr` values

[aaronpk]

@gffletch see the notes from July 1.

We determined that the auth_time claim and amr claims should be paired. However, that doesn't resolve the issue of the auth_time if amr has multiple values. @aaronpk and I spoke this morning, we think there needs to be an extension to the core spec which enables the RP to determine the auth_time for each amr value. At first glance, a JSON array such as follows would meet the need.

"amr": "hwk, rba"
"auth_time_amr" : [
  {"auth_time": 1311280969, "amr": "rba"} 
  {"auth_time": 1311280000, "amr": "hwk"}
] 

This is an example and may not be acceptable syntax, but it should give you an idea of what we're thinking about. I'm open to other ideas of how to represent the mapping of 2..n amr claims to the auth_time of each claim.

Originally posted by @deansaxe in openid/ipsie-openid-sl1#4 (comment)

(Edited to change phr to hwk to match the correct IANA registry values.)

[gffletch]

For me, auth_time_amr is the beginning of an authentication context with history for the session. In that like, I suspect other fields besides just auth_time and amr will be important. I would expect that most OPs do a risk evaluation on every request and I could see an authorization PDP wanting to know the risk score for each authentication event.

Based on the WG call for July 8, 2025... I don't think we can change the semantics of the existing auth_time and amr claims. IPSIE could specify that the id_token contains the last auth_time and amr values.

IPSIE could also work with the OpenID Connect working group to define and extension for the session authentication context which contains the history of each authentication even across the lifetime of the session. IPSIE could then require this extension to be present in all issued id_tokens.

I'm assuming this is what @aaronpk and @deansaxe are suggesting. I would just add that I believe the extension should cover the authentication context concept and not just auth_time and amr.

[deansaxe]

This may be more work than we have time to accomplish ahead of the planned interop. We will continue working on this issue with recognition that a solution may not exist prior to the interop event.

[deansaxe]

@aaronpk and I discussed this on our planning call today.

If you are an IdP or have implemented an IdP, can you please document how your service issues the amr and auth_time claims. Specifically, we want to know:

• Do you issue one or more values for the amr claim?
  • If so, is there any structure to the order of the values?
• After primary authentication (e.g. password, passkey, MFA) do you later perform any risk based authentication?
  • If so, do you change the amr after RBA, either by changing it to rba or adding rba to the list of amr values?
  • Does your service change the auth_time value to match the time of the RBA or does the value match the time of the initial authentication event?

We want to understand what the common patterns in use are in order to minimize any disruption of existing services.

[mcguinness]

IIRC for Okta

• amr claim is not ordered, its just a set. You are unable to know the method sequence
• Risk based authentication is zero-trust policy condition evaluated on every SSO event (as well as actions) that triggers step-up when exceeded. It doesn't change the auth_time claim as its evaluated for every authorization request. SSF is used to evaluate risk changes out-of-band of SSO events
• rba method is not published

AMR is stored as part of the session as a tuple of method:timestamp. ID Tokens just pull latest values from the session. Policy introspects the session on SSO or specific actions. Risk is just a policy condition.

[deansaxe]

Following the discussion on the July 15, 2025 call we are going to pause further work on mapping multiple amr and auth_time claims in an array absent a clear, specific need to do so. Instead, I will update the OIDC SL1 doc with additional constraints around the auth_time claim.

If you have a need to express/consume multiple amr and auth_time claims, please let us know.

[deansaxe]

Since a month has passed with no updates nor a requirement to add multiple claims, I am closing this issue. We can reopen the issue if necessary at a later date.