[security] PAPE Policy for RPs to force authentication without browser cookie

[Allen Tom]

Eric Sachs wrote:
>
> The short version of my suggestion is that IDPs should be "lazy."  For 
> any value of max_auth_age (including 0), the "lazy" can ALWAYS perform 
> a re-authentication before sending the user to the RP.  The IDP could 
> also send along the "last authentication time" as well, but it isn't 
> particularly interesting in this case.
>
This is a good compromise that satisfies the use case that RPs seem to 
be asking for - which is to be able to force the OP to re-authenticate 
the user (verify the user's password) before returning a positive 
assertion, while making it possible to optimize the user experience 
later, if this becomes an issue.

As a best practice, we should recommend that we use max_auth_age=0 as 
the flag for this behavior to eliminate any ambiguity for implementers.

Speaking on behalf of the Yahoo OP, we will implement the "lazy" 
behavior, with the recommendation that RPs that want to force a password 
reprompt send max_auth_age=0 in the authentication request to indicate 
this. Our experience within Yahoo is that applications that actually 
care about the user's last authentication time almost always elect to 
force a password re-verification, rather than try to determine if the 
last authentication time is acceptable. Although this is can sometimes 
result in a sub-optimal user experience, in which the user is forced to 
enter their password multiple times within a short interval, in 
practice, applications that actually care about this prefer to take the 
conservative (and easier) approach of just unconditionally forcing the 
password to be re-verified.

> In the future we will hopefully find some aggressive early-adopters 
> who have a strong need for the more advanced max_auth_age flow, and 
> they can help define the best practices.  But in the meantime, I'd 
> suggest that IDPs start with the "lazy" version and see how far it 
> gets us.
>
Works for me!
Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090707/a3d48ab7/attachment.htm>