<div dir="ltr"><div>Hi Mike,</div><div><br></div><div>Thank you for raising this in the call, and for your detailed thoughts.</div><div><br></div><div>Our team looked into the possibility of always returning the actual <font face="monospace, monospace">auth_time</font> in response to a request with <font face="monospace, monospace">max_age</font> without reauthing users (thus not guaranteeing that the <font face="monospace, monospace">auth_time</font> was within the requested range). It's an interesting idea, but we found a potential issue:<br></div><div><br></div><div>A well implemented OIDC RP using <font face="monospace, monospace">max_age</font> is told that they SHOULD validate that the <font face="monospace, monospace">auth_time</font> claim is indeed within the <font face="monospace, monospace">max_age</font> they requested (otherwise they are susceptible to client modification). If we knowingly return <font face="monospace, monospace">auth_time</font>s that exceed <font face="monospace, monospace">max_age</font>, 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 <font face="monospace, monospace">auth_time</font>, which is not a behavior we would like to encourage, as it is even more burdensome to users than a reauth would be.</div><div><br></div><div>The alternative suggestion of returning <font face="monospace, monospace">auth_time=0</font> 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.</div><div><br></div><div>Best,</div><div>William</div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 8:48 AM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hi Adam and team,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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?<u></u><u></u></span></p><span>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Adam Dawes [mailto:<a href="mailto:adawes@google.com" target="_blank">adawes@google.com</a>]
<br>
<b>Sent:</b> Thursday, March 26, 2015 12:53 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> Don Thibeau; Naveen Agarwal; William Denniss; Breno de Medeiros; John Bradley; Eric Sachs<br>
<b>Subject:</b> Conformance and Max Auth Age<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><div>
<p class="MsoNormal">Hi Mike,<u></u><u></u></p><div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">We're burning down the list of remaining OIDC conformance issues, this is one of the remaining sticking points for us.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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).<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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). <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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).<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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.<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">thanks,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.5pt">AD<u></u><u></u></span></p>
</div>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div></div></div>