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

[Allen Tom]

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
>> security at openid.net
>> http://openid.net/mailman/listinfo/security
>>