Re: Session Concepts

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

On Sat, 3 Feb 2001, Hal Lockhart wrote:

> I will call the Jamcracker/Moses session concept a User Session.
> ...
> I will call the Bob Blakely session concept an Assertion Session.

I could well be missing something, but while at first I agreed with Hal
and several others that we seem to be talking about two different concepts
of "session" at two different layers of abstraction, I am now inclined to
believe that in fact we are talking about the same "session" but coming at
it from different directions.

A session is a bundle of state that supplies context for sequences of
operations.  It has security-related state, it has other kinds of state.
Normally we think of it as two-party (client-server), but it might have
many parties to it.  Bob B's note described how security assertions get
bound to a session (and whether as part of our work we need to create a
session structure to do this).  The AuthXML/etc interest in a session is
(I think) in how session state can be abstracted, packaged up,
transported, and injected into a new session.  So, same session, just
different operations being performed on it.

> Bob's concern (if I understand him correctly) is with the
> communication of assertions between the AP and RP. The Assertion
> Session is concerned with the possibility of an AP sending multiple
> assertions to the RP which describe the same User. If you implement
> Assertion Sessions, these are associated with a session and a request
> made by the User at any point in time is bound to the assertions
> received up to that point. Assertions might accumulate or replace
> their predecessors. If you do not implement Assertion Sessions, each
> Assertion must either be bound in some way to a request or the
> assertion and request must travel over the same path, so some
> enveloping protocol, e.g. TCP, can bind them.

To the extent I understand the above, this isn't what I got from Bob B's
note.

> My question to Bob is:
>
> In case 1a, explicitly scoping of assertion to a request, if the
> assertions pass directly from AP to RP, doesn't the AP have to provide
> the User with some kind of reference to present to the RP so the RP
> will know what assertions apply?
>
> Doesn't that imply doing most of the work of managing a session?

I think you're asking:  isn't there always going to be a "session" between
the AP and the user, so doesn't OSSML have to define and provide
facilities for managing that session?  My answer:  yes, a session-oriented
AP will require sessions.  How this session relates to application
sessions is a question that's a little too deep for me at the moment ...

 - RL "Bob"