[Openid-specs-ab] Conformance and Max Auth Age

[Mike Jones]

Hi Adam and team,

We discussed this on the OpenID Connect call this morning.  We didn’t reach any firm conclusions yet, in part, because we think some further discussion is needed both with your team and among the working group to arrive at a solution that works well for everyone.

John Bradley reminded us of the history of this feature (which actually came from the OpenID 2.0 PAPE extension).  Some RPs were uncomfortable accepting authentications that might be weeks old and based solely on cookies – which could be the case with Yahoo identities at that time.  The problem is that there’s no assurance that the same user is present.  The max_age request and auth_time response are intended to enable RPs to have some assurance that the correct user is likely to be actually present, when there are business reasons to do so.

We agreed that that one valid implementation of auth_time is to return the time that the OP last was able to somehow validate that the user was present.  This needn’t be a password.  For instance, if you’re on a mobile device, a device unlock event certainly qualifies as proof that the user is present.  If you could return an auth_time value that’s an accurate reflection of this when max_age is requested, I know that the working group would be satisfied with that.  Even if the auth_time was older than what was requested by max_age, at least the RP would have accurate information that it could use in its own risk assessment.  Without auth_time, the RP really doesn’t have any usable data about when the user was last present.  Could we go that route?

I’ll note that people also made the point that device reauthentication is different than user reauthentication.  For instance, just because the connection remains on the same IP address with the same cookies, that’s a clear indication that the device is the same, but it’s not a good indication that the same user is present.  Therefore, those in the discussion weren’t comfortable with a device reauthentication time being returned as auth_time.  Whereas, if a user unlocked their phone, that’s user authentication – not device authentication.

In closing, there’s a tension between defending the OP from RPs trying to always force re-logins, which I think none of us want, and giving the RP actionable information about when the user was last known to be actually present, which we suspect all of us want.  What are your thoughts?

                                                            -- Mike

From: Adam Dawes [mailto:adawes at google.com]
Sent: Thursday, March 26, 2015 12:53 AM
To: Mike Jones
Cc: Don Thibeau; Naveen Agarwal; William Denniss; Breno de Medeiros; John Bradley; Eric Sachs
Subject: Conformance and Max Auth Age

Hi Mike,

We're burning down the list of remaining OIDC conformance issues, this is one of the remaining sticking points for us.

As an IdP, we have strong opinions on forcing users to re-authenticate, in that it should be avoided unless needed. We have a sophisticated risk engine to detect situations where reauthentication is needed, which takes into account a number of different factors related to each user's unique situation (for example, a 2SV user using their browser from a new location will likely need to reauth).

We don't want to hand the session quality decision process over to RPs in the form of a one-size-fits-all method like "max_age", for fear that every RP will start adding "max_age=1" in a misguided attempt to improve security. We're also concerned about training users that they should enter their password every time they visit a site, for fear this will make it easier to phish them.

On mobile in particular, Max Auth Age is problematic. For "passwordless mobile accounts" like Yahoo just launched, reauthenticating the user with a password isn't really possible (except to the extent that you're creating a circular loop of receiving the OTP on the same device where you're reauthing).

Currently, we don't honor max_age and don't return an auth_time claim. This is how we would like to move forward, we won't error the OIDC request if max_age is present, but we won't reauth, and won't return the auth_time claim. The RP can look for the absence of auth_time and act accordingly (including, not using Google as an IdP).

The test in question is "OP-IDToken-max_age=1", specifically the "ID Token has auth_time claim when max_age in request" feature. Our wish is to certify as conformant without supporting that feature.

We've brainstormed a number of approaches. Ultimately, we think the cleanest would be to just drop the test from the conformance suite. Alternatively, we're prepared to return an auth_time based on the last check of our risk system, but not necessarily prompting a reauth action for the user. This might allow us to pass the current test but may not meet with the expectations of RPs.

Happy to get on a call to discuss ways that we can find a resolution to this. Obviously, we very much want to support the standard and conformance launch but we're not prepared to give RPs the ability to call for password checks at their own whim.

thanks,
AD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150326/b3422593/attachment.html>