[PROPOSAL] authentication age

Recordon, David drecordon at verisign.com
Sun Oct 1 20:08:38 UTC 2006


That was going to be my exact follow-up to my own message, though got distracted.  What I phrased was how Dick described it.

I like the feature, though agree that many IdPs may be unable to implement it due to how they do session handling.  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.

--David


-----Original Message-----
From: specs-bounces at openid.net on behalf of Martin Atkins
Sent: Sun 10/1/2006 12:07 PM
To: specs at openid.net
Subject: Re: [PROPOSAL] authentication age
 
Recordon, David wrote:
> No, IdP MUST perform and RP MAY include.
> 

IdP implementations that are embedded into some other app might have 
trouble implementing this. Take LiveJournal, for example: what should it 
do in the case where it has to re-authenticate? End the user's LJ 
session and force them to log in again? Duplicate the login code in the 
OpenID server code?

Aside from that qualm, this is another one of those things where it's 
pointless to make it a MUST since IdPs that don't implement it aren't 
going to get punished in any way. If IdPs can get away without doing it, 
and RPs can't tell that they have, then some/most IdPs just won't 
bother. Sure, it reduces the usefulness of this feature, but this 
feature is riding on a completely uncheckable assumption and is 
therefore broken by design.

The best we can do is make it a MAY (that is, max_age is a *suggestion* 
from the RP) and hope that most IdPs do the right thing; we shouldn't 
write the spec in a way that misleads RP implementers into thinking 
they've actually got any real control here.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061001/476e8585/attachment-0001.htm>


More information about the specs mailing list