the validity period thing

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

In our discussion at the Austin F2F, it was said (by Scott, more or less):
it is reasonable for an RP to want to know, when it receives attributes
(as part of SSO), how long to consider those attributes to be valid; and
further, to have this info provided by the attribute supplier as part of
the assertion; hence, it seems straightforward to have this "information
validity" be based on the NotBefore and NotOnOrAfter conditions which SAML
has, which appear to be precisely designed to express a general validity
period.  We talked about this a bunch Wednesday.  Here's how I think about
this issue.

SAML isn't X.509, but I still think the example of X.509 is useful in
figuring out how to think about this issue.  X.509 PK certs and attribute
certs both have not-before/not-after validity periods, which inspired the
SAML ones.  But these are *not* a guarantee to the RP that the info in the
cert is valid for that period (I mean really, how could they be, in the
case of a long-lived cert?).  The mechanism X.509 provides to RPs to
assess the continued validity of info in a cert is revocation (ignoring
any difference between classic revocation and real-time status checking,
which isn't relevant to this argument).  When an X.509 authority issues a
cert it agrees to provide continued info about the status of the cert
(including all the info in the cert) to the RP, and the validity period in
the cert states the life of this agreement.  In an orderly world an RP
would never have to process a cert that was beyond its validity period,
because well before that time it would have got a new one, or ceased to
have a need for the cert's info.

So an X.509 cert doesn't say "how long the info is valid", rather "how
long you can find out whether the info is valid".  An RP is on its own in
setting its policy about when cert-supplied info is stale and has to be
re-confirmed (via revocation checking), except in those cases where a
particular defined procedure (eg path validation) says "a cert used at
this point must be within its validity period".  But as we know, most
other defined procedures (like application sessions) don't refer to certs
at all except at initiation time.

The modern approach to this stuff (as found in SAML and other schemes) is
to say that we can avoid the apparent complexity of revocation machinery
by just issuing lots of short-lived assertions, noting that there's little
difference between providing a response about status of an issued
assertion and simply providing a new assertion with the same info; and
anyhow nowadays issuance is cheap and authorities will be online all the
time and well-connected.  So revocation isn't needed, but the tradeoff is
apps having to deal with short-lived assertions, and potentially with
things like updating the assertions that apply to live sessions.

Presumably one implication of the absence of revocation in SAML is that a
SAML authority does *not* (in general) have any obligation to maintain or
return status info about an assertion after it is issued.  If a client
queries a server about an assertion (by assertion id) and the server sends
a response that doesn't include that assertion (and doesn't suffer from
some other error), the client can't conclude anything about the status of
that assertion.  And there is no "assertion no longer valid" error or
response code (that I can see).  Of course, a particular
profile/application may impose this kind of requirement, eg SSO with
artifacts.

I think this helps to explain why assertion recipients would like to see
some content-freshness info supplied by a SAML authority in the assertion:
there's no other way to get it.  But I don't think that this changes the
obligation that an RP has to set its own policy on this.

So ... if SAML doesn't have revocation, hence a SAML assertion's validity
period doesn't mean what an X.509 cert's validity period does, then can
the validity period be generally used to set the useful life of the info
in the cert?  I don't think so; or, that is, I think there will be need
for app/profile-specific validity attributes to more precisely specify
times for particular kinds of utility.  I think the general validity
period has a generic use, as in X.509, as an overall sanity check: by this
time, throw this thing out, it aint gonna be good for nothing.  I think
our spec should have language recommending this function for this
condition, and recommending that app-specific conditions be defined to do
more app-specific constraints as needed.

If you believe all this you might also be inclined to think there's a need
for statement-level conditions, as we discussed a little bit at the F2F.
But that's a topic for a different message.

 - RL "Bob"