Session Concepts

[Hal Lockhart <hal.lockhart@entegrity.com>]

I believe that the confusion about sessions stems in part from the fact that
there are more than 2 parties involved. It seems to me there are always at
least three and in the Jamcracker usecase, four.

Let's start simple by considering just three. If we can agree, we can extend
it to four or more.

I will (temporarily) adopt Bob's terminology: Asserting Party (AP), Relying
Party (RP) and User. In a web environment, the User is making a HTTP
request. In a transaction message exchange, the User is essentially the
author of the transaction message.

The User is asking the RP to perform some action.

The RP trusts the AP to tell it something (assertions) about the User that
it can use to decide whether to perform the action.

Note that the assertions that flow from AP to RP can go directly (push or
pull) or can be given to the User (push) to forward to the RP.

When the assertions flow via the User, there is an opportunity to depend on
the communications mechanism from the User  to the RP to bind the assertions
to the requests. Examples of this are web cookies and sending assertions in
the same email as a transaction message.

When the assertions flow directly from AP to RP, there is no such
possibility, so some other means must be used to bind the assertions to User
requests. One way to do this is to bind the assertions to the User for some
period of time and accept the convention that all requests made by the User
during that time are associated with those assertions. Another approach is
to bind the assertions directly to each request. These are not mutually
exclusive. For example, which method is used could depend on the choice of
request protocol, binding or both.

I will call the Jamcracker/Moses session concept a User Session. A User
Session represents some (potentially distributed state) about a User's
interaction with one or more RPs (and possibly APs). In the Jamcracker
model, the parties to the session attempt to maintain some level of
synchronization about the session state. It is quite possible that assertion
information is only transmitted to each RP once during a session. In this
model it is natural to associate the assertions with the session and
therefore with all User requests for the duration of the session.

I will call the Bob Blakely session concept an Assertion Session. 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.

As I understand it, User Sessions could be implemented without implementing
Assertion Sessions if assertions are only passed once during a user session.

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? Clearly the
RP has to manage some state (assertions, timestamp) associated with the
reference. You may not have to support explict session end requests, but you
probably have to time it out, in case the User never sends you a request.
The only real difference in supporting a session is that after you receive a
request from the User, you don't immediately discard the state.

Does this make any sense?

Hal