W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Re: [Powerbox] New draft based on further collaboration and prototyping

From: Kenton Varda <kenton@google.com>
Date: Fri, 4 Jun 2010 10:59:43 -0700
Message-ID: <AANLkTilEem6Re43KRQ84UMF_fJS1hO8WH1knWcqRjNJ5@mail.gmail.com>
To: James Salsman <jsalsman@gmail.com>
Cc: Tyler Close <tyler.close@gmail.com>, public-device-apis@w3.org
Sorry for the delay; I was on vacation.

On Thu, May 27, 2010 at 2:17 PM, James Salsman <jsalsman@gmail.com> wrote:

> On Wed, May 26, 2010 at 5:15 PM, Kenton Varda <kenton@google.com> wrote:
> > On Wed, May 26, 2010 at 4:19 PM, James Salsman <jsalsman@gmail.com>
> wrote:
> >>
> >> I, for one, would feel a lot more comfortable if there was a MUST
> >> normative direction to provide a way for users to browse, and rescind
> >> at their option, all of their granted permissions, without having to
> >> depend on a provider's home interface.
> >
> > Are you hoping for this to work without communicating with the provider's
> > server at all?
>
> I think so.  Why would that be difficult?  Do you contemplate
> recording a list of "provided resource URL"s in the user's browser?
> Why can't they be annotated with a human-readable description and the
> customer sites for which they provide access, and listed, each with a
> "revoke" button or link which would cause access to the resource to
> fail if selected?
>

The problem is that in the current proposal, the provision is an arbitrary
message sent from the provider to the customer.  It is likely to contain
URLs which the customer will then use to contact the provider directly.
 Such communication is not obliged to go through the browser, and thus the
browser has no way of revoking such communication without the cooperation of
at least one of the two sites.

We assume that at least the provider is interested in cooperating with the
user's wishes (otherwise the whole system is pointless).  So, to revoke
grants, we must talk to the provider.

If we really wanted the user agent to be able to perform revocations
directly, we'd have to devise a scheme whereby all URLs sent in messages
between the customer and provider are replaced by proxies hosted within the
UA itself.  Then, all these proxies could simply be disabled in order to
revoke communication.  However, to do this, we would have to place
constraints on the protocol used between the customer and provider in order
to allow the UA to find and substitute URLs.  For instance, the Powerbox
protocol itself uses JSON like "{ '@': 'http://example.com' }" to
distinguish URLs.  We could require that all protocols negotiated via the
powerbox use the same convention (which, incidentally, implies that they
must be JSON-based), but this would be a huge limitation, basically
preventing any existing protocol from being used with the powerbox.
Received on Friday, 4 June 2010 18:00:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:10 GMT