Re: Policy - capability definition question

Richard

I was thinking if it was in the WebIDL definition itself we could use tools to generate code/test cases/policy templates etc which we cannot do with text, however I can also understand the desire to minimize changes to WebIDL.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 21, 2010, at 6:40 AM, ext Rich Tibbett wrote:

Hi Frederick,

On Fri, Jun 18, 2010 at 5:50 PM, <Frederick.Hirsch@nokia.com<mailto: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<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/