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