[cap-talk] Scope/span of capability systems

[David-Sarah Hopwood]

Marcus Brinkmann wrote:
> David-Sarah Hopwood wrote:
>> Marcus Brinkmann wrote:
>>> Bill Frantz wrote:
>>>> marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) on Thursday, February 26, 2009 wrote:
>>>>
>>>>> Capabilities can only survive in an isolated, homogeneous environment.  I
>>>>> think that this is a serious limitation, which in my opinion severely
>>>>> restricts the applicability of capability theory.
>>>>
>>>> This statement is wrong on the face of it. Any data-as-capability (e.g.
>>>> WebKeys, SPKI authorizations, etc.) can be securely passed through systems,
>>>> such as encrypted email, that are completely unaware of capabilities, let
>>>> alone the precise capability system they represent.
>>>
>>> That is just a transport issue, and not what I meant.  If you send me a capability-as-data
>>> over any channel, what can I do with it?  Nothing useful, until I feed it back into a system that
>>> accepts the data as a valid capability for anything.  For that to happen, the system must
>>> somehow be in rather intimate contact (and if only by following the same P2P protocol) with the
>>> system from which the capability originated.  It does not need to be the same system, but surely
>>> all such systems form a common domain.  This domain is the isolated, homogeneous environment I am
>>> talking about.
>>
>> Your definition of an "isolated, homogenous environment" would apply just as
>> well to the world-wide web. I don't think many people would agree that this
>> is a useful definition; it seems quite misleading to me.
> 
> I accept that it applies to the web.  The web would be utterly useless without
> the standards that hold it together.

Fine, then say "standards-based environment".

If "capabilities can only survive in a standards-based environment",
then I don't see that as a significant limitation; certainly not one that
"severely restricts the applicability of capability theory".

> And we have some experience with how
> those standards work.  The more low-level the standard is, the better is
> compliance.  Compliance to TCP/IP, DNS, etc is very good.  With SMTP we
> already see some divisions, and HTTP compliance of browsers is the fabric of
> legends.  But it only gets really nasty once you enter the world of
> application services, where nothing interoperates and even the users have no
> control over what happens to their data.  Take for example OpenID: Everybody
> wants to be a service provider, but nobody wants to accept other service
> providers.  Why should the situation be different if capabilities are
> introduced into the mix?  The incentives just are not there.

Capability-based IPC is at a similar position in the protocol stack to
HTTP (one layer above secure transport). For cultural reasons, designers
and implementors of capability IPC protocols are likely to be somewhat
stricter and more careful about interoperability than is the case for
HTTP -- but if a capability IPC protocol were to "only" achieve similar
adoption and interoperability to HTTP over TLS, that'll do fine. Yes,
cap IPC protocols are more complicated than HTTP, but not substantially so.

> In a world where we can't even agree on compatible data formats, I see little
> chance to agree on compatible capability interfaces, which have potentially a
> much higher degree of complexity.

Well, we'll just have to prove you wrong, then.

-- 
David-Sarah Hopwood ⚥