[cap-talk] A paper on web-keys

[Toby Murray]

On Thu, 2008-01-17 at 15:11 -0800, Tyler Close wrote:
> One of the WWW 2008 reviewers of this paper wrote:
> 
> "Capabilities are *always* easier to implement, and the tradeoff is
> *always* about giving up control."
> 
> What is the canonical paper to critique in order to rebut the "giving
> up control" argument? Which paper had so much influence that people
> like the reviewer believe this fiction to the point of using star
> quotes?
> 

The reviewer fails to realise, of course, that when I give my
username/password for web application X to web application Y, in order
to facilitate some mashup of X on Y, that I am of course giving up more
much control that what I ever would, were I able to delegate a single
webkey to web app Y that gave it precisely the authority it needed on
web app X.

Of course, designing a UI that would allow the user to generate such a
web key, suitable for this particular mashup, seems non trivial. How is
the user supposed to know the authority that web app Y needs over the
user's account in web app X ? Even if the user is able to somehow
determine this, it would appear that web app X would need to implement
special support for creating a suitably reduced-power webkey that
happens to fit the requirements of web app Y. 

So while webkeys ought to provide a good means for these sorts of
mashups, I wonder whether there is a more fundamental concern about what
the user experience would look like in this case.

As one of the reviewers commented on the paper, it would appear that
even using the webkeys approach (which I'm in favour of, btw), one still
needs to design a web app (e.g. web app X above) cognizant of the
requirement that it might end up being mashed-up with another (e.g. web
app Y). 

However, perhaps it isn't as hard as one might imagine at first. Perhaps
all that is needed is a means to allow the user to create less powerful
webkeys to useful facets of their account. Given the nature of the web
app in question, the choice of facets may well be obvious and may well
still allow the application to be mashed-up to other developers' hearts'
content.