- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 06 Jan 2011 21:16:16 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv1021
Modified Files:
Overview.html
Log Message:
fix spelling errors and typos, clarify 2.1.3 last two bullets, mention cert revocation in 2.2.2
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -d -r1.51 -r1.52
--- Overview.html 10 Sep 2010 13:05:41 -0000 1.51
+++ Overview.html 6 Jan 2011 21:16:14 -0000 1.52
@@ -2,7 +2,7 @@
<html>
<head>
<title>Device API Access Control Use Cases and Requirements</title>
- <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8' />
<style type="text/css">
.story {
margin: 1em 0em 0em;
@@ -48,7 +48,7 @@
</head>
<body>
<section id='abstract'>
- With the emergence of numerous new APIs in Web browsers and runtime engines, the need to control which Web sites and applications can make use of these APIs increases. This document describes use cases and requirements for controling access to these APIs.
+ With the emergence of numerous new APIs in Web browsers and runtime engines, the need to control which Web sites and applications can make use of these APIs increases. This document describes use cases and requirements for controlling access to these APIs.
</section> <!-- abstract -->
<section id='sotd'>
@@ -69,12 +69,15 @@
<section id="defs">
<h2>Definition</h2>
- <p>A <dfn>non-safe API</dfn> is an API that shares sensitive user information or makes a commitment for the user to a third-party (e.g. paying a fee).</p>
+ <p>A <dfn>non-safe API</dfn> is an API that shares sensitive
+ user information or makes a commitment for the user to a
+ third-party (e.g. paying a fee).</p>
</section>
</section> <!-- introduction -->
<section id="interactions" class="informative">
<h2>Access Control Interactions</h2>
- <p>Three main types of interactions haven been identified for controling access to non-safe APIS:</p>
+ <p>Three main types of interactions have been identified for
+ controlling access to non-safe APIS:</p>
<ul>
<li>based on granular user consent, for every first call of a sensitive API,</li>
<li>based on user consent for a set of APIs at once, packaged into a single interaction (e.g. at “installation” time),</li>
@@ -114,7 +117,12 @@
are the same.</p>
- <p>To make it easier for the user to understand what he is granting access to, the access control interactions need to be as integrated as possible as a part of the task specific workflow, thus not necessarily appearing as a permission dialog. Relying on the user pressing the shutter button to take a picture is more effective than asking him if he agrees with sharing a picture.</p>
+ <p>To make it easier for the user to understand what he is
+ granting access to, the access control interactions need to be as
+ integrated as possible as a part of the task specific workflow,
+ thus not necessarily appearing as a permission dialog. Relying on
+ the user pressing the shutter button to take a picture is more
+ effective than asking him if he agrees with sharing a picture.</p>
<p>Prompts should be eliminated whenever possible. Many prompts do not provide any meaningful security because:</p>
<ul>
@@ -142,11 +150,13 @@
installation or invocation).</li>
<li>As a result, non-safe APIs MUST use asynchronous calls for operations that require user consent.</li>
<li>Non-safe APIs SHOULD permit to get user consent in interactions that are well-integrated in the workflow of the underlying operation.</li>
- <li>In an untrusted context, user consent for a given non-safe API SHOULD NOT enduce consent for another non-safe API.</li>
+ <li>In an untrusted context, user consent for a given non-safe
+ API SHOULD NOT imply consent for another non-safe API.</li>
<li>when a non-safe API expose multiple non-safe operations, the API MUST describe the granularity of user consent if that granularity is not part of the user workflow; the parameters to which this granularity can be applied include:<ul>
<li>separate consent for each operation, or grouped for the whole API,</li>
- <li>separate for each call or valid for a longer time,</li>
- <li>persistent across users visits or not.</li>
+ <li>persistent for each call in a given session,</li>
+ <li>persistent for each call over a period of time spanning
+ multiple sessions.</li>
</ul>
</li>
</ul>
@@ -191,14 +201,18 @@
<ul>
<li>Non-safe APIs SHOULD define an identifier for the various permissions they require.</li>
<li>The security framework SHOULD refer to these API permissions identifiers to allow grouping them in a single user consent operation.</li>
- <li>when identity is checked through the use of signature in conjunction with PKI mechanisms, the security framework MUST require the verification of the signatuure, and MUST require validation of the certificate chain to a knonw trust root.</li>
+ <li>when identity is checked through the use of signature in
+ conjunction with PKI mechanisms, the security framework MUST
+ require the verification of the signature, and MUST require
+ validation of the certificate chain to a known trust
+ root. Certificate revocation SHOULD be considered.</li>
</ul>
</section>
</section>
<section id='delegated-authority-case'>
<h3>Delegated Authority</h3>
- <p>Delegated authority use case includes refers to the use of
+ <p>Delegated authority use case refers to the use of
explicit and interoperable policy definitions to control the use of
an extensive set of APIs, safe and unsafe. Such rules may be used
in the context of a trusted widget or of well-identified web site, with clients that support it.</p>
@@ -214,7 +228,9 @@
<h4>Analysis</h4>
<p>In many professional contexts, allowing access to private or sensors data available through connected devices creates an unacceptable risk.</p>
<p>In these contexts, being able to enforce and update a policy that determines who can make use of these data across devices and platforms can be a decisive aspect of the adoption of a given technology.</p>
- <p>To that end, it should be possible to describe platform-independent and declarative policies that determine what APIs can be used from what Web site or application.</p>
+ <p>To that end, it should be possible to describe
+ platform-independent and declarative policies that determine which
+ APIs can be used from what Web site or application.</p>
</section>
<section id='delegated-authority-story2'>
<h4>User Story: Third-party protection against malware</h4>
@@ -281,7 +297,7 @@
a policy that supports a specific objective - such as to
limit access to APIs
to only those web applications that are themselves
- distributed or vefiried by the policy
+ distributed or verified by the policy
authority (e.g. to control its exposure to the financial
risk of abuse of device
APIs).
@@ -351,7 +367,7 @@
SMS capability is something that is part of the original
application. Examples of this have been seen in the past,
created from games and this model could be used for
- ‘diallers’ too (which plagued the desktop world in the
+ ‘dialers’ too (which plagued the desktop world in the
days of dial-up networking). There have been recent
warnings about this kind of abuse from security firms.
</p>
Received on Thursday, 6 January 2011 21:16:18 UTC