RE: Notion of session: picture

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

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
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?
>