I don't exactly understand what you are proposing, but discussions
the Browser/Artifact Profile, made it clear that the
the the latest time you can BEGIN to use the contents of an
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"
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
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.