Re: [HASMAT] HASMAT Charter Proposal (revised)

Adam Barth <ietf@adambarth.com> Fri, 03 September 2010 17:04 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: hasmat@core3.amsl.com
Delivered-To: hasmat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D243A68CB for <hasmat@core3.amsl.com>; Fri, 3 Sep 2010 10:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level:
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTWfGXALOhZc for <hasmat@core3.amsl.com>; Fri, 3 Sep 2010 10:04:43 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 8814F3A6803 for <hasmat@ietf.org>; Fri, 3 Sep 2010 10:04:43 -0700 (PDT)
Received: by yxl31 with SMTP id 31so927905yxl.31 for <hasmat@ietf.org>; Fri, 03 Sep 2010 10:05:12 -0700 (PDT)
Received: by 10.103.229.2 with SMTP id g2mr148960mur.97.1283533510303; Fri, 03 Sep 2010 10:05:10 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id p2sm982926fak.22.2010.09.03.10.05.09 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 10:05:09 -0700 (PDT)
Received: by iwn3 with SMTP id 3so1866853iwn.31 for <hasmat@ietf.org>; Fri, 03 Sep 2010 10:05:08 -0700 (PDT)
Received: by 10.231.15.8 with SMTP id i8mr1253059iba.12.1283533507923; Fri, 03 Sep 2010 10:05:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.187.218 with HTTP; Fri, 3 Sep 2010 10:04:34 -0700 (PDT)
In-Reply-To: <3D718A9E-02EA-481E-B246-0E9C8B987F49@w3.org>
References: <4C8036C4.9060908@KingsMountain.com> <3D718A9E-02EA-481E-B246-0E9C8B987F49@w3.org>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 3 Sep 2010 10:04:34 -0700
Message-ID: <AANLkTikMLwSkV9M6F-ThFXEJYaowUGN439TzM=2Ho-so@mail.gmail.com>
To: Thomas Roessler <tlr@w3.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF HASMAT list <hasmat@ietf.org>
Subject: Re: [HASMAT] HASMAT Charter Proposal (revised)
X-BeenThere: hasmat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <hasmat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hasmat>
List-Post: <mailto:hasmat@ietf.org>
List-Help: <mailto:hasmat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2010 17:04:44 -0000

On Fri, Sep 3, 2010 at 2:02 AM, Thomas Roessler <tlr@w3.org> wrote:
> On 3 Sep 2010, at 01:44, =JeffH wrote:
>> Additionally, the WG will standardize a small number of
>> selected specifications that have proven to improve security of Internet
>> Web applications. Initial work will be limited to the following topics:
>>
>>   - Same origin policy, as discussed in draft-abarth-origin
>
> draft-abarth-origin defines the origin concept and a corresponding HTTP header.
>
> The same-origin policies typically involve a lengthy decision tree about where to take the origin from, e.g.:
>        http://dev.w3.org/html5/spec/origin-0.html#relaxing-the-same-origin-restriction
>
> Adam, can you elaborate a bit more how, in detail, you see the relationship between your draft and HTML5 play out?

Sure.  draft-abarth-origin defines the nuts-and-bolts of working with
origins (computing them from URLs, comparing them to each other, etc).
 HTML5 defines HTML-specific usage of origins.  For example, when
making an HTTP request, HTML5 defines how to compute which origin
among all the origins rendering HTML is the one responsible for making
the request.  draft-abarth-origin then takes that origin, serializes
it to a string, and shoves it in a header.

Originally, draft-abarth-origin was part of HTML5, but there are a
number of other standards that wanted to interact with origins.  For
example, Hybi would like to serialize an origin and place the octets
somewhere on the wire.  Rather than have these folks refer "up the
stack" to the application layer (e.g., HTML5), it seems to make more
sense to move the non-application specific parts lower down in the
stack.  Of course, the application-specific parts (e.g., that the
toDataURL method on the <canvas> element behaves different depending
on the origins of things drawn on the canvas) will remain at the
application layer.

There also seems to be demand for a document that describes the
same-origin security model overall.  However, it seems like that
document ought to be more informative rather than normative.  I've
started sketching out something in that regard:

https://docs.google.com/document/pub?id=1p2t8ZOAcwduqrS-NPAlSMtBDaDBg3PDBED625rTvctw

That's a pretty rough draft, but it should give you an idea of the
direction for that document.  Once I get that finished up, I'd like to
publish it in some forum, but it's unclear to me at this point what
forum would be most appropriate.

> And can we talk about that in the charter?

I'll leave that up to the folks who've been working on the charter directly.

Adam