[cap-talk] Cap vs. cap + password

Sandro Magi smagi at naasking.homeip.net
Sun Nov 27 09:08:08 EST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Wagner wrote:
> A capability that requires a password isn't really a capability any more.
> 
> A malicious user could give away their password, but a well-intentioned
> user is less likely to give away their password because they generally
> have been taught and understand that passwords are to be kept secret.
> However, users aren't taught to keep URLs secret.  (Even if we tried
> to tell users to keep URLs secret, they'd laugh at us behind our backs
> and ignore us,

They wouldn't laugh if their livelihood depended on it. The example
problem I posed is based on a real scenario; if a sales rep gave a
customer his cap URL to an order he was specifying, the customer could
decrease the sales rep's commission to practically nothing, and get
himself a corresponding decrease on the final price. I don't think the
rep would find that funny at all. It's all about incentives right? :-)

> because that would prevent them from getting useful work
> done.)

I don't see how. If each screen had a "safe link" feature which created
 a limited (perhaps only read-only?) reference to the current resource,
users could pass around information while safeguarding their authority
to make changes. Even better would be some facility to somehow specify a
subset of the current data.

> I agree that this would help with the security problem, but it seems like
> it would harm usability and interoperability among applications.  How do
> users share a URL with a friend?  How do they copy-and-paste it into
> an email?  How do they link to it in their own web pages, their blogs,
> their communications with others?  And, most importantly, how can we make
> these steps as convenient and intuitive for YURLs as for today's URLs?

All of the problems thus far described are non-issues if capabilities
were partitioned rather than data. Partitioned capability systems can't
leak authority in the ways we've described since the capabilities would
all reside on the server. A partitioned capability web application would
require an initial authentication to reconnect a party with their
private object space, but how could/would one traverse the object graph?
 How does this differ from typical web apps? I'm curious how far this
idea could be taken.

Passing URLs wouldn't work unless one were to explicitly create a
cap-URL of a resource.

Sandro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDib3Hp+tmQHySTM0RAvyJAJ407RAStbrzSlcUIuZt5DDvaSH6YgCgw07N
rAQHNKeSHH1HaWaKquEwego=
=qTgB
-----END PGP SIGNATURE-----


More information about the cap-talk mailing list