Hi Simon,

I believe expires_in from 
http://openid.net/specs/openid-authentication-2_0.html#anchor20 
  is the thing you're interested in?


On Jul 2, 2008, at 5:40 PM, Simon Josefsson wrote:

> Dick Hardt <[EMAIL PROTECTED]> writes:
>
>> One parameter of PAPE was allowing the RP to specify how long it had
>> been since the OP had authenticated the user.
>
> I looked at the max_auth_age property, but it seems somewhat reverse  
> to
> what I am looking for: the max_auth_age property allows the RP to
> request that the OP do "active" authentication after a certain  
> interval.
> What I'm thinking of is that the OP can let the RP know that it is
> useful to request "active" authentication after a certain interval.
>
> One can emulate the latter by having the RP loop through the OP
> frequently, so that the OP can decide for itself when to perform  
> active
> authentication, but this would be slow (one loop through the OP
> frequently) and wasteful (hurts everyone, not just those using one- 
> time
> passwords).
>
>> There is a PAPE working group right now, if you were interested in
>> looking at how your suggestions would be incorporated, I am sure they
>> would welcome you to the group.
>>
>> I've cc'ed Mike Jones who is one of the people driving PAPE
>
> Thanks.  To be slightly more specific, what I'm thinking of would be a
> response parameter similar to:
>
> openid.pape.suggest_next_auth_time
>
>  (Optional) The number of seconds that the RP can hold off before
>  requesting an active authentication.  A value of 0 means infinity.
>
>  Value: Integer value greater than or equal to zero in seconds.
>
>  The RP is not required to re-authenticate with the OP after this
>  interval, but a low value indicates that the RP may increase security
>  by requiring user interaction with the OP more frequently.
>
> Alternatively, this problem may be solved by defining a new
> authentication policy.  However, it strikes me as the balance between
> writing a new authentication policy and adding a new request/response
> parameter is somewhat fuzzy.  Couldn't the NIST authentication level  
> be
> an authentication policy?
>
> Thanks,
> Simon
>
>> -- Dick
>>
>> On 2-Jul-08, at 7:45 AM, Simon Josefsson wrote:
>>
>>> Hi.
>>>
>>> Is there a best practice on how Openid consumers can find out  
>>> whether
>>> re-authenticating the user, via the OpenID server, once in a while  
>>> can
>>> lead to improved security?
>>>
>>> The security of normal one-time password systems (SecurID, SMS  
>>> codes,
>>> Yubikeys, ..) can be improved if you ask for a new one-time password
>>> once in a while.
>>>
>>> Of course, the OpenID server cannot do this on its own, so it  
>>> needs to
>>> be initiated by the OpenID consumer, but that will not happen  
>>> without
>>> clues that it is a good idea to do perform re-authentication.
>>>
>>> Thoughts?
>>>
>>> Would this be a worthwhile addition to the
>>> openid-provider-authentication-policy-extension document?  I'm
>>> thinking
>>> that the Response Parameters should include an optional parameter  
>>> that
>>> imply that a one-time-password system was used, which suggests that
>>> the
>>> RP may re-authenticate the user more frequently.
>>>
>>> It may be useful to generalize this idea somewhat, but I can't  
>>> come up
>>> with a better abstraction.  Even re-authenticating using password  
>>> may
>>> improve security in some situations (although I suspect most  
>>> passwords
>>> are cached by browsers anyway these days).  Ideas welcome.
>>>
>>> Thanks,
>>> Simon
>>>
>>> Btw, this idea originated from discussions on
>>> <http://forum.yubico.com/viewtopic.php?f=9&t=126>.
>>> _______________________________________________
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
> _______________________________________________
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs

-- 
Martin Paljak
http://martin.paljak.pri.ee
GSM: +3725156495




_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to