- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 12 Apr 2010 09:49:22 -0400
- To: Maciej Stachowiak <mjs@apple.com>, Tyler Close <tyler.close@gmail.com>, Anne van Kesteren <annevk@opera.com>
- Cc: public-webapps <public-webapps@w3.org>
Maciej, Tyler - thanks for continuing this discussion. I think it would be helpful to have consensus on what we mean by subsetting in this context. (Perhaps the agreed definition could be added to the CORS and UMP Comparison [1].) Anne - as Maciej mentioned in another thread [2], it would be good to get your feedback on this subject. -Art Barstow [1] http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP [2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 0058.html On Apr 8, 2010, at 8:51 PM, ext Maciej Stachowiak wrote: > > On Apr 8, 2010, at 5:20 PM, Tyler Close wrote: > >> On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak <mjs@apple.com> >> wrote: >>> Actually, the other proposal is to provide an XHR-like API that >>> would use CORS forcing a unique origin as an input parameter - >>> there is no need to >>> My hope is that this would be semantically equivalent to using UMP. >> >> This unique origin would still need to discard Set-Cookie response >> headers to prevent the accumulation of credentials associated with >> the >> unique origin. It would also need to prohibit the reuse of a TLS >> client authenticated connection or NTLM authenticated connection. It >> would also need to prevent use of cache entries populated by >> non-uniform requests. The CORS draft is also unclear on what happens >> with the Referer header. > > Good point. It seems like these should all be raised as issues on > CORS. I will do it if you don't beat me. > > >> >>> What I'm looking for is a clear and objective way to evaluate the >>> desired subset properties. Here are some clear-cut subset >>> properties that I think will give most of the interoperability and >>> ease of implementation you want: >>> >>> (A) Every Uniform Request should also be a valid CORS request. >> . >> ...with the same semantics. The goals being: >> 1) an UMP API can safely and successfully send a uniform request to a >> CORS resource >> 2) a CORS API can safely send a request to an UMP resource, which may >> choose to either fail or allow the request > > Sounds good, although I meant this to only be a syntactic criterion - > (C) is intended to be the semantic / processing requirements > criterion. > >> >>> (B) Every Uniform Response should also be a valid CORS response. >> >> ...with the same semantics. The goal being: >> 1) an UMP resource can safely and successfully return a uniform >> response to a CORS API >> 2) a CORS resource can safely and successfully return a uniform >> response to an UMP API >> >> Given the above, a developer can read only UMP and ignore CORS and >> still write safe code that works. That's what I mean by "subset". > > Also agree to your clarifications. > >> >>> (C) When a CORS client makes a Uniform Request and receives either >>> a Uniform Response, or an HTTP response that is neither a Uniform >>> Response nor a response would allow access under CORS rules, then >>> the processing requirements under CORS are the same as the >>> processing requirements under UMP. >> >> (C) seems the same as (B) if we assume both CORS and UMP properly >> reject Same-Origin-only responses. > > I'd like to have a rule explicitly about the processing requirements > rather than have that implied by rules about semantics. "Semantics" is > not quite clear-cut enough to evaluate objectively. > >> >>> Currently (A) and (C) do not hold. One counter-example to (A): a >>> request that contains no Origin header at all, not even Origin: >>> null, may be a Uniform Request but is not a valid CORS request. >> >> I think it would be safe for a CORS resource to assume Origin: null >> when no Origin is provided. I agree the current spec doesn't say so. > > Either UMP or CORS could change here, but we have to agree which to > change and do it. I don't actually know if assuming "Origin: null" in > the absence of an origin is safe; that's a change to the model that > would have to be reviewed. I am pretty confident that adding "Origin: > null" to a Uniform Request does not pose a security risk, though it > may be seen as unnecessary from the UMP-only perspective. I also do > not know if this is the only counter-example; I did not do a thorough > review UMP and CORS against these criteria at the time. I think we > should review carefully according to these criteria and reconcile all > violations before either spec goes to CR (and ideally before either > goes to LC). > >> >>> One counter-example to (C): UMP will follow a redirect that is >>> neither a Uniform Response nor allows access under CORS; but CORS >>> will not. >> >> This has since been reconciled. > > Good news. > >> >>> I am not currently aware of any violations of (B). >> >> (B)(2) is currently violated by the difference in response header >> filtering. This can be reconciled when the current open CORS issue >> about response headers is closed. It'll be interesting to see how >> this >> issue is resolved since it is potentially very contentious. Banning >> response headers seriously affects the extensibility of HTTP. > > Can you explain more specifically what the (B) violation is? > >> >>> Also, the reason the conditions on (C) are a little funny: I think >>> it's possible that a CORS implementation could make a Uniform >>> Request that receives a non-Uniform Response that nontheless allows >>> access, but I'm actually not sure if this is possible. It's >>> definitely possible if it is legal to send multiple "Access-Control- >>> Allow-Origin:" headers in a response, or to send "Access-Control- >>> Allow-Origin: null". I am not sure if either of these is allowed. >>> I'm also not sure if there are other possible CORS responses that >>> would violate the Uniform Request requirements or UMP processing >>> model. If there are no such conflicts, then we could tighten C to: >> >> An UMP resource is only allowed to respond with a single >> Access-Control-Allow-Origin: *. Other values are undefined by UMP and >> so don't offer any defined behavior that an UMP resource can rely >> upon. That's not a violation of (C) through, since (C) says the >> response is either a uniform response or one rejected by both UMP and >> CORS. >> >>> (C') When a CORS client makes a Uniform Request and receives any >>> response, then the processing requirements under CORS are the same >>> as the processing requirements under UMP. >> >> CORS defines more kinds of successful responses than does UMP, since >> it supports additional values for the Access-Control-Allow-Origin >> header. So (C') would be violated if a non-compliant UMP resource >> responded with an Access-Control-Allow-Origin header with a value >> matching the received Origin header. > > I am ok with not having (C') as one of the criteria. > >> >>> Also none of this squarely addresses your original point 1: whether >>> a UMP server would automatically be compatible with a CORS request >>> that is *not* a Uniform Request. That would require a condition >>> something like this: >>> >>> (D) When a UMP server receives a CORS Request that is not a Uniform >>> Request, if it would have granted access to the same request with >>> all user and server credentials removed, it must process the CORS >>> request in the same way as it would if all credentials had in fact >>> been omitted. >>> >>> I don't think (D) follows from the current requirements, and I'm >>> not entirely sure if it is practical to enforce through >>> requirements. >> >> ...or desirable. I can imagine a resource that legitimately wanted to >> reject all non-uniform requests. For example, there may be a back-end >> that doesn't trust its front-end to ignore credentials, so it fails >> all non-uniform requests so that such requests trigger test failures >> that can be detected. > > I agree; I do not think (D) is a useful property to ensure. > >> >>> Whether CORS and UMP satisfy the various subset relations described >>> here is something that can be determined objectively through review >>> of both drafts. Relation conditions like "small subset of the >>> mechanisms" or "automatically compatible" are harder to pin down. I >>> would like to ensure that CORS and UMP satisfy at least relations >>> (A), (B) and (C), and if desirable and practical, also (C') and >>> (D). Note: I'm not making any assumptions here about which of CORS >>> or UMP should change to address any given violation of the subset >>> relation. >> >> I think (A) and (B) define the subset relationship we should aim for. > > I would prefer to still include (C) to the extent that it require > anything additional on top of (A) and (B). > >> >>> If we satisfy all of these relations, then once we have an API that >>> allows making requests that satisfy the Uniform Request >>> requirements via CORS, it will be usable as a UMP API as well. >> >> Sure. Whether or not it is desirable to have both living under the >> same API is still a question though. > > Definitely a valid question, but separate from the subset relation, I > think. > > Regards, > Maciej > >
Received on Monday, 12 April 2010 13:50:58 UTC