[cap-talk] Webkeys vs. the web

[James A. Donald]

Chip Morningstar wrote:
> Approach #1 is to never leave one's home page, but have all navigation take
> place via scripted fetches of particular bundles of data.  That preserves the
> capability model but it breaks the web nature -- I can't, in this scenario,
> bookmark things I go to (remember, I didn't say we couldn't use bookmarks, just
> that we can't rely on the user making particular bookmarks) or snapshot the
> URLs of pages to have links to pass to others.
> 
> Approach #2 is to have every page in this system include a "powerbox module"
> and use a session cookie so that when I load the powerbox module, the backend
> populates it with my stuff but when you load it it populates it with your
> stuff.  The session cookie in this scenario ends up being, in essence, a webkey
> that is held in a cookie (and handed around like a cookie), which makes me very
> queasy.  The key thing the cookie is providing is a bit of short-term memory
> state that survives page load.
> 
> I'm thinking we have no choice but to go with option #2, but it makes me really
> uncomfortable, given all the various issues cookies have.

In the browser, possession of authority is normally represented to the 
user as the state of being logged on to a particular domain, which under 
the hood is represented by a transient secret cookie that will be 
presented to all web pages in that domain and only in that domain.

Unfortunately it is easy for a site to present as a false domain, 
thereby leaking the secret.  Obviously the state of being logged on 
should be represented by a transient shared secret which is *not* handed 
to the server, but rather both parties prove possession of the secret 
without revealing it by encrypting their communications to the shared 
secret.

https makes this leakage somewhat less likely, by providing a true name 
map to public keys.

The problem is that the underlying protocol does not represent the state 
of being logged in, does not have a concept of a logged in relationship.

User authority concepts do not map directly to low level browser 
authority concepts, and the resulting gaps cause insecurity, making 
people reluctant to store and transfer promises and representations of 
value over the internet.

If the underlying communication protocol *did* represent the state of 
being logged in as a shared encryption secret, and authority bearing 
urls logged you in, and if the user agent knew that authority bearing 
urls were different, so that it refrained from indiscriminately putting 
authority bearing urls in headers, and transformed authority bearing 
urls to greatly attenuate authority when passing them around, then the 
browser would work as the basis of a capability system.

As the browser is, it does not actually work as the basis of a 
capability system.

However, with https cookies, leakage of login state is not too severe. 
Https cookies are a workaround for cookie secret leaking, and #urls are 
a workaround for for the propensity of the browser to indiscriminately 
pass out urls in headers.  With these workarounds (authority bearing 
#urls that log you in to a particular sub sub sub domain), the browser 
does work as a capability system, though in a cumbersome, inefficient, 
and dangerously complicated way.