Re: Policy - capability definition question

[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0195.html

On Mon, Jun 21, 2010 at 11:40 AM, Rich Tibbett <rich.tibbett@gmail.com>wrote:

> 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/
>>>
>>>
>>
>>
>