[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Notion of session: picture
Bob, Tim, and Nigel, I see the key aspect of session management as the transfer of end-user sessions between federated web domains. This session transfer would be facilitated by the secure exchange of some kind of signed XML assertion which contains properties about a user's session (start time, authentication type(s), IP address, ...). Handling multiple concurrent sessions (Nigel's suggestion) makes sense to me, too. Another aspect of session behavior which should be considered is logout - particularly the ability to notify partner/federated domains of a user's explicit logout (so that the partner sites can close/void any sessions they have for the user). I, too, agree that concepts Bob's diagram seem to be orthogonal - sorry for piling on, Bob. I also don't think I fully understand it, though, and would benefit from a scenario. Darren -----Original Message----- From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com] Sent: Thursday, February 01, 2001 1:51 AM To: 'Tim Moses'; 'George_Robert_Blakley_III@tivoli.com'; security-use@lists.oasis-open.org Subject: RE: Notion of session: picture Bob and Tim, I agree with Tim's characterization of a session. I had trouble understanding the requirement underlying Bob's picture and description. Perhaps I am struggling with the abstract and a use case or scenario would help? Certainly at my current level of understanding, I also agree with Tim that Bob's characterization seems orthogonal. I think we should also add the requirement that a principal can have more than one session. This allows scenarios like A to have multiple concurrent sessions with B, as well as A having a session with a third party C concurrent with its session with B. Nigel. > Bob - My reading of the AuthXML content on "sessions" was that it > intended to support scenarios such as this ... > > A Principal has conducted a session with Application A. There is an > accumulated state associated with that session, and this is to be > transferred to Application B (presumably state accumulated in > Application A is meaningful to Application B). > > The state is not a property solely of the Principal, so a name > assertion or entitlement assertion is not entirely appropriate. This > state is a property of the session, so a session message was used. If > we are combining the two specifications and preserving their > capabilities, but extracting any "assertions", then we need a "session > assertion". > > This seems to be orthogonal to your discussion of scoping assertions > that are directly associated with the Principal. No? >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC