Re: [UMP] Server opt-in

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 <w3c@adambarth.com> 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 <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
>>
>



-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 13 January 2010 00:56:37 UTC