<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yes leaving your proclivity for puppy photos aside.<div><br></div><div>I don't know that an error is the correct thing.</div><div><br></div><div>In principal if the idP gets max_age in the request and auth_time is > max_age then the IdP MUST attempt an interactive authentication (one not relying just on a session).  </div><div>If the user can't provide there credentials the IdP is going to return a not logged in response like any other.</div><div><br></div><div>The problem is if the IdP is not honouring the max_age request for some reason,  eg a social network doesn't really want to log you out ever, so they can track you. </div><div>They translate this to something like it is a bad user experience if the user must login again,  they get the blame and not the RP.</div><div><br></div><div>So we are never going to get 100% of IdP to support it, and the ones that don't are not likely to throw an error.</div><div><br></div><div>Adding a claim to the id_token saying you processed there request is probably the safest.</div><div><br></div><div>John</div><div><div><div>On 2013-02-04, at 1:22 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div>I'm pretty sure you don't need statistics to infer that I was surfing porn and gambling sites. Just sayin' ;)<br><br></div>But I (reluctantly) see your point about max_age. <br><br></div>

The spec could probably be clearer/stronger about the expected behavioral though. There's a little "must" about actively re-authenticating but nothing saying that an error must be returned or anything. And it's all nestled inside text about the request object which, I think anyway, is pretty much telling the OP what to try and do but not to return an error, if conditions can't be met. <br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 1:11 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">As long as the client has something to evaluate then not signing it is OK.<div><br></div>

<div>The reason for not coupling them was privacy.  That way a privacy respecting IdP could honour the request but not disclose when the IdP session started.</div><div><br></div><div>Suppose I send a authorization request with a max_auth_age of 2 weeks to the IdP perhaps reasonable, I think Yahoo's sessions are typically 4 weeks. </div>

<div><br></div><div>I get back a auth_time of 2am last night.  I may now be able to infer that you were surfing porn or gambling sites statistically.</div><div><br></div><div>It is a small info leak but one we were trying to avoid being criticized over.</div>

<div><br></div><div>The value of auth_time is a timestamp and I hate messing with special values.</div><div><br></div><div>Perhaps we need to return a "max_auth_age" : true claim if the claim request is met.</div>

<div><br></div><div>In openID 2 the logic was ask for max_auth_age and get back auth_time.  But as I say that was seen as bad for privacy.</div><div><br></div><div>This would be much easier without privacy concerns,  just saying:)</div>

<div><br></div><div>John B.</div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><div><div>On 2013-02-04, at 12:53 PM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr">I wasn't saying that there shouldn't be a way to ask for auth_time. But rather questioning the claim (pun intended) that singing the max_auth_age request was really that important or provided a great deal of value (as the client should validate what it gets back regardless of what it asked for).<br>



</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 12:12 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">No but there are currently two separate requests, one for the max_auth_age and the other requesting the auth_time claim.  The current spec doesn't couple them.<div>



Removing a way for the client to ask for auth_time in the response to determine if max_auth_age was acted on is a problem.</div><div><br></div><div>The solution may be simple by just saying that you need to return auth_time if the authorization server honours the max_auth_age request.</div>



<div><div><br></div><div><br><div><div>On 2013-02-04, at 11:55 AM, Brian Campbell <<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>> wrote:</div><br><blockquote type="cite">



<div dir="ltr"><div><div>In general isn't it really incumbent upon the client/RP to validate security sensitive things, like auth_time and acr, as needed in the response?  <br><br></div>That's how I've read it anyway, that the client can make whatever request it wants but that the OP isn't necessarily obligated (or capable) to live up to what is requested. And the client needs to enforce things that are important to it.<br>





<br></div>Is my interpretation wrong on that?<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 1, 2013 at 5:09 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div>For max_age you don't necessarily want the user to be able to modify that in the request, that might cause security issues if auth_time is not required in the response, the RP may be thinking it is getting a stronger authentication than it is in reality.</div>





<div><br></div><div>I would prefer to leave max_age in the signed request and not confuse the lower security parameter based request with it.</div><br></div></blockquote></div></div></div>

</div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></body></html>