George,
I think it is clear from the spec that if max_auth_age=0 the OP must
perform a interactive login.
I think what Eric is suggesting is that a OP may choose to treat all
values of max_auth_age as 0.
Nothing in the PAPE spec precludes an OP from doing that.
I don't think that precludes other OPs from treating non 0 values of
max_auth_age differently.
Some may choose to limit max_auth_age to 1 day or some other value.
So it would be more like if(if(max_auth_age < auth_age) or if(auth_age
> local_max_auth_age) ) then re-verify credentials.
It is up to the OP to decide what local_max_auth_age should be. It
might depend on other PAPE parameters. eg if the RP is asking for
multi-factor then you may decide they care more about security and
make local_max_auth_age = 2h but otherwise be 12h or something like
that.
The PAPE spec leaves that up to the OP.
John B.
On 7-Jul-09, at 4:23 PM, 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
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
