RE: Session Management Use case, scenario and issues

["Mishra, Prateek" <pmishra@netegrity.com>]

David,

the requirements focus on communicating "logout" and 
"timeout" between two security domains supporting
a federated session. I would also 
suggest a "session active" message (a kind of 
"keep alive" message) between
the two security domains. It seems to be complementary
to the two proposed messages.

- prateek



-----Original Message-----
From: Orchard, David
To: UseCaseList
Sent: 2/17/01 3:48 PM
Subject: RE: Session Management Use case, scenario and issues

I have created another version of the session management use cases.  

Changes: 
. I put back all of the issues, even if I disagreed with them being
associated.  I added commentary to indicate such.  The numbering now
matches
the original section.
. I introduced the notion of requirements nomenclature in addition to
issues, ie CR-3-1:UserSession:  [OSSML] shall support web user
session(s).
. ensured every issue/req had a possible resolutions section, even if
repetitive.
. Cleaned up much of the text.

Ed note: I think the overlap between issues and requirements is a bit
painful for the use case/reqs team.  Every requirement we have may be an
issue, and every issue probably is a potential requirement.  We may want
to
use the issue notation for the rest of the work, but focus just on reqs
for
our group.

Cheers,
Dave



> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: Friday, February 16, 2001 2:12 PM
> To: Orchard, David; UseCaseList
> Subject: RE: Session Management Use case, scenario and issues
> 
> 
> Thanks, David.
> 
> My specific comments are inline in blue text in the attached 
> doc.  Here are
> my hi-level comments:
> 	- There are issues that are on the issue list that are 
> not in your doc.
> 	- The issue numbering is inconsistent with the 
> numbering in the issues doc.
> That will cause confusion.  What may happen is that as you 
> investigate this
> issue group, you discover additional issues, which should be 
> added to the
> end of the list.  Propose resolution text for voting for 
> these new issues as
> well if you can.  If we are unable to resolve them via vote, 
> they will be
> added to the issue list of the next strawman.
> 	- We need to propose resolutions which can be voted on 
> for each issue.
> 
> Regards,
> 
> Darren
> 
> 
> 
> > -----Original Message-----
> > From: Orchard, David [mailto:dorchard@jamcracker.com]
> > Sent: Thursday, February 15, 2001 5:36 PM
> > To: 'security-use@lists.oasis-open.org'
> > Subject: Session Management Use case, scenario and issues
> >
> >
> > Apologies for the slight delay, here is what I have been 
> able to come up
> > with.
> >
> >
> >
> > Dave Orchard
> > XML Architect
> > Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
> > p: 408.864.5118     m: 604.908.8425    f: 408.725.4310
> >
> > Named to Red Herring's list of 100 Most Important Companies:
> > www.redherring.com/mag/issue79/herring100/jamcracker.html
> >
> >
> 

 <<OASIS Session Management scenarios2001-02-17.doc>>