Re: Policy - capability definition question

Hi Frederick,

On Fri, Jun 18, 2010 at 5:50 PM, <Frederick.Hirsch@nokia.com> wrote:

> Thanks Richard.
>
> Which capabilities do you envision for contacts API? Can they be flagged in
> the WEB IDL?
>

The capabilities I envision for the Contacts API are expressed in [1].
Including these in WebIDL is an option though I hope that won't break any
tools relying on strict WebIDL definitions.


> The remainder of this message is a rough example, to try to get some
> concrete conversation on the list on how all this will work - to get less
> abstract in our discussions.
>
> How about
>
> interface ContactProperties withCapabilities
>
> implying a read/write/delete capability for every attribute in the
> ContactProperties interface?
>

Read only ContactProperties are defined with the 'readonly' keyword in
WebIDL (e.g. Contact.id). All other properties imply write and delete
functionality (or, more specifically for the Contacts API, the ability to
set an existing property to null rather than delete).

In that sense, do we need to define capabilities at the ContactProperties
level? I don't think access decisions need to be so granular...


>
> and with features as
>
> interface Contacts {    Contact <http://dev.w3.org/2009/dap/contacts/#idl-def-Contact>   create <http://dev.w3.org/2009/dap/contacts/#widl-Contacts-create> isFeature (in ContactProperties <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactProperties> attributes);    PendingOp find <http://dev.w3.org/2009/dap/contacts/#widl-Contacts-find> isFeature (in DOMString[] fields, in ContactFindSuccessCB <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactFindSuccessCB> successCB, in optional ContactErrorCB <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactErrorCB>? errorCB, in optional ContactFindOptions <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactFindOptions>? options);
> };
>
>
>
> interface Contact : ContactProperties <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactProperties> {    readonly attribute DOMString  id <http://dev.w3.org/2009/dap/contacts/#widl-Contact-id>;             attribute DOMString? serviceId <http://dev.w3.org/2009/dap/contacts/#widl-Contact-serviceId>;    Contact <http://dev.w3.org/2009/dap/contacts/#idl-def-Contact>   clone <http://dev.w3.org/2009/dap/contacts/#widl-Contact-clone> isFeature ();    PendingOp save <http://dev.w3.org/2009/dap/contacts/#widl-Contact-save> isFeature (in ContactSuccessCB <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactSuccessCB> successCB, in optional ContactErrorCB <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactErrorCB>? errorCB);    PendingOp remove <http://dev.w3.org/2009/dap/contacts/#widl-Contact-remove> isFeature (in ContactSuccessCB <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactSuccessCB> successCB, in optional ContactErrorCB <http://dev.w3.org/2009/dap/contacts/#idl-def-ContactErrorCB>? errorCB);
>
>
> (These are just examples of the idea, not sure how to do this best in
> WebIDL.)
>
>
Perhaps we could attach the capability to the description of each method
rather than in the WebIDL itself. The whole recommendation is normative and
so a soft approach should work just as well.

i.e. just adding 'DAP Capability: contacts.write' to the description,
linking 'DAP capability' to a description of the policy framework might just
do the trick.


> The implication here is that an access control decision granularity is at
> the level of accounts, relationships, etc assuming the find and/or save
> feature is allowed (both find and save needed for writing I assume).
>

Only save() is needed for writing. There may be situations where the user
can write new contacts but not read existing contact information, much like
one of the principles of the File Writer API.


>  If the feature is allowed, then there is a read and write capability for
> each capability definition that is input to the policy decision (maybe
> delete as well).
>
> Thus if the feature save is allowed, then a policy decision check would be
> to see if saving an update to relationships  in a contact would be allowed.
>

I'm not sure where this requirement is coming from. I'm not sure that policy
decision checks to this level should be allowed/required. A web app can
either update all fields for a contact or none (depending if the
contacts.write feature) has been authorized by the user/policy.


>
> I'm not sure I see commit in the WebIDL now, but I may be missing it.
>

s/commit/save


>
> I think a goal should be to define capabilities and features as part of
> WebIDL definitions, to allow automation etc for those that implement the
> policy framework. Obviously the number of capabilities can grow to be rather
> large across all the APIs so doing this manually is a non-starter in my
> opinion.
>

Which would be a good reason to include it within the WebIDL but I'm not
convinced that the capabilities need to be very large hence why I suggest a
softer approach, at least to start with (and add any complexity or WedIDL
tie-in from there).


>
> We also immediately see the issue of granularity related to access
> decisions.
>

My suggestion is that the Contacts API can make do with two
features/capabilities: contacts.read and contacts.write, mapped as defined
in [1] (s/commit/save). These access decision levels map identically to the
non trust relationship scenario non-normatively described in the Contacts
API: Appendix A.

>
> I may be confused here, so others can please help me understand this
> better, using contacts as a concrete example.
>
>  regards, Frederick
>
>
Thanks,

Richard



>
>
> On Jun 18, 2010, at 12:17 PM, ext Rich Tibbett wrote:
>
> Hi Frederick,
>
> I sent an email to the list in December defining how I saw capabilities
> mapping to the Contacts API. The API methods remain unchanged (except that
> commit() is now called save()).
>
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0195.html
>
> regards, Richard
>
> On Wed, Jun 16, 2010 at 2:39 PM, <Frederick.Hirsch@nokia.com> wrote:
>
>> Some time ago Daniel provided an overview of device capabilities [1] and a
>> pointer to BONDI definitions [2].
>>
>> It seems, however, that these definitions may not map directly to the DAP
>> API definitions, especially as the DAP interfaces evolve.
>>
>> Taking Contacts, as an example, the BONDI definitions include:
>>
>>  pim.contact.read Read the contacts stored in the terminal    pim.contact.writeWrites contacts to be stored in the terminal
>>
>>
>> However our current contacts editors draft [3] has find, create, clone,
>> save, remove as methods, as well as more granular access control
>> opportunities on the ContactProperties interface.
>>
>> It seems that this kind of issue might occur with a number of
>> specifications.
>>
>> In this case it seems we have capabilities for creation, deletion, and
>> update as well as find (and some possible granularity on find).
>>
>> If capabilities were marked in the Web IDL itself it would aid in
>> automatically generating, using and testing capabilities - is this an
>> approach worth considering?
>>
>> It appears we will need API specific definitions of capabilities.
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Feb/0142.html
>>
>> [2] http://bondi.omtp.org/1.1/apis/devcaps.html
>>
>> [3] http://dev.w3.org/2009/dap/contacts/
>>
>>
>
>