- From: Breno de Medeiros <breno@google.com>
- Date: Mon, 23 Feb 2009 16:40:05 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Ben Laurie <benl@google.com>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
- Message-ID: <29fb00360902231640q589f259cxed1992c375e274a7@mail.gmail.com>
On Mon, Feb 23, 2009 at 3:48 PM, Adam Barth <w3c@adambarth.com> wrote: > On Mon, Feb 23, 2009 at 3:05 PM, Breno de Medeiros <breno@google.com> > wrote: > > crossdomain.xml was introduce to support a few specific applications > > (notably flash), and it did not take into account the security > requirements > > of the application context. Tough. > > I'm suggesting we learn from their mistakes instead of making the same > mistakes ourselves. I am saying that we do not have the application context here because this spec is generic. > > > > Because at this point there is no consensus what a general delegation > > mechanism would look like. Quite possibly, this might be > > application-specific. > > Why not handle delegation at the application layer instead of using > HTTP redirects for delegation? I am not saying that HTTP redirects are the same as delegation. I think to treat them on the same level is a mistake. An application can decide whether to follow a redirect or not based on its security model. For applications that expect signed content, the only delegation happens via signatures, and following HTTP redirects is a transport event that has nothing to do with delegation. > > > > The alternative is to write a spec that > > introduces complexity to solve problems that we conjecture might exist in > > yet-to-be-developed applications. The risk then is that the spec will not > > see adoption, or that implementors will deploy partial spec compliance in > > ad-hoc fashion, which is also a danger to interoperability. > > Great. Let's remove the complexity of following redirects. Or, from another point-of-view: Let's introduce restrictions on the spec based on anticipated threats against non-existing applications. However, I am tired of this argument. You haven't produced anything that convinces me there is a need to be addressed here, and I have not managed to convince you that this should be left to be specified when applications are developed that show clear usage patterns to justify what is and what is not, an acceptable restriction to be placed on the spec at a generic level. My vote is that I think the spec is better left as is. Your vote is also understood. See you in a future thread ... > > > Adam > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
Received on Tuesday, 24 February 2009 00:40:45 UTC