RE: [security-services] Proposed DoNotCache Condition

[Scott Cantor <cantor.2@osu.edu>]

>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 (for the reasons you're noting, the condition is used to indicate
one-time use and is very narrow).

I remember IDs for replay detection, but that's all.

IOW, I rely on the session, and the session's original construction came
from the assertion.

>However, when the Browser Artifact Profile was developed, the majority
view
>was to use the validity interval in the way I described as a
countermeasure
>against replay attacks. This, in effect established that the semantic
of
>this element is Profile-specific. I would like to define a semantic for

>DoNotCache which is Profile independent.

I guess I don't see it as being that different, based on my
interpretation of the purpose of the SSO assertion as establishing a
session with its own properties. Subsequent to the validity period
expiring, the assertion can't be used for that purpose (session
establishment) and so caching it serves no purpose.

I don't remember reading anything in the document (at least on the POST
side) that contradicts that interpretation, and either way the effect is
the same, but I guess it leads to different conclusions as to the
profile-specificity of NotOnOrAfter.

>Also, there seems to be a strong view in the SAML TC that ultimately it
>is up to the relying party to determine what information to rely on.
The
>asserting party can attach caveats, such as Audience Restriction, but
>ultimately the relying party does what it wants.
>
>This seems to me to be quite different from the X.509/PKIX philosophy
>where they have a fetish about performing the signature validation and
>verification algorithms as defined in the specifications. But perhaps
>there will be little difference in practice.

I would agree with that, the rules for consumption seem to be looser and
more application-specific. That's why I wondered if there was a specific
use case in mind for this idea of caching an invalid (condition-wise)
assertion. 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.

-- Scott