Size of client-side sessions

[Rod Widdowson]

> Mostly done, the Authentication and Sessions topics have been updated.
> 
> https://wiki.shibboleth.net/confluence/display/IDP30/Software+Design

I read through those two sections again today and, given that I am not
intimately aware of the problem space, it all seems to hang together
beautifully well.  Equally my ignorance makes it sure that there are some
very subtle nuances in what is (by necessity) a very nuanced design, which a
first reading hasn't thrown to light.  Nonetheless I have no doubt that when
we start plumbing in the flows the reasons for much of the details will
become apparent as will the subtleties.  I am really looking forward to
taking part in that work and thus learning more about this design 'hands
on'.

A few immediate observations and/or questions do come to mind:

Firstly, with respect to identity switching: I note that this is explicitly
*not* treated as a failure and I'm guessing that this is because it is not
the principal's fault that the identity has switched.  Thus to fail anything
would be wrong.  I assume that something would be logged, and AFAICS the way
that the design works is that things "just work".

Secondly I tried to fit some of the (SAML) flows that I understand into this
framework and it all "just works" (no surprise), except I am unsure how
Attribute Query fits in. You explicitly do not mentioned as a motivation for
much of the session resolver complexity although the NameID->Session mapping
seems to be exactly what is needed.  Therefore I am assuming that it is
dealt with in some other way.  We did discuss for a while treating
NameID->Session as an Authentication flow, is that the idea here?  
It also strikes me that there are in fact two different cases - one where
the session is pre-existing but not locatable via a cookie because we are on
the backchannel and another where there is no pre-existing session (Stored
ID, or anonymous query).   Bottom line, I'm interested in how this all
works.

As a very minor question, is the SAMLContext targeted at the HoK profile
(which I only skimmed and a long time ago) or is that different again?

Finally, a non-question - more of a worked example to see if I understand.
As you have been working on cookie storage (congratulations on the size by
the way, and also the bit where by update and recovery can happen without
writing the record) I have been thinking about the whole issue of session
cookie non destruction on browser shutdown.  I was vaguely convinced that by
putting a date into the cookie something magical could be done to age out
old cookies and hence sessions (i.e. have another layer of control at that,
lowest, level).  Having read and partially digested the Session document it
seems that I was wrong:  There is more than enough control in the Session
layer to age out sessions making the need to control this at a lower level
redundant.    
I suppose that there is a question though:  Do you believe there is anything
we can do in the IdP Design to handle these sorts of buggy browsers?  It
strikes me that your idea of being able to say "And here are all the
Sessions you have not been logged out of" might be useful - even if just for
didactic purposes.

Thanks again

Rod