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

Fri Mar 27 08:02:14 UTC 2015

Hi Mike,

Thank you for raising this in the call, and for your detailed thoughts.

Our team looked into the possibility of always returning the actual
auth_time in response to a request with max_age without reauthing users
(thus not guaranteeing that the auth_time was within the requested range).
It's an interesting idea, but we found a potential issue:

A well implemented OIDC RP using max_age is told that they SHOULD validate
that the auth_time claim is indeed within the max_age they requested
(otherwise they are susceptible to client modification).  If we knowingly
return auth_times that exceed max_age, this would result in correctly
implemented RPs failing some of the time, potentially with a confusing
error message. An RP who expects this behavior may even choose to instruct
users to log out explicitly in order to get a more recent auth_time, which
is not a behavior we would like to encourage, as it is even more burdensome
to users than a reauth would be.

The alternative suggestion of returning auth_time=0 in this situation is an
interesting prospect, as it would avoid the above issue, while still giving
RPs a recovery option if they chose (e.g., to accept IdPs who don't offer
reauth).  I'll be covering that approach with Breno, Adam and the team on
Friday.

Best,
William

On Thu, Mar 26, 2015 at 8:48 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

>  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
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150327/a39c440a/attachment.html>