Re: Session Concepts

[Jeff Hodges <jhodges@oblix.com>]

My feeling is that we're using the term "session" in reference to stuff thay is
occuring orthogonally at distinctly separate layers of abstraction. This seems
to me to be borne out in reading Hal's, BobB's, Tim's, Nigel's messages. 

It seems to me that a big part of this difficulty is that we're using the
unqualified term "session" to refer to all of these -- separately or in
combination -- and we're thus confusing ourselves. Thus I think Hal's proposing
of terminology ("user session", "assertion session") is apropos. 

The below discussion concerns largely what Hal is terming the "user session",
tho it has ramifications for assertion sessions.

JeffH
-----

In some cases, distinctly separate, authenticated (or not) entities may be
communicating at each distinctly separate layer of abstraction. In other cases,
the separate layers' identities may be based upon a given source identity.

An example of this is the session behavior one sees when layering LDAP, with
it's distinct notion of session, on top of TLS/SSL, with it's own distinct
notion of session. 

I worked out a combined session state diagram for this as a part of the work on
RFC 2830. It's available here..

http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-1999-12-14.html

It embodies examples of both of the cases -- the one where distinct layers have
their own distinct notion of session, and the other where they are blended. 

LDAPAssociationStateDiagram illustrates there being three overall "anonymous"
states, and five overall "identified" states, at a gross level of abstraction.
But, for example, state 8 is a case where the notion of session at the LDAP
layer is distinctly separate from the notion at the TLS layer. 

However, we took advantage of the SASL "EXTERNAL" mechanism, and allowed for
the client to assert that the session at the LDAP layer base it's
"authorization identity" on the "authentication identity" established in the
TLS context. Thus one can move from state 8 over to state 10. Both states 8 and
10 are "identified" at a gross level, but their AuthzIDs are distinctly
different. 

This also brings up the distinction between AuthzIDs and AuthnIDs ("Auth ID" in
LDAPAssociationStateDiagram). I hate to complicate things, but so far this
"session" thread has seemed to assume only one overall session identity. I
think we're going to have to carefully think about whether we need to follow
the SASL (RFC 2222) and LDAP (RFCs 2829 & 2830) models of having sessions
comprised of distinct AuthnIDs and AuthzIDs, and what all does that mean. 

And then, on top of it all, it seems to me that we may well be transferring
object blobs that have embedded "assertion sessions" that once again may or may
not be orthogonal to the "user session" notion at the transfer protocol (and
below) layer(s), and we'll have to figure out the implications for all that. 

-----
end