[no subject]

That would mean the SP would specify the minimum acceptable =
authentication "strength", maximum length of timeout settings, and =
complete set of authorize-able users.  Then potentially an SA or user =
could request "stronger" authentication, shorter timeouts, and/or a =
subset of the authorize-able users.  Neither the SA nor the user can do =
the inverse of any of these.

In thinking through how this might work, it seems providing a logical =
user experience means not mixing SPs requiring timeouts within the same =
session.  Today in our real production environment, we have been unable =
to mix SP timeouts within the same SSO environment without introducing =
user interaction anomalies.  This is not a technical limitation, the =
anomalies exist even in a perfect environment.

Mike

-----Original Message-----
From: John Kemp [mailto:onezero@bcn.net]
Sent: Tuesday, October 21, 2003 5:13 PM
To: Steve Anderson
Cc: security-services@lists.oasis-open.org
Subject: Re: [security-services] AI 60 - Dynamic Session Material=20


Steve,

Thanks for taking the time to review the document! Comments inline=20
below:

On Friday, Oct 17, 2003, at 18:17 US/Eastern, Steve Anderson wrote:

> Some comments on the use case/requirement document ... Better late=20
> than never, I suppose ...
>
> I propose changing the definition of "Idle Time-out" from
>
>   A period of time, after which, if there is no activity by the user=20
> associated
>   with a session, the session may be considered invalid
>
> to
>
>   A period of time, during which, if there is no activity by the user=20
> associated
>   with a session, the session may be considered suspended.
>
> The wording change at the beginning is just clarification, and I don't =

> expect it to be controversial.

Not controversial perhaps, but important. I can say that what I meant=20
by "timeout" was actually "timeout value" - ie. a timeout value of 2=20
hours would imply that a session was considered timed-out after a=20
period of exactly 2 hours. Changing "after" to "during" changes the=20
meaning of timeout - I like your definition better, but it may well=20
reflect some changes I need to make to the rest of the document ;)

>  The wording change at the end may generate a little discussion.  I=20
> prefer the notion of suspending the session here, because if the user=20
> re-authenticates successfully, the data associated with the session=20
> before the timeout should still be available.  Under the previous=20
> wording, there was no distinction between disposition of the session=20
> during timeout and during logout.

I'm certainly open to this... anyone else have something to add?

> I would also like to echo some of Mike Beach's comments.  I view the=20
> SP as the top of the food chain, as it relates to idle timeout=20
> thresholds.  Other links in that 'chain' can shorten the threshold,=20
> but not widen.

Can you expand on that view? I'll just say the same thing I said about=20
Mike's earlier comment. I think that for a *local* resource, the SP=20
*is* the SA, but that they may be conceptually separate, implying that=20
at the least the SA and the SP will "agree" on timeout values. For a=20
*shared* session, the SA is almost certain to NOT be physically=20
connected to the SP, but still may be, and the SA will have ultimate=20
responsibility for the timeout values set - an individual SP shouldn't=20
be able to affect the timeout value for a session that is shared with=20
other SPs - one would imagine the SA would have to take responsibility=20
to setting the global session timeout, no?

Thanks again,

- JohnK


To unsubscribe from this mailing list (and be removed from the roster of =
the OASIS TC), go to =
http://www.oasis-open.org/apps/org/workgroup/security-services/members/le=
ave_workgroup.php.