W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [access-control] Seeking Clarification and Status of Issues #25, #26, #29, #30, #31 and #32

From: Arthur Barstow <art.barstow@nokia.com>
Date: Thu, 16 Oct 2008 10:13:50 -0400
Message-Id: <E1864572-907A-4E2E-A01F-488FF8E22766@nokia.com>
Cc: public-webapps <public-webapps@w3.org>
To: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>

Thanks for the information Jonas.

Anne - Jonas indicates #26, #29, #31 and #32 have been addressed in  
the latest Editor's Draft. Thus an implication they can be closed. Do  
you agree they have been addressed and thus can be proposed to Close?

Also, what are your thoughts on #25 and #30?

-Thanks, Art Barstow


On Oct 9, 2008, at 8:56 PM, ext Jonas Sicking wrote:

> Arthur Barstow wrote:
>> The following issues were created during the July 1-2 f2f meeting  
>> (minutes at [1], [2], respectively).
>> Would someone that attended that meeting please elaborate these  
>> issues?
>> In particular, has the Issue been addressed and thus can be  
>> proposed to be Closed?
>> -Regards, Art Barstow
>> [1] <http://www.w3.org/2008/07/01-wam-minutes.html>
>> [2] <http://www.w3.org/2008/07/02-wam-minutes.html>
>> * ISSUE-25 - Revocation of cached access grants
>> http://www.w3.org/2008/webapps/track/issues/25
>
> The issue was the ability for a server to revoke a cached preflight  
> result. Or ensuring that if you are MITMed in a cafe or some such  
> that the cached result doesn't linger too long.
>
> I *think* this one is resolved since the cache is cleared if access  
> is ever denied (haven't implemented this part of spec yet so not  
> 100% sure).
>
> We decided that implementations should be allowed to clear the  
> cache at any point if they so desire, which means that  
> implementations are allowed to limit the cache time to 24 hours or  
> some such (something that firefox will do).
>
> Hmm.. though looking at the spec I can't find where it says that  
> clearing items out of the cache at any point.
>
>> * ISSUE-26 Wildcarding is currently possible together with cookies  
>> which could result in exploitable servers.
>> http://www.w3.org/2008/webapps/track/issues/26
>
> This is about not allowing the '*' syntax when fetching private data.
>
> This has been address as this is no longer allowed per spec.
>
>> * ISSUE-29 Should Access-control allow DNS binding defense?
>> http://www.w3.org/2008/webapps/track/issues/29
>
> This should again be addressed by the spec allowing the  
> implementation the clear the cache at any point.
>
>> * ISSUE-30 Should spec have wording to recognise that User Agents  
>> may implement further security beyond the spec?
>> http://www.w3.org/2008/webapps/track/issues/30
>
> I guess this is the part that needs to be addressed by adding  
> wording to the spec to say that the cache can be cleared/ignored at  
> any point.
>
> I wrote up a list at some point and I think sent it to the public  
> list about security measures that Firefox was going to take beyond  
> the spec.
>
>> * ISSUE-31 Allow POST without a preflight with headers in a whitelist
>> http://www.w3.org/2008/webapps/track/issues/31
>
> This is addressed in the spec. POST is now allowed when the content- 
> type is text/plain.
>
>> * ISSUE-32 Each redirect step needs to opt in to AC in order to  
>> avoid data leaking
>> http://www.w3.org/2008/webapps/track/issues/32
>
> I think this is addressed in the spec.
>
>
> So all in all it seems like once ISSUE-30 is fixed all of the above  
> can be closed.
>
> / Jonas
Received on Thursday, 16 October 2008 14:15:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT