Re: Comments on Powerbox

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

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Tuesday, 2 March 2010 17:30:41 UTC