Some comments on the use case/requirement document ... Better late 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 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 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. The wording change at the end may generate a little discussion. I prefer the notion of suspending the session here, because if the user re-authenticates successfully, the data associated with the session before the timeout should still be available. Under the previous wording, there was no distinction between disposition of the session during timeout and during logout.
I would also like to echo some of Mike Beach's comments. I view the SP as the top of the food chain, as it relates to idle timeout thresholds. Other links in that 'chain' can shorten the threshold, but not widen.
I also admit that I don't completely have my head around the ramifications of a separate session authority, but it does seem like the right direction.
--
Steve
-----Original Message-----
From: John Kemp [mailto:]
Sent: Tuesday, October 14, 2003 5:54 PM
To: Hal Lockhart
Cc:
Subject: Re: [security-services] AI 60 - Dynamic Session Material
I would just note that I reviewed this presentation, and the earlier
session materials forwarded to the list by Jason. I believe that the
use-case/requirements document that I wrote (draft 02) currently
uploaded in Kavi covers all of the requirements mentioned in these
materials. I would appreciate some review (in particular from you,
Hal). Several of the requirements are covered by the existing work on
Single Logout in Liberty (and are marked as such in the requirements
document) but, in particular, no timeouts are specifically covered in
the Liberty work.
The concept of a Session Authority as potentially separate from an
Authentication Authority deserves some thought in particular - if we go
this route, we may need to think carefully about the link between a
session and authentication in SAML (and how we model it in the
protocol). Also, understanding the interaction between a local session
and some session that is shared between multiple service providers is
important.
Cheers,
- JohnK
On Tuesday, Oct 14, 2003, at 13:01 US/Eastern, Hal Lockhart wrote:
> Here is a presentatioon I made to the TC back in August 2001 on Dynamic
> Sessions.
>
> Hal
> <Dynamic Sessions.ppt>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/leave_workgroup.php.
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/leave_workgroup.php.
