[cap-talk] Capability Semantics

[David Hopwood]

Jed at Webstart wrote:
> At 11:36 AM 7/25/2006, Tyler Close wrote:
>>On 7/24/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
>>>At 03:57 PM 7/24/2006, Tyler Close wrote:
>>>
>>>>I am arguing that if we wish to make use of our existing WWW software,
>>>>such as browsers, we need to use a capability representation that is
>>>>supported by this software. AFAICT, a password capability is the only
>>>>capability representation that is backwards compatible with our
>>>>existing software.
>>>
>>>I assume you also include software such as email clients and
>>>servers, perhaps protocols like LDAP, PAM, im, etc., etc.
>>
>>Yes, I am interested in applying capability concepts to other
>>protocols, but I also think HTTP is currently the most important
>>protocol and will continue to be so for the foreseeable future. I have
>>therefore been putting most of my effort into developing tools that
>>work within HTTP.
> 
> I can understand an emphasis on http, but I think at least email
> must be included.  At present it seems that email is nearly (absolutely?)
> the only means for individual domain to domain (e.g. person to
> person) communication.  Without the ability to safely send
> capabilities in email, it's difficult for me to see how any richer
> object based sharing structure can be built up.

Another reason why you need to consider email, is that email is a
"push" protocol, while HTTP is primarily a "pull" protocol (although
it can be used for "push" as well). Also email is store-and-forward
(no end-to-end communication), while HTTP is end-to-end.

"Push" and "pull" protocols have fundamentally different properties
in terms of secure interaction. If the user wants to *give* some
resource to another user, he or she will normally think of a push
protocol as being the most natural way to do that. Also, most users
don't have full control over a web server, which leaves them with no
way to receive unsolicited (or not directly requested) messages
containing capabilities.

Store-and-forward transport protocols place additional constraints on
any higher-level protocol built on them, and you need to know whether
the web calculus can handle these constraints gracefully.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>