Wrapping Up Proposals

[Dick Hardt]

On 3-Oct-06, at 11:48 PM, Josh Hoyt wrote:

> On 10/3/06, Dick Hardt <dick at sxip.com> wrote:
>> > * Authentication age
>> > (http://openid.net/pipermail/specs/2006-September/000141.html)
>> >       Still being discussed, varying opinions on if the spec  
>> mandates
>> > this will IdPs cooperate.  Proposal of having it as an extension.
>>
>> +1 - per other email, let's get the feature in there. The IdP is
>> already managing session age. Having it as an extension is going to
>> add complexity to RP code as they have to discover if they can have
>> that as a parameter. This seems like huge overhead to determine a
>> single parameter
>
> There are other related session-management issues that need to be
> addressed, so I think it's silly to say that it'd be an extension for
> one parameter. I'd like it to be in a different spec so that those
> issues can be hashed out without having to update the core
> specification. Other things that might go in that spec include
> single-sign-off and the IdP advising the RP that the assertion is only
> good for a certain period of time.

session age is part of many existing sites coding patterns, it is a  
request we received a number of times when designing SXIP 1.0
NOT having session age now will limit who will adopt OpenID 2.0

Of all the points in discussion, I feel the most strongly about this  
one being in the spec as for many RPs this is an important aspect of  
AuthN.

single-sign-off and assertion expiry are not part of existing coding  
patterns.

I don't want to start a discussion on single-sign-off and assertion  
expiry, but here is my experience:

single-sign-off is impractical and although it seems to add value,  
our experience with SXIP 1.0 was that it did not, that implementing  
was difficult, and that users did not see value

authn assertion expiry does not seem to have value -- SAML does not  
use it, I would see the RP having its own session age to determine if  
the session is still valid. Perhaps there is a use case I am missing.


having spent considerable time on single-sign-off, it is not practical

having an authN assertion valid for a certain period of time is  
pretty meaningless as well

the RP knowing how long the user authn is useful and is part of  
existing coding patterns in websites