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

Best regards.  Tim.

-----Original Message-----
From: George_Robert_Blakley_III@tivoli.com
Sent: Wednesday, January 31, 2001 2:09 PM
To: security-use@lists.oasis-open.org
Subject: Notion of session: picture

I got to thinking visually and produced the following .ppt diagram of what
the model for our specification
looks like in my mind.

I've included core tokens, how the flow from services to applications
through request/response XML protocols,
and how they are transmitted via protocol bindings from one application to
another.  I've also included in
dotted lines my notion of the two places where a notion of session would be
appropriate -- one in the
protocol binding layer (specified by us) and the other in the pre-existing
communcations protocol infrastructure
(specified by others and relied upon by us).

I've also distinguished visually between "tokens" which are just the raw
assertion, and "bound tokens" which
might also be signed etc... in order to protect them appropriately for
their environment of intended use (this was
the substance of my discussion about making signatures optional on the main
mailing list).

I hope the diagram is helpful.

I'm attaching both the .ppt source and a .pdf

(See attached file: OASIS-model.ppt)
(See attached file: OASIS-model.PDF)


Bob Blakley
Chief Scientist, Security
Tivoli Systems, Inc.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC