RE: [security-services] Proposed DoNotCache Condition

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

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

> >I don't exactly understand what you are proposing, but discussions
> around
> >the Browser/Artifact Profile, made it clear that the
> NotOnOrAfter time
> is
> >the the latest time you can BEGIN to use the contents of an
> assertion,
> not
> >the time you must STOP using the contents.
>
> Ah, I don't think I heard any of that, so I was definitely thinking
> about it the other way. In the SSO case, you're really "done"
> using the
> thing once you've initiated the remote session. I don't think of that
> session as "continued use of the SSO assertion", but maybe that's just
> me.

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

> In the case of attribute assertions in Shib, for example, the time
> condition is used explicitly to tell the relying party when to throw
> them out and query back again. That seems very natural to me.

I agree. When the core spec was originally developed, I assumed that this would be the uniform semantic for all assertions. This is consistent with the interpretation of X.509 certificates, including Attribute Certificates, which are quite simliar to SAML Attribute Statements.

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.

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.

Hal