[cap-talk] Scope/span of capability systems

[Marcus Brinkmann]

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.

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?

Maybe you are not interested in such interactions, but if not, then that's
exactly the limit I was talking about, and you may just not be pushing it.

Remember that this thread started with the confused deputy problem and the
claim (or definition) that the confused deputy problem can not occur in
capability systems.  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
that problem, but we can't use a single capability system for everything, so
the confused deputy problem will stay with us.

But the corollary is: if we need and can solve the confused deputy and other
problems without capabilities for those cases where they are not available,
the need to move to capability based systems is less urgent, and capabilities
may only play out their main advantage at a smaller scope.

Thanks,
Marcus