Auto logout? Request re-authentication from the server?
Martin Paljak
martin at paljak.pri.ee
Wed Jul 2 17:15:57 UTC 2008
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 <dick at sxip.com> 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 at openid.net
>>> http://openid.net/mailman/listinfo/specs
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
--
Martin Paljak
http://martin.paljak.pri.ee
GSM: +3725156495
More information about the specs
mailing list