- From: <Frederick.Hirsch@nokia.com>
- Date: Tue, 17 Aug 2010 21:26:34 +0200
- To: <Claes1.Nilsson@sonyericsson.com>
- CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Claes Thanks for reviewing this document! Apparently the section on the phishing Abuse case has been incorrect since originally inserted in the document (revision 1.33, 30 March 2010). Thank you for catching that error. I have updated the text with the example in David's original email [1]. Other comments inline below. I have updated the proposal, see http://dev.w3.org/2009/dap/docs/policy-requirements-proposal.html regards, Frederick Frederick Hirsch Nokia [1] http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0155.html On Aug 16, 2010, at 10:16 AM, ext Nilsson, Claes1 wrote: > Hi, > > I read the document and have a few basic comments/questions. Please excuse me if I am addressing something that already has been discussed. I might have missed some mails due to my summer vacation. I pretty much made this revision in an attempt to simplify and consolidate the material in the document. You may have missed our general discussion of treating web as a different layer/stage than policy. > > Seems as section 2 covers the cases when the specific API itself implements API access control through some user interface as described by the "Security and Privacy Considerations" sections in the DAP API specifications and that section 3 and 4 describes the use cases when there is a prearranged trust relationships with users. Assuming this is correct: Yes, the intent I have here is to lay out our roadmap for policy, starting with none for web APIs and progressing to use of declarative policy > > * Are untrusted (unsigned) widgets a part of the "Un-managed Web Browser" use case or another separate use case? Untrusted widgets (either unsigned or untrusted signature) should be treated the same as un-managed web browser - API use should be conservative. I've added a note to that effect in the proposal draft. > > * Does the "Trusted Widget" use case without a delegated authority assume a user configured access control policy or does it assume user approving API access at widget installation time? It could be using policy, and then treated as the delegated authority case. If not, it may have additional APIs available beyond un-managed case, but may require installation similar to application. Added text to the proposal. > > Section 3.3: > * The examples refer to web sites, not trusted widgets. > Oops, thanks. They ended up in the wrong section with all the restructuring I did. Fixed in revision to proposal. > Editorial: > > Section 4.1: > * First sentence says "The enterprise Managed Device API use case ...". Should be "The Delegated Authority Device API use case ...". fixed in proposal, thanks > > Section 5.3 and 5.4: > * Contains the same text. fixed in proposal, thanks! please review. > > Regards > Claes > > -----Original Message----- > From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Frederick.Hirsch@nokia.com > Sent: den 14 augusti 2010 02:58 > To: public-device-apis@w3.org > Cc: Frederick.Hirsch@nokia.com > Subject: proposed update to policy requirements > > I put together a proposed update to the policy requirements editors draft. > > I restructured it to reflect our latest thinking that there are essentially three cases: web, trusted widget and managed policy with requirements that build on the more general cases. > > It turns out most of what we had before is still relevant, but I consolidated and reorganized it. > > See http://dev.w3.org/2009/dap/docs/policy-requirements-proposal.html > > If the WG agrees I propose to update the current editors draft with these changes. > > regards, Frederick > > Frederick Hirsch > Nokia > > > >
Received on Tuesday, 17 August 2010 19:27:16 UTC