Shibboleth Developers

[Scott Cantor <>]

I don't have any argument with Bob or David on the session issue. The
in-memory approach has some advantages over the database, but it creates
some session churn if the Java VM fails, and using a self-contained
handle is probably the best solution, provided it's efficient to decode.

> I think the most concrete question is whether the Attribute 
> Authority in the Shib scenario needs access to the entirety 
> of the authentication assertion in order to properly answer 
> an attribute query.  I am inclined to say that it doesn't.

I don't think it does. I guess an AA might want to see a signed message
from its own site that validates the handle somewhat, but if you encrypt
data into the handle, you get a similar effect. I can't think why it
would care about most of the miscellany in the statement element (IP
address, authn method), but if it does, it can either maintain that
state or encode it into the handle.

> A related question is whether the attribute query can simply 
> include the authentication assertion by way of identifying 
> the subject.  I'm pretty sure this was proposed, and 
> supported by the schema at some point, but it seems to me 
> that this is not possible with the current schema.  Am I 
> missing something?

I guess you could put the assertion inline as SubjectConfirmationData.
Since I barely understand the whole SubjectConfirmation thing, I can't
really say if that's appropriate.

> A more general question is whether the HS will want to save 
> some state about user authentication in order to support what 
> SAML folks like to call "dynamic sessions", aka "rich 
> sessions", supporting things like logout-from-all-apps, 
> cross-app inactivity timers, etc.  One answer to this is that 
> this is really local WebISO functionality rather than HS 
> functionality.

Well, I think it's both. But it seems like anything that's reliant on
such state could store that state in the handle or a separate cookie and
still not have to maintain it. I don't know exactly how the proposed
solutions for that stuff work. I assume they have to do some cross-talk
between servers to inform each other about the logout event?

Personally, I never viewed it as all that valuable. Explaining how to
close a browser seems a lot easier to me than explaining some kind of
application-level mechanism on a page. And unless it's on every page,
it'll never get used anyway (notice that the Passport icons are in fact
on every page...). Hmm, I sense a proliferation of flying pigs...

> Anyway, I'm inclined to think that designing a self-contained 
> handle would be a good thing.  I have some more specific 
> ideas on how to implement this.

Excellent, just send in your diffs... ;-)

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--