OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] AI 60 - Dynamic Session Material


Thanks for taking the time to review the document! Comments inline 

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

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

Not controversial perhaps, but important. I can say that what I meant 
by "timeout" was actually "timeout value" - ie. a timeout value of 2 
hours would imply that a session was considered timed-out after a 
period of exactly 2 hours. Changing "after" to "during" changes the 
meaning of timeout - I like your definition better, but it may well 
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 
> 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'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 
> 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.

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

Thanks again,

- JohnK

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]