Re: Policy work items - request for proposals

I'm not sure I follow the reasoning of starting off by defining capability
definitions "in conjunction with the API development" -- I would much rather
say "Here are the use cases we're intending to support. To do that, we think
we need an API that vaguely does the following things. Now how can we design
that API in such a way that it has some reasonable security model?"

I think the first step is to collect use cases for each proposal, before
that exists I think trying to define "capabilities" is going the wrong
direction.

2009/11/4 Frederick Hirsch <Frederick.Hirsch@nokia.com>

> Ian
>
> I agree that security needs to be considered in conjunction with the APIs,
> I don't think we disagree.
>
> WG members can help by taking actions, and to do this we need to break a
> bigger problem into smaller aspects and get  concrete proposals.
>
> For example we can make proposals regarding capability definitions in
> conjunction with the API development - I proposed this be in the API
> documents themselves, Robin suggested a separate document, but regardless I
> think we can start on this work.
>
> Do you have any additional suggestions on how to move this work forward?
> Are you able to help generate any proposals related to policy and security?
>
> Thanks
>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Nov 2, 2009, at 5:36 PM, ext Ian Fette (イアンフェッティ) wrote:
>
>  I don't really know what this means. I think the point that we tried to
>> make in the joint WebApps/DAP f2f was that it doesn't make sense to separate
>> the discussion of API from security considerations and UI. I don't
>> understand what any of 1-3, or "access control model" in the abstract, mean.
>>
>> I for one remain highly skeptical of a "policy framework" that is
>> independent of security UI and APIs, and think that designing APIs that then
>> plug into some framework as a way to avoid having discussions about security
>> aspects in the design of said APIs, is a recipe for disaster.
>>
>> -Ian
>>
>> 2009/11/2 Suresh Chitturi <schitturi@rim.com>
>> Hi Frederick, all,
>>
>> I would be happy to look at the security aspects in general for the
>> API/features and access control model for the same.
>>
>> To be concrete I guess this translates to items 2 and 5? If there are
>> others who are also interested perhaps it can be a joint action item.
>>
>> Regards,
>> Suresh
>>
>> -----Original Message-----
>> From: public-device-apis-request@w3.org
>> [mailto:public-device-apis-request@w3.org] On Behalf Of Frederick Hirsch
>> Sent: Monday, November 02, 2009 2:15 PM
>> To: W3C Device APIs and Policy WG
>> Cc: Frederick Hirsch
>> Subject: Policy work items - request for proposals
>>
>> During the morning F2F session I recorded the following somewhat
>> independent work items:
>>
>> 1. trust model definition
>> 2. access control model definition
>> 3 capability definitions for APIs in DAP charter and related W3C APIs
>> 4. features - definition
>> 5 security considerations for each API,  privacy concerns for each
>> API, definition of likely user prompts based on API functionality that
>> have security implications (e.g. take picture query also gives
>> security permission)
>> 6 security threat models and countermeasures/ security use cases
>> 7 Context for security decisions - what additional information can be
>> included in decision
>> 8. FileAPI security model and simplification
>>
>> Is this list complete, are the items somewhat orthogonal?
>>
>> Do we have volunteers to help with concrete proposals, especially for
>> the list of capability definitions, API security considerations,
>> security use cases/threats.
>>
>> regards, Frederick
>>
>> Frederick Hirsch, Nokia
>> Co-Chair, W3C DAP Working Group
>>
>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from your
>> system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>>
>>
>