Re: Policy work items - request for proposals

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

Received on Wednesday, 4 November 2009 15:27:23 UTC