Re: Draft policy requirements

Hi,

I've created an initial  Policy Requirements editors draft, see
> http://dev.w3.org/2009/dap/policy-reqs/
>
> Please review and propose additions or changes.
>
> I used material that we've discussed to date on the teleconferences,
> including  proposals from Paddy and myself.
>
> This draft is to give us something concrete to improve - it does not assume
> consensus on the material (at this point).
>

I think this is a good start.

I took an action to review it, so here are my high-level comments.

*1) Applicability: only widgets, or websites as well?

*If we intend that we will define a framework that can describe an access
control policy for website access to APIs, then we should say so explicitly.

Beyond that we can then discuss what impact that really has on a model. In
BONDI the primary impact is that a different set of subject attributes exist
for subjects that are websites. Each of those subject attributes should be
traceable back to some requirement or use case if possible.
*
2) Use cases for policy*

We've captured the idea that there must be a specific language for
describing a policy, and it must be based on XML, but we haven't really said
much more about what specifically we need to be able to express in the
policy. For this I think in a next revision we have to start writing down
some use cases that define (or imply) some specific things we may want to be
able to say in a policy.

We can write more formal definitions of these, but we could identify certain
kinds of policy statements that we think should be expressible, such as (for
Widgets):

   - A Widget whose signature chains to operator root can read and write
   from the PIM databases.


   - A Widget downloaded from weather.com can access geolocation coordinates
   if the user says it’s OK.


   - The weather.com Widget can connect to weather.com without notifying the
   user, except when roaming.


   - All Widgets with a reliably identified author can save data
   persistently if the user says it’s OK.


   - No Widget can get my location, no matter who trusts it.

(Agree or disagree with whether or not these examples are real requirements,
but they are illustrative of the kind of use cases we should be identifying
and discussing as requirements.)

Here are some more, for websites:

   - A reliably identified website can access geolocation coordinates if the
   user confirms it’s OK.


   - Any Website in a subdomain of mynetwork.com can read phone status
   properties.


   - Reliably identified Websites can send and receive SMS except to premium
   rate numbers.


   - evil.com cannot access any device APIs.


   - The weather.com igoogle widget can access geolocation coordinates but
   only if it’s embedded on the igoogle home page.

*3) User configuration
*
There are probably lots of requirements in this area, but one specific issue
relates to what happens to any user decisions (eg as a result of prompts,
even though we're avoiding them) and how they are recorded.

One principle we tried to adhere to in BONDI is that those user decisions
are themselves expressible in the policy language.

So, if for example, a policy says that a user must be prompted in order to
confirm an action X for a subject Y, then that fact can be "remembered" by
adding a policy-set and/or rule to the policy. Similarly, if there is a user
configuration setting that denies access to geolocation for a given set of
applications, then this setting shout itself be expressible in the policy
language. This means that the policy document is not just a way of creating
an initial policy configuration, but can be the sole and complete
representation of the access control configuration at any time.

Thanks - Paddy