Re: [Powerbox] Q's on the proposal

On Tue, Mar 2, 2010 at 11:29 AM, <richard.tibbett@orange-ftgroup.com> wrote:

> On Sun, 28 Feb 2010 at 19:45, Mark Seaborn <mseaborn@chromium.org>
> wrote:
>  >       If the browser were responsible for aggregating
> > responses like this it would need to know about the protocols
> > and data formats supported by particular resource types.
> > This is something we specifically want to avoid in the
> > Powerbox proposal.  The Powerbox just provides a generic
> > facility for introducing a customer web app to a resource by
> > passing a URL (and, for the sake of compatibility with file
> > upload, a blob of data) to the customer.  We don't want the
> > Powerbox to need to know how to interpret this data.
>
> I would say that we do want a Powerbox to know how to interpret the data
> being sent and received for a finite set of API use cases. Being
> data-aware provides more granular filtering, parameterization, richer
> opt-in/review interfaces and better security and privacy controls - IMO
> all of the challenges of this working group.
>
> It should be possible for a webapp to request specific sets of an
> object's attributes and to receive only those requested attributes in
> response


This is possible with the Powerbox.  The system allows resources to be
attenuated so that the customer web app is granted a resource which provides
only limited access.  For example, a resource can be read-only instead of
read-write; it can be revocable or time-limited; it can provide filtered
access to a subset of resources.

In general, it is up to providers to implement attenuation features, but
this does not rule out having the browser provide attenuation, because it is
possible for the browser to act as a provider.

For example, suppose I want to grant LinkedIn access to my Gmail contacts
list, with two constraints:
 * I only want to grant a snapshot, so contacts added in the future will not
become visible.
 * I only want to include names and e-mail addresses, not phone numbers or
any other information (to take Bryan Sullivan's example).

There are two ways in which an attenuated grant like this might be set up by
the user:

1) An interactive provider can provide options to restrict what is granted.
So in this example, Gmail's contacts provider might provide a checkbox to
say whether to grant a snapshot of the contacts list or instead grant the
ability to read future versions.  It might provide options to limit what
fields are exported.

2) In more advanced usage, it is possible to set up a proxy provider.  One
provider (P) can be set up to return a resource (B) that wraps an existing
resource (A).  There are a couple of ways this can be set up:
- P can be created with access to resource A.  P can be interactive or
non-interactive.
- P can be an interactive provider that asks for a resource A when P is
selected from the Powerbox.

So suppose Gmail's contacts provider does not provide the snapshotting and
filtering features that I want.  Someone can create a "Contacts Filter"
proxy provider (P) that implements these features.  Resource A is my Gmail
contacts -- the unfiltered version as provided by Gmail.  Resource B is the
filtered version that the proxy provider provides.  When I select Contacts
Filter from the Powerbox, it can ask me what filtering to perform and for
access to my unfiltered contacts.  Alternatively, it can ask for these
earlier, at the point where I register Contacts Filter with the Powerbox.

A proxy provider can be implemented as a normal web server, as a local web
server, or in the browser itself.

It is also possible for the customer web app to request voluntarily limited
access at the point where it makes the Powerbox request.  So a web app
requesting a contacts list might state that it only wants e-mail addresses,
not phone numbers.  An interactive contacts provider can display what the
customer web app requested, and in this case would not need to display an
option to omit phone numbers.

Cheers,
Mark