Clarifying validity times in profile proposal

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

I don't expect this will change anybody's mind, but before we get into the
proposal for the SSO profile tomorrow, here's a snippet of what I was
actually proposing with all the potential timestamps. I also agree with
Conor that post-dating (using NotBefore) is probably not of much use in this
context and perhaps should just be profiled out.

<Response IssueInstant="">
	<Assertion IssueInstant="">
		<Conditions NotOnOrAfter="">
			<BindingCondition NotOnOrAfter=""/>
		</Conditions>
	</Assertion>
</Response>

Conor's use case of potentially storing signed assertions in a smarter
browser might argue for discontinuing the reliance on IssueInstant in
general, since it could be long since elapsed in that case, and also because
we don't need two ways of doing the same thing. Seems like if you have a way
of doing what's needed for browsers that will work for non-browsers, that's
better than having different ways.

In this world-view (apparently a world of one), Conditions/@NotOnOrAfter is
the time at which the data in the assertion becomes unreliable. That means
attributes become invalid and also means any SP sessions initiated on the
basis of an authn statement should be refreshed (what ID-FF does with
ReauthenticateOnOrAfter).

Meanwhile, the BindingCondition attempts to impose constraints not on use of
the assertion in general, but on the acceptability of the assertion in the
message context in which its delivered (again, I view the assertion as a
payload, the "message" in SSO is always a Response). In this case, it's a
constraint on the latest time at which the assertion can be delivered in a
Response. One could call it a ProtocolCondition, I suppose.

It's also the case that my idea for BindingCondition was that it just
duplicated information that would probably be in the protocol/binding layer
already, and it was just a hack for the double signing problem. This would
argue that Response wants a NonOnOrAfter attribute if the goal is to say
"don't accept the Response after X".

My major problem seems to be that nobody but me thinks of this "other
timestamp" as a property of the Response rather than the Assertion. I don't
see myself changing my mind about that, since I've thought about this a
whole lot in the last two years, but mechanically speaking, it's a plain
fact that if the bits are there, it doesn't matter what they're called so if
everyone else is already doing something, I'll change to fit that as long as
the obvious need here for clarity is addressed.

I will say this though...we need better text about NotBefore/NotOnOrAfter
and we need to say either that they mean nothing in the absence of a profile
or add more profiles to define them for more general uses other than the SSO
piece, or something. I guess I can accept the argument that a SSO assertion
is some special beast (even if I disagree, I think it's only the packaging
in a Response to an AuthnRequest that makes an authn assertion apply to that
use case). But then we need to address the other instances where assertions
might come to be.

-- Scott