Re: Powerbox: UMP & CORS

Hi Robin,

Can you describe how you'd imagine CORS being used with the spec?  I don't
think it's all that obvious how it would fit in.

In general, if your URLs are secrets, then CORS does not provide any
particular benefits over UMP -- the secret nature of the URL already
provides all of the security properties that CORS can provide.  On the other
hand, if your URLs are *not* secrets, then I don't think they'd be
appropriate to use with this spec, unless they are public resources with no
access control at all.

There are two places where UMP is used in the spec currently:
1) In the requisition.
2) When submitting a <form> containing an <input> that has been filled in
via the powerbox.

For case (1), the secret provider URL serves two purposes:  to prove the
user's authority to access the resource, and to ensure that only the
powerbox can make requisitions (because only it knows the secret URL).
 Under CORS, we could communicate authority via cookies instead.  However,
the latter problem is trickier:  how does CORS indicate that only the
powerbox is allowed to make these requests?  Since the powerbox is not a
host, it cannot currently be listed in Access-Control-Allow-Origin.  So,
we'd have to extend the Access-Control-Allow-Origin header with some way to
specify the powerbox.  Or, we could stick with secret URLs, in which case
CORS doesn't seem to provide any actual benefit over UMP.

I suppose another way to solve case (1) would be to say that the powerbox is
not subject to same-origin policy at all, in which case neither CORS nor UMP
is needed, and providers could use cookies rather than secret URLs for
authority.  But this precludes implementation of the powerbox as a web
service.

In case (2), the secret URL is the only thing preventing a site from
accessing the resource before it has been granted through the powerbox.  In
order to solve this problem via CORS, we would have to add additional
details to the Powerbox spec to communicate the customer's origin to the
provider, so that the provider could then set "Access-Control-Allow-Origin:
${customer}" on the resource.  But this sort of mechanism would break the
ability of the customer site to delegate the resource to some other origin
unless they set up a proxy, which is unfortunate.  Also, server-to-server
communication would not work if the resource is protected by cookies -- the
customer must proxy all requests through the client's browser.

So it seems like, at best, to support CORS we have to add some complications
to the spec.  But it's not apparent to me that we gain anything from this
complication -- in fact, it seems that using CORS would only be harmful, as
it forces the customer to set up unnecessary proxies.

So the question becomes: Do we want to complicate the Powerbox spec in order
to give people the option of using a design that seems strictly inferior to
what the spec already supports?

On Mon, Mar 1, 2010 at 5:34 AM, Robin Berjon <robin@robineko.com> wrote:

> Hi,
>
> I just wanted to clarify a small detail concerning Powerbox. The proposal
> mentions relying on UMP for access; I have nothing against Unified
> Messaging, but it's currently a fairly early draft and it's unclear what
> solution will eventually be gravitated towards. I can't see any specific
> reason why the same proposal couldn't be used with CORS (or whatever we end
> up with). Am I right in presuming that it's saying UMP now, but it could in
> fact be another similar option?
>
> PS: any chance of changing the UMP acronym to something else? ;-)
>
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
>
>
>
>
>
>