Re: Next steps for Policy Requirements draft?

Hi Frederick, all,

Do we want to make (or consider) a reference to the WARP spec/concept in the requirements doc? I am wondering how relevant the declaration of <feature> and <access> elements fit into the policy/security requirements. I believe there is some relevance, if I'm not mis-understood.

Thanks,
Suresh


----- Original Message -----
From: public-device-apis-request@w3.org <public-device-apis-request@w3.org>
To: public-device-apis@w3.org <public-device-apis@w3.org>
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Sent: Wed Feb 10 08:44:24 2010
Subject: Next steps for Policy Requirements draft?

Before we progress the Policy Requirements editors draft [1] to FPWD  
we may wish to address some issues:

1. Do we want to indicate use cases/requirements related to the REST  
discussion we have been having?

If we are serious about this approach then we probably should. Any  
volunteers to take an action?

Along the lines of "Requirement to use various web authorization  
mechanisms such as OAuth"
Note that I suspect OAuth still requires backend policy somewhere so  
may not preclude the XACML style rules on the device...

2. Incorporate material from currently open actions

- ACTION-45: David Rogers to Provide use case with threat model  
scenarios

- ACTION-48: Suresh Chitturi to Propose a definition for API access  
control, and a possible model for policy enforcement

for the definition

  - ACTION-77: John Morris to Provide a discussion of requirements  
for privacy

or is privacy requirements another document, or per API? I think  
common considerations  should be in this document, however
Retitle this document "DAP Security, Privacy and Policy use cases and  
requirements"?

    - ACTION-79: Paddy Byers to Integrate his use cases in policy  
requirements

   • Dan Applequist's TAG message about privacy per api or grouping
Add note to document that additional notes on security/privacy  
specific to APIs will appear in API docs?

3) Issues noted in document, next steps?

Features defined according to CRUD, one feature for Create, Read,  
Update, Delete?

Feature parameters to avoid explosion of capabilities and features?  
e.g. file open with either read or write parameter. ( see http:// 
lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/ 
minutes-2009-10-07.html#item03 )

User authorization vs other policy authority

Support for trust models other than user security decisions needed?

What is the correct granularity of security decisions presented to  
user? Perhaps this should be stated in policy. What is the linkage to  
application logic?

( see ISSUE-21 - OPEN ) Is access control at the feature level  
required or is access control at the device capability level adequate?

4) Any other next steps?



regards, Frederick

Frederick Hirsch, Nokia
Co-Chair DAP WG

[1] http://dev.w3.org/2009/dap/policy-reqs/







---------------------------------------------------------------------
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, 10 February 2010 14:17:57 UTC