Re: [PROPOSAL] authentication age

2006-10-05 Thread Dick Hardt
Kevin, thanks for the well articulated argument.

I do see this as something that is completely within the End Users  
control, and if the End User chose to ignore it, then that is their  

The use case is that for convenience, a site wants to let the user do  
certain functions without having to have authenticated recently. Some  
functions require a fresh authentication. For example it is easy to  
browse around, but when you go to purchase something, they  
want to make sure that it is still you, and prompt you for your  
password. Of course I can have my browser configured to autocomplete  
the password prompt and all I have to do is press enter, which  
circumvents proving it is me since someone walking up to my computer  
does not need to know my password to
complete a purchase.

The point is that the has made an effort to increase the  
certainty that it is me, and it is my choice to not take advantage of  
it. If OpenID does NOT have this functionality, sites that have  
requirements similar to will be reluctant to adopt OpenID.

In the spec, I would say auth age is a request the RP MAY make, and  
that the IdP SHOULD accept, and that there is no certainty that the  
IdP will accept it.

To look at it another way, there is no requirement for the IdP to ask  
me if I want to respond to an RP that I have never been to before. I  
could have an IdP that responds positively to ever request with no  
interaction from myself. There is nothing in OpenID that proves I  
approved the request, or for that matter that there is actually a  
person at the end of the browser.

On 4-Oct-06, at 6:29 PM, Kevin Turner wrote:

 Pretty much the *only* relationship that exists between the RP and the
 IdP is that the authentication method is trustworthy because the user
 has decided it is.  I believe this proposal places additional  
 demands on
 that, and that those are demands that the protocol cannot fully  

 When you ask an OpenID IdP for information, you are not asking some
 ultimately trusted third party, you're asking whomever End User  
 chose to
 appoint as her agent.  Which is quite possibly an entity entirely
 controlled by End User herself.  All information sent by the IdP is
 *only as true as the user wants it to be.*

 So I think the question is, who will catch the blame when the RP's
 requirements for credentials checking aren't followed?  Will you be  
 to say End User chose to ignore our requirements, so it's End User's
 problem.?  If so, this proposal is okay.  But if your Draconian
 Security Officer will say When I said to require up-to-the-moment
 credential checks to access our resources, I did mean REQUIRE, not  
 'require *if the user feels like it.*'  Your implementation failed to
 enforce our requirements.  You're fired, then that is not so good for

 My worry is that features like this will mislead the RP developers  
 thinking they have more control over the authentication protocol than
 they really do, into thinking that they can exert the level of control
 required by that Draconian Security Officer, when OpenID actually  
 all those controls in the hands of the user and their chosen IdP.

 Session age isn't the only thing application developers will be
 accustomed to having control over.  Password strength and password
 lifetime are a few other obvious examples.  (Although I think it's  
 to see password lifetime restrictions on the Web these days, it was
 popular to do in other applications for a while.)  But with OpenID,  
 RP won't have real control over of any of those things.  I'm concerned
 that adding parameters that suggest it does will do more harm than  

 The RP doesn't even have the capacity to audit any of those processes,
 to find out what procedure was followed.  Now that I think about it,
 that may be the real problem: How useful is it to specify security
 requirements that you can't audit?

 specs mailing list

specs mailing list

RE: [PROPOSAL] authentication age

2006-10-02 Thread Kevin Turner
On Sun, 2006-10-01 at 13:08 -0700, Recordon, David wrote:

 It could be augmented to also contain a response parameter telling the
 RP if the IdP acknowledged it, then the RP could make the decision if
 it wants to proceed.

You will want that response parameter.  Otherwise, couldn't I (as the
attacker who has the user's IdP cookie) just drop the auth_age parameter
from the checkid request?

specs mailing list