[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] AI 60 - Dynamic Session Material
Steve, Thanks for taking the time to review the document! Comments inline below: 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]