Hi George,
Is there any other plausible expectation that an RP could have other
than "re-auth" for max_auth_age=0? If not, then it's probably simpler to
just more clearly define (perhaps in a best practices doc) what the
behavior for max_auth_age=0 should be, rather than define a new policy
which is identical to max_auth_age=0.
The reason why I'd like to establish max_auth_age=0 as the convention
for re-auth, is that any "small" value of max_auth_age could be
interpreted as re-auth, so I'd like to elminate any uncertanity for
implementers by just saying that "0" means re-auth, and be done with it.
Allen
George Fletcher wrote:
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
