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

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