UMP supports confidentiality where client and server desire confidentiality. I am mystified as to why you might think otherwise. Concern over CSRF does not preclude concern over confidentiality, to the contrary, it requires it.
--Tyler On Tue, Jan 12, 2010 at 3:24 PM, Adam Barth <[email protected]> wrote: > Before I respond to the below, I'd like to clarify one point. Does > UMP aim to provide confidentiality or are we concerned only with > integrity? It seems you consistently ignore confidentiality risks > (e.g., your response below is entirely about CSRF). > > Adam > > > On Tue, Jan 12, 2010 at 3:10 PM, Tyler Close <[email protected]> wrote: >> On Tue, Jan 12, 2010 at 2:57 PM, Adam Barth <[email protected]> wrote: >>> On Tue, Jan 12, 2010 at 2:47 PM, Tyler Close <[email protected]> wrote: >>>> On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth <[email protected]> wrote: >>>>> Let my phrase my question another way. Suppose the following situation: >>>>> >>>>> 1) I'm a server operator and I want to provide a resource to other web >>>>> sites. >>>>> 2) I've been reading public-webapps and I'm concerned about the >>>>> ambient authority in CORS. >>>>> >>>>> How can I share my resource with other web sites and enjoy the >>>>> security benefits of UMP? >>>> >>>> Follow the advice given in the "Security Considerations" section of >>>> the UMP spec: >>>> >>>> http://dev.w3.org/2006/waf/UMP/#security >>> >>> As a server operator, why can't I follow that advice with CORS? >> >> You can. >> >>> Nothing there seems specific to UMP. >> >> UMP is more restrictive on the server than is CORS. UMP doesn't make >> the client's ambient authority visible to the server. >> >>> I don't understand how UMP is helping server operators deal with the >>> risks of ambient authority. When a server operator makes a resource >>> available via UMP, they're also making it available to CORS with it's >>> attendant security model. >> >> UMP is helping server operators define APIs that enable their clients >> to defend themselves against CSRF-like vulnerabilities. A CSRF-like >> attack takes place on the client-side, not the server-side. The >> server's behavior needs to be restricted in a way that enables the >> client to communicate its wishes, while defending itself against CSRF. >> In particular, the client must be able to make a request without >> applying its credentials to the request, so the server must handle the >> request without demanding credentials be provided. >> >> --Tyler >> >> -- >> "Waterken News: Capability security on the Web" >> http://waterken.sourceforge.net/recent.html >> > -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
