[e-lang] What is defensive consistency? Client vs. server side, client distinctions via invoked capability

[Jed Donnelley]

On 11/2/2007 12:36 AM, David Wagner wrote:
> Dean Tribble writes:
>> How's this for a definition: A client is  a holder of the capability with an
>> independent interest from the holders of the capability. That's a very
>> general distinction, but I think that's OK. Within a security domain, I
>> would still want to be able to separately analyze (the reliance sets of)
>> multiple clients of the same object.
> 
> That's great.  Very helpful!  I like this way of thinking about it.

I've read through this thread and thought I'd comment on the beginning.

> Unfortunately, this feels a little bit like an "aspirational" goal.
> It describes what we should strive to achieve, but what does it mean
> for the programmer who has to write the defensively-consistent code?
> If a server is invoked twice, how does it tell whether those callers
> have independent interests (or even be the same client invoking the
> server twice)?

Why should it matter to a server whether callers have independent
interests?  It seems to me that a service should clearly document
how it operates.  It should document how much, if any, state it
maintains and how invocations operate on that state.  This seems
to me gets to the core of the a) / b)  [ c)?] distinction:

> a) Every method call stands on its own. ...

> b) All method calls to a single instance of the server are assumed to
> come from clients with a common interest.

Every call does stand on it's own except for any documented
internal state.  It's up to the callers to manage how the
capability to the service is communicated and how common
or not the interests of the clients are.

With regard to:

> c) The server object might build some special method of
>    authenticating its clients.

The recommended method of "authenticating" clients is by
separate capabilities.  Servers can give out new capabilities
as needed for this purpose.  There's nothing "special" about
that as far as I know.

Regarding:

> For instance, clients might pass a Token to prove who they are.
> Then the server might assume that all method calls that refer to the same
> token have come from a single client (or a set of clients with a common
> interest).

I believe the above is a bad idea.  The above path leads
to separation of designation and authentication (via the
above "Token"s) and to the very set of problems that the
capability paradigm is successfully able to avoid.  Tokens
to "prove who they are" leads to ambient authority by
'identity' (Token).

Consider a simple case - the distinction between a file (segment)
capability and an "open file" capability.  The later might
include a pointer state to support sequential reads or writes.

Given the documentation for such capabilities, clients would
be advised to create separate "open file" capabilities for
distinct clients that want to be able to assume that they
can step sequentially through the file (segment) - e.g. that
have separate "interests" in that sense.  This is a client
side issue, thought the internal state on the server side
suggests where to draw the boundaries in the clients interests
(shared file capabilities, less shared "open file" capabilities).

> Consequently the failure of any such caller to establish
> the documented preconditions releases the server from all obligations
> regarding all subsequent method calls mentioning the same Token.

I have to admit that I'm a bit lost when it comes to the
notion of "documented preconditions".  Perhaps an example
would help?

> And of course the server would need to document which of these three
> types of defensive consistency it provides, so that clients can know
> what they can rely upon and so they can know how to use the server safely.

The server indeed needs to document how it operates, including
any internal state it keeps.  However, I'm afraid I don't
understand the value of the "defensive consistency" term
as it relates to the server.  To me it is the clients that
must deal with the issues of defensiveness.  Again perhaps
I'm missing a relevant example.

> I wonder if perhaps my intuition has been poorly served by focusing on
> the case of building a defensively consistent object.

That seems to me so, but until I hear of an example where
such defensive consistency on the server side is relevant,
I can't comment.

> Perhaps I should
> be thinking about a defensively consistent subsystem, which might be
> composed of multiple objects and which might expose multiple facets
> to the outside world.  Then perhaps we can distinguish method calls
> according to which facet they are invoked upon, enabling a richer set of
> options for what type of defensive consistency the subsystem provides.
> Does that sound right?

That is certainly my suggestion.

Is that a more typical case?

You can design any case you wish, but doing authentication by
separately invoked capabilities is the approach I've found
most effective.  Doing so enables all the power that capabilities
as parameters have proven effective at providing for so many years.

--Jed  http://www.webstart.com/jed/