- From: Doug Turner <dougt@dougt.org>
- Date: Mon, 28 Jun 2010 13:58:50 -0700
- To: <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com>
- Cc: <dom@w3.org>, <public-device-apis@w3.org>
On Jun 28, 2010, at 1:38 PM, <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com> wrote: > Thanks Dom. > > Is the first argument is what we've been calling a "capability"? Maybe? The two examples are "geolocation" and "desktop-notification". Thinking as a firefox developer, these are two features that require user permission prior to use. It would be useful if a website would know if firefox would bring up a UI before invoking either of these features. The point of this interface would be to test and acquire that permission without invoking the actual feature. > It looks like "checkPermission" then is requesting a Policy Decision, so behind this call could be a variety of choices of policy decision evaluators, one of which could be along the lines of the XACML-like policy rules and evaluation engine. > > Thus it seems we still need to define capabilities and ability to express policy rules. I did not understand any of the above text. > What is proposed however, is a means to "mix in" an interface to request such decisions to any API, is that right? Not exactly. The basic use case is that a web application might want to know if invoking a given API will change the UI of the UA. > What happens if an application does not ask permission, but just calls an API with this approach in place? No change to what happens today. I hope this helps! Doug
Received on Monday, 28 June 2010 20:59:25 UTC