W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Re: Policy work items - request for proposals

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Wed, 4 Nov 2009 06:29:02 -0800
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, Suresh Chitturi <schitturi@rim.com>, W3C Device APIs and Policy WG <public-device-apis@w3.org>
Message-Id: <9B313662-2BA3-488A-AF52-CF9629B2D48F@nokia.com>
To: "ifette@google.com" <ifette@google.com>

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?


regards, Frederick

Frederick Hirsch

On Nov 2, 2009, at 5:36 PM, ext Ian Fette (イアンフェッティ)  

> 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 14:30:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC