RE: [Powerbox] Q's on the proposal

Mark,

 

The idea of the browser as a proxy provider is analogous to the role of
the web runtime in BONDI as the policy info collection / decision /
enforcement point. So overall this makes sense to me as a layered
approach to adding request processing granularity to the more
data-opaque design of the Powerbox.

 

I recommend this be added to the Powerbox proposal.

 

Also, what would also help me (at least) understand Powerbox better
would be to have some architecture diagrams and message/interaction
flows which illustrate the process and roles of the actors and other
entities in the architecture.

 

Thanks, 

Bryan Sullivan | AT&T

 

From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Mark Seaborn
Sent: Wednesday, March 03, 2010 3:53 AM
To: public-device-apis@w3.org
Subject: 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