<html><head><base href="x-msg://72/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Peter,<div><br></div><div>The tech writers got a bit carried away describing this.</div><div><br></div><div>In reality this is just an existing feature of PAPE. </div><div>In a PAPE request you can send a max_auth_age parameter.</div><div><br></div><div>This sets a limit on the maximum amount of time that can have transpired since the last interactive login for the user.</div><div><br></div><div>Some IdP may use long lived cookies that may have many days duration to authenticate users.</div><div><br></div><div>That may be fine for social networking but government sites may want to restrict that to a shorter time so that it is more likely the person to whom the credential has been assigned that is presenting it rather than someone else at the computer days later. </div><div><br></div><div>People have a habit of staying signed in to there social networking accounts.</div><div><br></div><div>Allowing the RP to specify the max age of the authentication allows OP's to continue with there existing practices and still allow a higher level of confidence for those RP's that require it.</div><div><br></div><div>It is also not uncommon to re prompt the user for there password before performing administrative tasks.</div><div><br></div><div>Setting max_aut_age=0 allows a RP to effect a similar level of security to the one they had before adopting openID.</div><div><br></div><div>This received a lot of discussion amongst the OP's in the pilot. </div><div>It has been in PAPE all along, just not implemented by the OP's</div><div><br></div><div>It has no effect on the users sessions with other RP's other than to update the users last interactive login time if someone else makes a similar request.</div><div><br></div><div>It is not new just an explanation of how to use a feature we put in PAPE some time ago. </div><div><br></div><div>John B.<br><div><div>On 2009-09-11, at 2:47 PM, Peter Williams wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 10.5pt; font-family: Consolas; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 10.5pt; font-family: Consolas; ">Several references are made to "session reset" - which is not a term I've heard anything about in 3 years of openid general discussions... It's apparently the SAML2 forceauthn=true handling requirement, with identical semantics. Nothing required the IdP or user to participate, though.<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><span style="color: black; ">Some more thoughts on this aspect of the profile. Assuming the OP has a user-browser/tab -> IdP session (or multiple such sessions if the browser instances do not share session state), we cannot have the ridiculous situation that one RP (of the several to which assertions have been released) can be forcing reauthentication of the user (or dropping the IdP session such that communications with the other RPs are affected)<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><span style="color: black; "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><span style="color: black; ">We don’t want a situation that some class of RPs all decide to auto-reauth every 50 mins from receipt of the PayPal assertion, way, which makes for a continuous prompting of the user at the IDP to reauth, as all the 50 min expiry periods happen to go off.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><span style="color: black; "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 10.5pt; font-family: Consolas; "><span style="color: black; ">What we need is for the RP to detect that a suitable positive assertion did not come back – despite request - and it cuts its own RP session (only). The destruction has no impact on any other RP session, or IDP->RP relationship tho.<o:p></o:p></span></div></div></div></span></blockquote></div><br></div></body></html>