Re: [HASMAT] HASMAT Charter Proposal (revised)

Thomas Roessler <tlr@w3.org> Fri, 03 September 2010 09:01 UTC

Return-Path: <tlr@w3.org>
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 BD2F03A6820 for <hasmat@core3.amsl.com>; Fri, 3 Sep 2010 02:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 sgVZlF82U9yH for <hasmat@core3.amsl.com>; Fri, 3 Sep 2010 02:01:53 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id D1D483A682D for <hasmat@ietf.org>; Fri, 3 Sep 2010 02:01:53 -0700 (PDT)
Received: from [87.240.232.183] (helo=[192.168.2.114]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <tlr@w3.org>) id 1OrSA5-0003IV-29; Fri, 03 Sep 2010 05:02:17 -0400
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Thomas Roessler <tlr@w3.org>
In-Reply-To: <4C8036C4.9060908@KingsMountain.com>
Date: Fri, 03 Sep 2010 11:02:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D718A9E-02EA-481E-B246-0E9C8B987F49@w3.org>
References: <4C8036C4.9060908@KingsMountain.com>
To: =JeffH <Jeff.Hodges@KingsMountain.com>, Adam Barth <abarth@eecs.berkeley.edu>, Brandon Sterne <bsterne@mozilla.com>
X-Mailer: Apple Mail (2.1081)
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 09:01:54 -0000

On 3 Sep 2010, at 01:44, =JeffH wrote:

> I've revised the proposed charter per Barry's comment.

Thanks.

> 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?  And can we talk about that in the charter?

> Deliverables
> 
> 1. A document illustrating the security problems Web applications are
> facing and listing design requirements.  This document shall be
> Informational.
> 
> 2. A selected set of technical specifications documenting deployed
> HTTP-based Web security solutions. These documents shall be Standards Track.
> 
> 
> Goals and Milestones
> 
> Oct 2010    Submit "HTTP Application Security Problem Statement and
>            Requirements" as initial WG item.
> 
> Oct 2010    Submit "Media Type Sniffing" as initial WG item.
> 
> Oct 2010    Submit "Web Origin Concept" as initial WG item.
> 
> Oct 2010    Submit "Strict Transport Security" as initial WG item.
> 
> Feb 2011    Submit "HTTP Application Security Problem Statement and
>            Requirements" to the IESG for consideration as an
>            Informational RFC.
> 
> Mar 2011    Submit "Media Type Sniffing" to the IESG for consideration
>            as a Standards Track RFC.
> 
> Mar 2011    Submit "Web Origin Concept" to the IESG for consideration as
>            a Standards Track RFC.
> 
> Mar 2011    Submit "Strict Transport Security" to the IESG for
>            consideration as a Standards Track RFC.
> 
> Apr 2011    Possible re-chartering

I'm trying to think through the relationship between this time line and the Web Application Security WG idea at W3C:
	http://www.w3.org/2010/07/appsecwg-charter.html

In particular, to what extent do we expect the requirements document out of the IETF WG to directly influence whatever the W3C group does with CSP?

(Note that, on the IETF side of things, it's rational to recharter after the requirements document has been developed.  I'd prefer to avoid that on the W3C side if possible, since a rechartering is more costly -- though not impossible -- there.)

Thoughts?