Re: [http-state] SCS I-D document

[tho <[e-mail]>]

Hello Adam,

On Feb 22, 2011, at 11:16 PM, Adam Barth wrote:
> Thanks for the draft.  I'm not sure I quite understood what problem
> this protocol addresses or how it addresses that problem.  

the problem is the following: suppose a web app needs to save its execution state with a given client and has no local storage available to do so.

It can pack the state (say "user=bob;role=admin;auth=ok;lang=en_us;..."), create an SCS cookie out of it, and send the SCS cookie to the client.

An SCS cookie is created such that:
a) the state string can be seen in clear-text by no one but the web application;
b) it embeds ancillary information that carries the proof of authorship of the given web application over the cookie.

So, when the client returns to the web app, the latter can verify that:
a) the supplied SCS cookie was its (i.e. generated by the web app),
b) the state string has not been tampered;
this way it can safely restore state and continue execution (or reject in case any of the two properties can't be satisfied).

This is especially useful in embedded devices (think for example of an home router with a web app providing configuration and monitoring via HTTP running from firmware), but could also come in handy at a completely different magnitude order.  When you have to deal with a massive web app you usually need to rely on a centralized storage to save/restore session state shared by the multiple nodes.  Using SCS cookies each node can dump/restore global application state independently, provided all the nodes are initially feeded with the same crypto material (i.e. the same ~64 bytes of entropy).

Hope the intent is less opaque now, of course I'm available for any further clarification.

ciao, t.