[OpenID] RP library authors

[John Bradley]

Peter,

The tech writers got a bit carried away describing this.

In reality this is just an existing feature of PAPE.
In a PAPE request you can send a max_auth_age parameter.

This sets a limit on the maximum amount of time that can have  
transpired since the last interactive login for the user.

Some IdP may use long lived cookies that may have many days duration  
to authenticate users.

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.

People have a habit of staying signed in to there social networking  
accounts.

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.

It is also not uncommon to re prompt the user for there password  
before performing administrative tasks.

Setting max_aut_age=0 allows a RP to effect a similar level of  
security to the one they had before adopting openID.

This received a lot of discussion amongst the OP's in the pilot.
It has been in PAPE all along, just not implemented by the OP's

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.

It is not new just an explanation of how to use a feature we put in  
PAPE some time ago.

John B.
On 2009-09-11, at 2:47 PM, Peter Williams wrote:

>
> 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.
>
>
> 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)
>
> 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.
>
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090911/897c9a3a/attachment.htm>