RE: updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Tuesday, September 21, 2010 2:54 AM
To: Suresh Chitturi
Cc: public-device-apis
Subject: RE: updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

Le lundi 20 septembre 2010 à 17:13 -0500, Suresh Chitturi a écrit :
> I wonder if there should be identifiers at the API level e.g. 'file'
> would indicate access to the entire File API i.e. read and write,
> 'contacts' would indicate access to the entire Contacts API and so on,
> in addition to the granular per operation access identifiers similar
> to 'geolocation' where it provides access to both getCurrentPosition()
> and watchPosition() methods.

My current approach is to have one identifier matching one permission
request in the browser — that's why geolocation covers both
getCurrentPosition() and watchPosition().

We could easily build groups of permissions as you allude to, but until
there is a clear use case for it, I would rather abstain from adding
arbitrary groups.

Suresh>> The use case is I would only grant permission for one time which translates to getCurrentPosition() and in some cases I would be fine to grant permission for continuous monitoring and that is watchPosition() and yet in another case I don’t care about the details and grant for both getCurrentPosition() and watchPosition().

So we have the following identifiers:

'geolocation' - Maps to both getCurrentPosition() and watchPosition()

'geolocation.get' - Maps to getCurrentPosition()

'geolocation.watch' - Maps to watchPosition()


>  This to me would make sense if one wanted to provide blanket-type of
> access to the entire API without worrying too much about the detail
> operations inside a particular API.

I think the number of current names is low enough that naming individual
permissions shouldn't be too much of a worry :)

> Since the <feature> element is linked into this document, would it
> make sense to also bring in the WARP <access> element to address the
> domain aspect? I think so.

One of the big differences of network-based permissions with the other
currently defined permissions is that this one would require
parametrization (e.g. the allowed domain names). Also, that permission
in the browser world is granted by the third-party domain (using CORS),
not by the user.

I'm not quite sure how this would be integrated as a result; would you
mind making a draft proposal that we could look into adding to the
document?


Suresh>> My understanding is that these identifiers can be used in with the <feature> element prefixed with a URI as described in the 1. Introduction. And what I was merely suggesting is that a complementary statement be added that these identifiers can also be used in conjunction with the <access> element. 

Here is a simple proposal:

1. Introduction 
.....

"For instance, the feature element as defined in the Widget Packaging and Configuration specification [WIDGETS] allows a widget runtime engine to grant access only to the specific APIs that the configuration file of the widget listed. Similarly, the access element as defined in the Widgets Access Requests Policy [WARP] when used in conjunction with the feature element allows the widget runtime to grant access only to the specific domains that are allowed to access the specific APIs.
.......



Dom




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 28 September 2010 18:08:46 UTC