RE: [security-services] Proposed DoNotCache Condition

[Hal Lockhart <hal.lockhart@entegrity.com>]

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.

Hal