<div dir="ltr"><div>This is an interesting approach. I like that it would give an explicit signal to the RP that, yes, the IdP received the request for <font face="monospace, monospace">max_age</font> (i.e no client modification), but no, it won't be revealing the <font face="monospace, monospace">auth_time</font>.</div><div><br></div><div>RPs then have a choice of whether to accept such IdPs or not, and could potentially make that decision in a dynamic way without special-case rules.</div><div><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 6:43 PM Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> 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 dir="auto"><div><p class="MsoNormal"><font face="UICTFontTextStyleBody" size="3"><span style="background-color:rgba(255,255,255,0)">FYI, after the call, Brian, John and me discussed this a bit more, and came to the conclusion that returning auth_time=0 may also be a good. There are times that you really do not know what it was, and in that case, returning the epic would be a reasonable thing. In google's case, it can always return auth_time=0 when asked indicating that google is unwilling to disclose this data. <u></u><u></u></span></font></p><div><p class="MsoNormal"><u></u><font face="UICTFontTextStyleBody" size="3"> </font><u></u></p></div><div><p class="MsoNormal"><font face="UICTFontTextStyleBody" size="3"><span style="background-color:rgba(255,255,255,0)">So, the semantics of auth_time=0 is either the IdP does not know the last active authentication time or is not willing to disclose it for various policy reasons, including both security and privacy. </span></font></p></div><br>=nat via iPhone</div><div><br>2015/03/26 9:54、Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>> のメッセージ:<br><br></div></div><div dir="auto"><blockquote type="cite"><div>
<div>
<p class="MsoNormal">Spec call notes 26-Mar-15<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">John Bradley<u></u><u></u></p>
<p class="MsoNormal">Brian Campbell<u></u><u></u></p>
<p class="MsoNormal">Nat Sakimura<u></u><u></u></p>
<p class="MsoNormal">Mike Jones<u></u><u></u></p>
<p class="MsoNormal">Edmund Jay<u></u><u></u></p>
<p class="MsoNormal">Justin Richer<u></u><u></u></p>
<p class="MsoNormal">Roland Hedberg<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Agenda<u></u><u></u></p>
<p class="MsoNormal"> Open Issues<u></u><u></u></p>
<p class="MsoNormal"> UserInfo access passing access token in the body<u></u><u></u></p>
<p class="MsoNormal"> Google not wanting to support max_age and auth_time<u></u><u></u></p>
<p class="MsoNormal"> JOSE/JWT/OAuth Assertions specs status<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Open Issues<u></u><u></u></p>
<p class="MsoNormal"> #123: redirect_URI tests still reporting wrong results.<u></u><u></u></p>
<p class="MsoNormal"> John will close as resolved<u></u><u></u></p>
<p class="MsoNormal"> No other issues were immediately pertinent to certification<u></u><u></u></p>
<p class="MsoNormal"> Mike has placed two issues not needed for v1 certification on hold<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">UserInfo access passing access token in the body<u></u><u></u></p>
<p class="MsoNormal"> It's a MAY in 6750<u></u><u></u></p>
<p class="MsoNormal"> This there to enable JavaScript clients and others which may not be able add an Authorization header<u></u><u></u></p>
<p class="MsoNormal"> Let's make this a WARNING rather than an ERROR now<u></u><u></u></p>
<p class="MsoNormal"> In v2, we should probably add this to the Dynamic profile as required<u></u><u></u></p>
<p class="MsoNormal"> Roland will make this a warning and send a note to the list when it's done<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Google not wanting to support max_age and auth_time<u></u><u></u></p>
<p class="MsoNormal"> Possibly reply asking if they can return an auth_time that actually reflects when the user authorized/was in possession of the device<u></u><u></u></p>
<p class="MsoNormal"> User presence signal that doesn't require a password<u></u><u></u></p>
<p class="MsoNormal"> Such as a native application on a mobile device<u></u><u></u></p>
<p class="MsoNormal"> A screen unlock is a valid user presence indicator<u></u><u></u></p>
<p class="MsoNormal"> But device authentication time is a different semantic, which could be added, but it's different<u></u><u></u></p>
<p class="MsoNormal"> Reauthentication may make more sense in the context of a particular action by the user<u></u><u></u></p>
<p class="MsoNormal"> Real-time consent for an action, as a step-up action, rather than just re-login<u></u><u></u></p>
<p class="MsoNormal"> Then the user has context for the action<u></u><u></u></p>
<p class="MsoNormal"> Mike will send a response asking for more discussion<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">JOSE/JWT/OAuth Assertions specs status<u></u><u></u></p>
<p class="MsoNormal"> These have exited RFC Editor "EDIT" status<u></u><u></u></p>
<p class="MsoNormal"> They are now in "RFC-EDITOR" status: Undergoing final internal review before AUTH48
<u></u><u></u></p>
<p class="MsoNormal"> This means the authors will soon be asked to verify that the edited specs are correct<u></u><u></u></p>
<p class="MsoNormal"> This is called AUTH48 because authors are supposed to respond within 48 hours<u></u><u></u></p>
</div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<u></u>_________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.<u></u>net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-specs-<u></u>ab</a></span><br></div></blockquote></div>______________________________<u></u><u></u>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.<u></u>n<u></u>et</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/<u></u>mailma<u></u>n/listinfo/openid-specs-<u></u>ab</a><br>
</blockquote></div></div></div>