- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 30 Nov 2009 17:11:07 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Nov 30, 2009 at 4:20 PM, Adam Barth <w3c@adambarth.com> wrote: > On Mon, Nov 30, 2009 at 11:25 AM, Tyler Close <tyler.close@gmail.com> wrote: >> On Wed, Nov 25, 2009 at 5:55 PM, Adam Barth <w3c@adambarth.com> wrote: >>> Yes. At the application layer. >> >> Perhaps we're just talking past each other here. I'll try again... >> >> When creating a new application layer API, the designers must take >> into account the SOP protection expected by resources. Currently, >> these expectations aren't documented anywhere. In the status-quo, the >> application layer API is expected to magically know all the SOP >> restrictions and then document how it enforces them. I'm just >> suggesting that it would be a good thing to remove some of the magic >> here by writing down the SOP restrictions, leaving the application API >> with only the task of documenting its enforcement mechanism. > > I agree with everything you're saying, but you haven't explained why > this documentation should be at the protocol layer instead of the > application layer. 1. To document the constraints that all user agents must enforce. The restrictions apply to all APIs in the entire application layer, not just some application APIs. HTTP is the layer below the application API, where constraints upon all user agents are specified. 2. To document the security model that server-side resources are written to. A HTTP resource expects the SOP to apply regardless of the API used to generate requests. A HTTP resource is not a <img> resource, or a <link> resource, or a curl resource, just an HTTP resource. A resource does not expect the security model to change based on the API used to produce the request. In many cases, this distinction is not even knowable based on the content of the HTTP request. 3. Although some parts of SOP also apply to other protocols, such as ftp, other parts are specific to HTTP, such as: rules around request headers, redirects, the distinctions between POST and PUT, etc. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Tuesday, 1 December 2009 01:11:47 UTC