[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: the validity period thing
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"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]