[cap-talk] Scope/span of capability systems

[David-Sarah Hopwood]

Marcus Brinkmann wrote:
> David-Sarah Hopwood wrote:
>> Fine, then say "standards-based environment".
> 
> I wouldn't argue with that at all.
> 
>> 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.
> 
> I am surprised that you would be satisfied with HTTPS-like interoperability,
> because that is almost entirely restricted to client-server exchanges.  Two
> HTTPS servers from different domains don't interact.

I meant, similar interoperability to HTTP over TLS between whatever peers
are involved in the protocol.

> Do you think that it would/should/could be possible to move capabilities from
> one web application service to another hosted by a different company?

Of course that would be possible. The whole point of a cap IPC protocol is
to allow the transfer of capabilities between subjects.

[...]
> My main point, which has now been blown totally out of
> proportion, is a very simple one: It's nice that capability systems don't
> have [the Confused Deputy problem], but we can't use a single capability
> system for everything, so the confused deputy problem will stay with us.

No, because if two capability systems, even of significantly different
designs, are bridged by making them support a common IPC protocol
(perhaps in addition to their native protocols), then the Confused Deputy
problem is also solved for cross-system requests.

-- 
David-Sarah Hopwood ⚥