What is defensive consistency?

Alan Karp writes:
>I have always assumed that what makes two clients different is the
>capability they use to access the object.  Basically, if the
>capabilities the clients use could be separately revokable, then the
>clients are different.

The part I find tricky is that the server can't know what capability
was used to invoke it.  So what is the poor developer who has to write
the server code supposed to do?

Suppose we construct a caretaker that wraps access to the server Sam,
and we hand that caretaker to Alice.  Then, we construct a second
caretaker that provides independently revokable access to the same Sam,
and hand the second caretaker to Bob.  Now both Alice and Bob can invoke
Sam (until their corresponding caretaker is revoked).  But when Sam is
invoked, he cannot tell whether he has been invoked by Alice or by Bob.
Consequently, if Sam is invoked by a caller who breaches his documented
contract, while Sam is released from the contract for that one method
call, it seems like Sam can't tell whether he is released from the
contract for other method calls or not.

One possibility is that we can say that, since Sam doesn't know which
other method calls might come from the same client, Sam had better
assume the worst and respect the contract for all invocations that are
consistent with Sam's documented contracts.  This corresponds to the
case you mention of a server where every valid request must return a
valid result but an invalid result might not.

Another possibility is that Sam can declare loudly that he is going to
presume that all of his callers will use the same capability (and if
they don't, too bad for them).  In this case, any invalid request may
cause all subsequent requests to return invalid results, even if those
later requests are valid.

However, this view makes defensive consistency look narrower than I
originally thought, so I suspect I've missed something.