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

Re: Comments on Powerbox

From: Tyler Close <tyler.close@gmail.com>
Date: Tue, 2 Mar 2010 09:30:07 -0800
Message-ID: <5691356f1003020930h7c866745wd0bc1ca3154cf2e8@mail.gmail.com>
To: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>, Robin Berjon <robin@berjon.com>
Hi Frederick,

On Mon, Mar 1, 2010 at 5:30 PM, Frederick Hirsch
<Frederick.Hirsch@nokia.com> wrote:
> Tyler
> I have two thoughts/questions related to  Powerbox.
> First, in the spirit of brainstorming, would make sense to associate a
> privacy policy with a given powerbox provider during the registration
> process, enabling notice and transparency,  perhaps including links to
> service policy and log information that could inform user provider
> selection. This could be simple but help with clarifying privacy policy
> associated with the provider. I don't think this would address all privacy
> issues, but could be a part of a solution.
> This might require an additional attribute  to provider registration, (e.g.
> a privacyPolicy attribute) or in  a REST approach a specific standardized
> URL variant could  return a privacy policy,  or access to a log.

In the expected scenarios, a Provider is a resource that already knows
about a user's private resources and is making them available to
Customers. The Customer is the entity gaining new access to a
potentially private resource. So I think there's a greater need for
the Customer, rather than the Provider, page to declare it's privacy
policy during a Powerbox interaction. I expect such declarations by a
Customer page can be made in the same way as any other page that is
requesting information from the user and so there is no need for the
Powerbox spec to define how this is done. For example, a Customer page
might include a link to the site's privacy policy.

> I also have a question. Wouldn't it be more REST-like to use  a GET in a
> provision request with the various parameters as query string parameters?
> Why does the draft use POST instead (due to potential size longer than
> allowed?)

The provision request [1] is a POST since it supports state mutation
on the server. The returned provided resource URL [2] might identify a
newly created resource on the server.

Leaving the response to a GET request undefined also leaves us the
flexibility to define Provider attributes like accepted MIME types and
expected interface names should that prove necessary.

[1] http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0140/Overview.html#provision
[2] http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/att-0140/Overview.html#provided-resource-url


"Waterken News: Capability security on the Web"
Received on Tuesday, 2 March 2010 17:30:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:42 UTC