[cap-talk] Capabilities for immutable data

[David Wagner]

David Barbour  wrote:
> 2. granting a capability is a sufficient condition for granting the
> associated permission
> 3. holding a capability is a sufficient condition for exercising the
> associated permission
> 
> Your decision to 'trivialize' 2 and 3 by saying that a sealed value has no
> associated permissions doesn't result in a useful analysis.

If we want to make 2 and 3 more precise and useful, don't we need
to define what is the permission associated with a given capability?
Is that well-defined?  Is the permission associated with a capability
anything more than "permission to invoke any method on the object"?
If that's all it is, then statements 2 and 3 are valid for a sealed box.

> But there's a mistake in reasoning: when people talk of the object
> capability security model, why it is good, they are referring to a whole
> body of research that depends on the broader set of features for
> capabilities - such as those attenuation, revocation, auditing patterns.

I would be happy to treat this as an engineering property of
object-capability programming, not of an individual capability.  Thus I'd
prefer to say something like

5'. Object-capability programming tends to make it easy to attenuate
authority via common capability patterns (e.g., facet pattern,
revocation).

Note that there are many reasons why it may not be easy to attenuate
authority.  e.g., if the libraries are not designed with attenuation in
mind, attenuation may be difficult.  If the language does not support
"noSuchMethod", the membrane pattern may be difficult to implement,
at least in general.

>> If you perceive that there is an existing consensus definition, was
>> it written down anywhere in a way that makes explicit how it treats
>> these cases?  Can you share a citation to where that was written down?
>
> Consensus is not the issue. Disagreement about definitions is a problem, and
> - even if you are well-intentioned - introducing yet another definition is
> just paving a road in the wrong direction.

I don't understand yet.  Are you suggesting that there exists
a written-down definition that takes a clear stance on this issue?
If so, which?  I think I mentioned that my memory is that the definition
in MarkM's thesis is not very clear on this point, and that feels like
the closest the field has to an existing consensus definition of the
object-capability model.  If that's not what you had in mind, what is?

I agree that disagreement about definitions is less than ideal, but that
fact doesn't tell us which definition to adopt.  I don't think we're
talking about introducing yet another definition.  Rather, I think we
are working out how to clarify a point that's currently not clearly
unambiguously specified by the existing standard definition of the word
"capability".

>> I guess I don't understand.  In Java, both of the following
>> variables hold a reference:
>>
>>    Reference<Sealed<T>> r;
>>    Sealed<T> s;
>
> You confuse presentation with representation. The question is: what
> abstractions do 'r' and 's' present to the user?
> * 'r' presumably has a 'dereference()' operator that returns a Sealed<T>.
> The user doesn't know whether it will return different values at different
>  times.
> * 's' has no operators, but may be passed to the appropriate unsealer to
> obtain a T. Being a sealed 'value', the value returned from the unsealer is
> always the same (though Java's type system doesn't enforce this constraint).
>
> The fact that 'r' and 's' happen to be represented in Java as references to
> objects is immaterial to the abstraction they present to the user. That's
> just semantic noise [1], not essential to the model. In another language,
> the noise might be different.

OK.  I accept all of that.  I don't think it contradicts the particular
statement I was making, but the particular statement I was making probably
wasn't helpful, so I'll drop it.