[PROPOSAL] authentication age

Recordon, David drecordon at verisign.com
Thu Oct 5 21:59:51 UTC 2006


I don't see a problem with the wording of:
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.

I don't think however that enough consensus will be reached on this
proposal to place it in the spec though.  That is why I'd advise it be
written as an extension and then merged into the specification in a
future version.

--David

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Dick Hardt
Sent: Thursday, October 05, 2006 9:25 AM
To: Kevin Turner
Cc: specs at openid.net
Subject: Re: [PROPOSAL] authentication age

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
choice.

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 Amazon.com, 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 Amazon.com 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 Amazon.com 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 
> support.
>
> 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 
> able 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 just 'require *if the user feels like it.*'  Your 
> implementation failed to enforce our requirements.  You're fired," 
> then that is not so good for you.
>
> My worry is that features like this will mislead the RP developers 
> into 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 leaves 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 
> rare to see password lifetime restrictions on the Web these days, it 
> was popular to do in other applications for a while.)  But with 
> OpenID, the 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 good.
>
> 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 at openid.net
> http://openid.net/mailman/listinfo/specs
>
>

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs




More information about the specs mailing list