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


 -----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';
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

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.


> 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