max_age and auth_time

[deansaxe]

Updated to address needs of FAL2 in openid/ipsie#90 and openid/ipsie#89.

[ttripp]

For reference:

max_age
OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. (The max_age request parameter corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] max_auth_age request parameter.) When max_age is used, the ID Token returned MUST include an auth_time Claim Value. Note that max_age=0 is equivalent to prompt=login.

https://openid.net/specs/openid-connect-core-1_0.html

[gffletch]

I missed the call on Jul 1 so don't know if this is resolved or not. I think we need to define what is meant my "end user authentication" (i.e. did the user need to do something? or is a silent authentication sufficient?). The OpenID Connect spec text also seems to imply ensuring that the authentication ensures the End-User is the same human who originally authenticated. I'm not sure we have good ways to do that other than biometric based challenges.

Maybe we can define this to mean that sufficient verification is performed by the OP to ensure that authentication methods bound to the identity associated with the session have been successfully completed.

[deansaxe]

@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": "phr, rba"
"auth_time_amr" : [
  {"auth_time": 1311280969, "amr": "rba"} 
  {"auth_time": 1311280000, "amr": "phr"}
] 

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.