Session issues

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Here are a few comments on sessions, taken from the "issues" document
sent out by Evan in [0].

[0] http://lists.oasis-open.org/archives/security-use/200102/msg00045.html

> ISSUE:[UC-3-01:UserSession] AuthXML includes an entity called a
> "session" that is not specified by any of the use cases in Straw Man 1.
> What is a session, and what use case scenarios should be developed
> to specify the need for sessions and their use?

As was pointed out by Prateek [1]. Sessions are just another form of
assertions which may have some standard elements such as start time,
end time etc.
[1] http://lists.oasis-open.org/archives/security-use/200102/msg00012.html

The essential characteristic of a session assertion is likely to be
that it captures transient information about the principal/user (logon
time, contents of shopping cart). The assertion may only be "good" for
a relatively short period of time. This implies a need for an
"end-time" to the assertion, but that is going to be needed for other
kinds of assertions (they may have longer validity periods).

You need to be able to bind a session assertion to a principal/user,
but again that is not a requirement that is unique to sessions. You
may need to have multiple sessions at any given time for a user
(e.g. if their are logged on twice to a site), this implies a need for
a session identifier. However, we probably need assertion
identifiers. (The only problem I see is that if you want to issue a
second assertion about the same session, then re-using the assertion
identifier as a session identifier might not work. This would be the
case if assertion identifiers are required to be unique - a reasonable
requirement in my opinion.)

In summary sessions don't seem to require other mechanisms. This was
pointed out by Bob Blakely in [2]. As was pointed out by Prateek [1]
they may have some standard elements. Uses cases showing transient
(session) information being passed between asserting parties and
relying parties would help us to define these elements.

[2] http://lists.oasis-open.org/archives/security-use/200101/msg00048.html

I think it would be helpful to have the following use case scenarios

1. Logon/Logoff (or sessionStart/SessionEnd)
2. Session keep alive (one site indicating to the other the user still
has a session/logon). Possibly combined with 1.
3. Session time out. (Possibly combined with 1.)

There are other kinds of transient information you might want to pass
between entities such as shopping carts. However, in the case of the
latter, I think it would be out of scope and a deep "tar-pit". Also
if the assertion framework is extensible (I hope it will be), then two
sites could devise their own extensions to transfer between them
arbitrary transient information about users.

> 
> ISSUE:[UC-3-02:ConversationSession] Is the concept of a session
> between security authorities separate from the concept of a user
> session? If so, should use case scenarios or requirements supporting
> security system sessions be supported?

I think the answer to the first question is yes, but I don't know that
they need a use case.

In Phillip H-B's core-assertions requirements document, I believe the
issue was captured thus.

<CoreAssertionsReqDoc>
[R-EfficientMessages] Should support efficient message exchange
Integrity checks such as digital signature can add excessive overhead
to messages.

[A-OptionalAuthentication] Authentication should be optional 
To Satisfy [R-EfficientMessages] Messages may omit authentication
altogether

[A-OptionalSignatures] Signatures should be optional 
To Satisfy [R-EfficientMessages] Messages may use a shared secret and
Message Authentication code for Authentication in place of digital
signature
</CoreAssertionsReqDoc>

The point being that an AP and RP could exchange assertions over a
secure session based protocol and avoid the cost of signing each
assertion.

I couldn't find the above from Phil's document in Stawman 2.

> 
> ISSUE:[UC-3-03:Logout] Should [OSSML] support transfer of information
> about logout (e.g., a principal intentionally ending a session)?
> Should a logout use case be added to an existing use case scenario, or
> should a new scenario about logout be added to the document?

This seems to me like a requirement for a particular element in a
session assertion. As I wrote above, use cases would help us to
identify what elements to standardize.

> 
> ISSUE:[UC-3-04:StepUpAuthc] "Step-up" authentication is when a
> receiving party refuses to accept an authentication from an
> authenticating party and asks for a higher level of
> authentication. For example, the RP can refuse password authc and
> require certificate authc. Should [OSSML] support step-up
> authentication? Should a use case be developed illustrating step-up
> authc?

I don't see that new mechanism or a special element needs to be
introduced to support step-up authentication. If I have an assertion
that indicates that the principal has authenticated in a particular
way and this is not good enough for me, then I re-authenticate with
stronger authentication. In the case of the web, I can send the user a
web page telling them what to do.

Not convinced a use case is needed either, although it might be nice
to demonstrate the power of the assertion framework.


> 
> ISSUE:[UC-3-05:SessionTimeout] Session timeout is an event that occurs
> when a security system invalidates a principal's session after a
> period of inactivity, without action by the principal. Should
> communication about timeout of sessions be supported by [OSSML]?
> Should a use case illustrating session timeout be developed?
> 

SessionTimeout seems to me to be something that should be allowed
within a session element. Again, I don't see new mechanisms being
needed, but it would be helpful to have a use case.

Nigel.