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.


On Tue, Jan 12, 2010 at 3:24 PM, Adam Barth <> 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 <> wrote:
>> On Tue, Jan 12, 2010 at 2:57 PM, Adam Barth <> wrote:
>>> On Tue, Jan 12, 2010 at 2:47 PM, Tyler Close <> wrote:
>>>> On Tue, Jan 12, 2010 at 2:44 PM, Adam Barth <> 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:
>>> 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"

"Waterken News: Capability security on the Web"

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