Re: Policy work items - request for proposals

I'm not really interested or vested in the contacts API. I would be willing
to help with use cases for the filesystem API though.

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

> Are you able to help with documenting use cases, say for the contacts API?
>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Nov 4, 2009, at 7:22 AM, ext Ian Fette (イアンフェッティ) wrote:
>
>  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.
>>
>>
>>
>>
>>
>>
>