To be sure I understand... Are you suggesting, Allen, that we don't
define a PAPE URI for "re-auth" and just use max_auth_age=0 as the
indicator for this behavior? I think I'd prefer to not define special
semantics for max_auth_age=0 and rather have a PAPE URI for "re-auth".
Of course if the RP sent a max_auth_age=0 it would almost certainly
result in the same behavior, I think it's cleaner to just treat
max_auth_age the same regarding it's value:
if ( (curr_time - auth_time) > max_auth_age) then re-verify credentials
Thanks,
George
Allen Tom wrote:
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
------------------------------------------------------------------------
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
