Re: [UMP] Server opt-in

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 <tyler.close@gmail.com> wrote:
> On Tue, Jan 12, 2010 at 2:57 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Tue, Jan 12, 2010 at 2:47 PM, Tyler Close <tyler.close@gmail.com> wrote:
>>> On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth <w3c@adambarth.com> 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
>

Received on Tuesday, 12 January 2010 23:25:03 UTC