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

Fri Mar 27 16:49:03 UTC 2015

Hi Mike,

The concern with sending auth_time to every RP is that it would enable them
to tell our users "to use x, please log out first" which is not a UX
pattern we endorse, or want to enable (for the same reasons we don't enable
blanket reauth).

We are not opposed to providing more risk signals to RPs in general, and
are working with standards groups on more ways to do this.

The nice thing about auth_time=0 (for requests passing max_age) is that it
could be treated as an explicit signal meaning "the IdP received your
request with max_age, but explicitly does not provide this information: act
accordingly".  This could be more useful than not returning an auth_time at
all, which leaves the RP wondering if the IdP doesn't support reauth, or
the client was modified. I also feel it is more accurate than always
returning an auth_time of "now".

Am looking forward to discussing this further with you on the call too.

Best,
William

On Fri, Mar 27, 2015 at 7:14 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

>  Thanks William,
>
>
>
> As a protocol design principle, it’s nearly always better to give parties
> accurate information and let them decide how to act upon it than to
> withhold the information they might need to make a decision.  The specific
> application here is that if you can return an accurate auth_time, that
> gives the RP information it can act upon in its risk engine that it
> otherwise would not have.  That’s far better than returning auth_time=0,
> which tells the RP that the authentication happened on January 1, 1970.
>
>
>
> As a practical matter, I suspect more RPs will be happy to continue with
> the session if the auth_time is in the recent past than decades old.  Yes,
> they’re supposed to validate the auth_time, but it’s up to them what to do
> if it’s older than they like.  Telling them when it actually happened seems
> strictly better than withholding this actionable information.
>
>
>
> I’m looking forward to talking later today.
>
>
>
>
> -- Mike
>
>
>
> *From:* William Denniss [mailto:wdenniss at google.com]
> *Sent:* Friday, March 27, 2015 3:02 AM
> *To:* Mike Jones
> *Cc:* Adam Dawes; openid-specs-ab at lists.openid.net; Eric Sachs; Naveen
> Agarwal; Don Thibeau
> *Subject:* Re: [Openid-specs-ab] Conformance and Max Auth Age
>
>
>
> 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/0467ecde/attachment.html>