atom feed7 messages in [security-services] Proposed DoNo...
FromSent OnAttachments
Hal LockhartOct 28, 2002 6:34 pm 
Scott CantorOct 31, 2002 9:32 am 
Hal LockhartNov 4, 2002 10:31 am 
Scott CantorNov 4, 2002 3:01 pm 
Hal LockhartNov 5, 2002 8:17 am 
Scott CantorNov 5, 2002 6:08 pm 
Philpott, RobertNov 6, 2002 5:03 am 
Subject:RE: [security-services] Proposed DoNotCache Condition
From:Hal Lockhart (
Date:Nov 5, 2002 8:17:34 am

Title: RE: [security-services] Proposed DoNotCache Condition

Every time you make an Authorization decision you are relying on the contents of the "SSO Assertion".

Well, in an indirect way that's true, but at least as I implemented it, I don't hold on to the assertion once the session is established, since the lifetime of the session can't be related back to the assertion anyway

But the SSO Assertion can contain attribute statements. Since Authorization decisions may be based on those attributes, it would be nice to know that they are expected to change soon. However, this is not the use case I am really interested in. (see below)

That's why I wondered if there was a specific use case in mind for this idea of caching an invalid (condition-wise) assertion.

I agree that this is absurd on the face of it.

Certainly if the definition of invalid is really context-dependent, then having a context-independent way of saying "whatever you do, don't keep this around" might be useful.

The use case I have in mind is an Authorization Decision Assertion which is derived from a policy which is time-based or otherwise volatile. Currently this is only available via the SOAP binding, but could be defined in other Profiles in future.