<abarth> Zakim: aabb is abarth

<abarth> Zakim: y u no remember my phone number?

<ekr> zakim doesn't remember me either

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2012Jan/0000.html

<bhill2> that's today's agenda, for those joining late

<krisk> I just wanted to confirm that we all agree to have the webappsec WG to hold the CORS tests cases and not have them in webapps

bhill, minutes approved from last meeting

<bhill2> http://www.w3.org/2011/webappsec/track/actions/open

bhill to update due date of activity 1

Action 34 pushed out 2 weeks.

<trackbot> Sorry, couldn't find user - 34

<abarth> you can't hear m?

No.

Action 35 pushed out to next call.

<trackbot> Sorry, couldn't find user - 35

Gopal has volunteered to be the test coordinator for webappsec testing.

Plan at the moment is to use the same process that webapp uses. In the process of building a virtual machine for use in testing

Moving the CORS test MS created into the webappsec test folder.

Couple of tests need approval for changes in the php config.

Need input from Dominique.

<jrossi> For those unfamiliar, here's the WebApps testing process (infrastructure, submission, approval, harness, etc.): http://www.w3.org/2008/webapps/wiki/Testing

CORS CfC comments

bhill: Concern that the issues and objections raised by UMP have not been fully addressed by CORS. Spec is incomplete around security considerations. After back-and-forth on TAG list,

<bhill2> http://www.w3.org/2008/webapps/track/issues/108?changelog

abarth: Can the TAG document their concerns as opposed to playing bring a rock with security goals to TAG.

bhill2: We can wait for them to create a security considerations text or create our own. Their concern is the the CORS approach is fundamentally flawed.

We have to work in the consensus based process as defined by the W3C.

We need to demonstrate that we have addresssed their concerns.

abarth: Why are we discussing the issue in the TAG and not the WG?

Part of the process should be engaging the relevent TAG members in the WG.

bhill2: We can move forward to last call, but it would be good to proactively address the issues that have been brought up.

abarth: We should just create the best spec we know how to create and move foward.

ekr: Create a security considerations section we are happy with.

<bhill2> ACTION to bhill2 to email anne wrt proposed additions to security considerations for CORS re: confused deputy

<trackbot> Sorry, couldn't find user - to

<bhill2> ACTION bhill2 to email anne wrt proposed additions to security considerations for CORS re: confused deputy

<trackbot> Created ACTION-37 - Email anne wrt proposed additions to security considerations for CORS re: confused deputy [on Brad Hill - due 2012-01-10].

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0031.html

CSP for scripts and stylesheets

abarth: There's a general problem with things non CSS being sent to the CSS parser.

We should definitely mention that it is important this is implemented correctly.

Not sure what to do the JSONP issue.

Possibly whitelist directories

Other possibilities are JSON specific. Don't know what the best solution is.

<bhill2> ISSUE how to deal with return-oriented-programming attacks against JSONP interfaces at whitelisted origins

Access-Control-Request lowercasing

<bhill2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15312

bhill2: Don't have the context to discuss this today. Table it for today and discuss on mail list.

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0039.html

CSP and ISP rewriting

bhill2: Consensus on the call that this is not a scenario we are going to accomodate.

<ekr> ACTION: abarth to record that ISPs should not mess with CSP, and if you are worried about this, you should do HTTPS. [recorded in http://www.w3.org/2012/01/03-webappsec-minutes.html#action01]

<trackbot> Created ACTION-38 - Record that ISPs should not mess with CSP, and if you are worried about this, you should do HTTPS. [on Adam Barth - due 2012-01-10].

ekr: One more piece of business; How do we get done?

Adding things like this to the agenda because they are alleged technical defects. Once we no longer have defects, we're at 1.0. Is this everyone's concensus?

bhill2: Move to last call once editors are comfortable with that request.

May be a good idea to move more aggressively to last call.

For next call we try and go through all the open issues and resolve them.

<gopal> thanks, happy new year

<Rajesh> thanks everyone

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: rrware
Inferring Scribes: rrware

WARNING: No "Topic:" lines found.

Default Present: +1.650.678.aaaa, ekr, gma1, +1.650.648.aabb, +1.303.229.aacc, bhill2, abarth, +1.408.234.aaee, +1.415.832.aaff, krisk, +1.650.224.aagg, [Microsoft], rrware, +1.408.234.aahh, +1.978.944.aaii
Present: +1.650.678.aaaa ekr gma1 +1.650.648.aabb +1.303.229.aacc bhill2 abarth +1.408.234.aaee +1.415.832.aaff krisk +1.650.224.aagg [Microsoft] rrware +1.408.234.aahh +1.978.944.aaii
Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2012Jan/0000.html
Got date from IRC log name: 03 Jan 2012
Guessing minutes URL: http://www.w3.org/2012/01/03-webappsec-minutes.html
People with action items: abarth

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report