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

Eric Sachs esachs at google.com
Tue Jul 7 17:47:17 UTC 2009


I hope everyone had a nice long weekend and is recharged to continue this
debate :-)

We are focused on two issues
 1 - password reprompts
 2 - time since last authentication at the IDP
For both of these we have some practical (but potentially debatable)
requirements about current practices, and then we have ideas on what we wish
were the best practices.  I suggest that we make sure to support that
practical requirements in the near-term, but keep the opportunity available
for potential improvements in the future.

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.

Even within Google, we don't provide a way for individual applications to
ask the central identity system to support the equivalent of a numeric
max_auth_age.  We offered to build it, but none of the apps wanted it.  Most
apps don't care about password reprompt, and the ones that do prefer to
control the process as much as possible, even if (1) it potentially hurts
usability in some edge cases by requiring the user to be re-authenticated
multiple times in just a few minutes and (2) it forces the RP to do extra
work to compare the time of when they started this workflow to the time when
the user comes back, and decide if the time window is short enough to be
acceptable.

Similarly, we don't have any relying-parties outside Google who are pressing
us to support a numeric value of max_auth_age.  Most of them even don't know
about the existence of PAPE, they just ask for "password reprompt"
functionality.  The higher priority requests we get in this area are to
support things like (1) forcing the user to change their password (such as
in cases where the RP is pretty sure the user's credentials have been
stolen) and (2) forcing the user to re-confirm they want their identity
shared with the RP even if previously asked for this to be done
automatically.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090707/ff17bb95/attachment.htm>


More information about the security mailing list