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

Adam Barth <> Wed, 23 February 2011 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2BA43A6A00 for <>; Wed, 23 Feb 2011 02:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.813
X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_SPAM=2.072]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O0vVXKR3I28W for <>; Wed, 23 Feb 2011 02:40:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3793C3A69FC for <>; Wed, 23 Feb 2011 02:40:55 -0800 (PST)
Received: by iwc10 with SMTP id 10so1581301iwc.1 for <>; Wed, 23 Feb 2011 02:41:41 -0800 (PST)
Received: by with SMTP id it7mr1755116icb.507.1298457701822; Wed, 23 Feb 2011 02:41:41 -0800 (PST)
Received: from ( []) by with ESMTPS id u9sm7146002ibe.2.2011. (version=SSLv3 cipher=OTHER); Wed, 23 Feb 2011 02:41:40 -0800 (PST)
Received: by iyj8 with SMTP id 8so2780936iyj.31 for <>; Wed, 23 Feb 2011 02:41:40 -0800 (PST)
Received: by with SMTP id hv6mr4833452icb.446.1298457700086; Wed, 23 Feb 2011 02:41:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 23 Feb 2011 02:41:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Adam Barth <>
Date: Wed, 23 Feb 2011 02:41:10 -0800
Message-ID: <>
To: tho <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] SCS I-D document
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Feb 2011 10:40:56 -0000

On Wed, Feb 23, 2011 at 2:24 AM, tho <> wrote:
> 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.

Why does the server need any help from the user agent?  It seems like
the server can just encrypt and mac the data itself and store it in a