[cap-talk] Webkeys vs. the web

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Mon Mar 23 15:31:40 EDT 2009


Chip Morningstar wrote:
> (Note: this was originally sent to the friam list, but Kevin Reid suggested
> that it would be appropriate for cap-talk as well, so I'm resending to the
> broader audience.)
> 
> I was thinking about webkey API design based on some conversations we had at
> last Friday's meeting at HP, and so I ran off and designed what I thought was a
> really spiffy and self-consistent interface for the thing I'm building...then
> as I was dozing off last night I realized there was a horrible flaw in what I
> was doing, and I don't quite know how to fix it.
> 
> If all authority is carried via webkeys, then to get at anything a user needs
> to know the thing's URL.  Looking at this from the perspective of the web
> browser, there are three places it can hold onto webkeys: (1) in bookmarks,

(1a) in resource files and user preferences. These are essentially another
kind of bookmark for the purpose of your argument.

> (2) in the browse history, or (3) in an open page, either in links that are
> actually on the page or in the memory state of Javascript objects loaded from
> that page.

> These are the roots of the browser's authority.  It can also get to
> anything reachable from these by fetching whatever they link to and following
> the chain of references.  So far, so good.
> 
> Now let's consider a browser-based UI.  I can't reliably count on using (1) or
> (2) to hold the user's root authorities [...]
> 
> So to deal with this, I had the notion of a having the server hold the
> powerbox, and have a password-authenticated "login" operation that hands it
> back.  So the user logs in, gets their bundle of root authorities, and off to
> the races they go.  This was the notion we discussed Friday.  And it was so
> clever and elegant, I went off and designed a whole API...  But what happens
> when they navigate to another page?  At that point, the memory state of the
> page they were on is lost and they get a whole new memory state loaded from the
> new page.  [...]
> 
> The normal way sites deal with this sort of thing, when they aren't webkey
> based, is to have a link on every page labelled something like "Home", and
> that's likely the kind of thing our UI people will ask for too.  But in order
> to do *that*, the page would need to have the user's home webkey, which we've
> already said it doesn't have.  What's a capability-oriented guy supposed to do?

Approach #3: Each page has a "Home" link that isn't a webkey. When that link
is clicked, the user must reauthenticate, and then gets back to their root
page (which *is* referenced by a webkey).

Note that in this design there is no such thing as being "logged in", and
no login cookies are used (so there are no associated XSRF attacks).
The home page is just a form that when correctly submitted, gives back the
user's root page.

-- 
David-Sarah Hopwood ⚥



More information about the cap-talk mailing list