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


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

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

Subject: RE: Ballot Attached - Group 3: Sessions

I agree that it is a good thing that the session management
topic has "broadly" been accepted as within scope without
explicit reference to overloaded terms such as logout, timeout,
keep-alive etc.

I think
it would be useful to have a discussion of an appropriate model
for sessions within SAML before trying to solve "problems"
such as logout, keep alive, time-out. Once we have agreed
on a model we could characterize these issues more precisely.
I would propose the following starting point:

(1) A session is "owned" by a security domain (session controller?)
and has a unique identity (session key).

(2) Each session is managed by the owning session controller and
is completely under its administrative authority.

(3) Session controllers generate "session change" events or notifiers.
There are some "session change" events that are standard, such as:
logout, time-out, keep-alive, administrator-logout, etc.  There may
be some others and there needs to some way to support these as well.

(4) "Session Change" events or notifiers may be exchanged (e.g.,
the usual push versus pull model) between security domains.

Look forward to some discussion on these points. I have previously
published a note summarizing some of the different notions of session
discussed on this list.


- prateek mishra

> It now looks like a good thing because some people appear to 
> want session
> mgmt, but not logout and/or timeout.  This gives us a 
> mechanism to approve
> the topic, and then dive into the details of what these mean. 
>  If we had
> done what I suggested, then we might not have approved 
> session management,
> even if sufficient people wanted some form of it.  Now that 
> we have approved
> the concept of session management, we can start trying to 
> figure out what
> the detailed requirements and design..
> Cheers,
> Dave
> > -----Original Message-----
> > From: Evan Prodromou [mailto:evan@outlook.net]
> > Sent: Tuesday, February 27, 2001 12:14 AM
> > To: UseCaseList
> > Subject: Re: Ballot Attached - Group 3: Sessions
> > 
> > 
> > >>>>> "EP" == Evan Prodromou <evan@outlook.net> writes:
> > 
> >     JH> rationale: I believe this is subsummed within the topic of
> >     JH> [UC-3-1:UserSession] and we should deal with it 
> explicitly in
> >     JH> that context.
> > 
> >     EP> So, I'm kind of confused by this rationale.
> > 
> > Actually, on review, I've noticed that it was actually 
> David's idea to
> > remove these requirements. I still don't understand why, but I see I
> > was directing my questions at the wrong person.
> > 
> > David: why? B-) I find this even more puzzling, because those were
> > req'ts pulled out of ITML and posted to this list. Was 
> there a reason
> > you didn't want the explicit logout, timeout, etc. requirements?
> > 
> > ~ESP
> > 
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: 
> > security-use-request@lists.oasis-open.org
> > 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-use-request@lists.oasis-open.org

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

Powered by eList eXpress LLC