Re: Policy - capability definition question

Thanks Richard.

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

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?

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.)

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).  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 I see commit in the WebIDL now, but I may be missing it.

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.

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

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

regards, Frederick

Frederick Hirsch
Nokia



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<mailto: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.write       Writes 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/