- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 08 Nov 2009 18:59:33 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv10911
Modified Files:
Overview.html
Log Message:
changes discussed at F2F, ACTION-49
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- Overview.html 27 Oct 2009 00:02:12 -0000 1.1
+++ Overview.html 8 Nov 2009 18:59:31 -0000 1.2
@@ -36,40 +36,34 @@
<h2>Definitions</h2>
<p>The following definitions are used in this document.</p>
<dl>
- <dt>application</dt>
+ <dt>Application</dt>
<dd>Code that may make use of DAP APIs. This can be widgets, web
applications running in a browser, for example. </dd>
- <dt>API<dt>
+
+ <dt>API</dt>
<dd>Collection of interfaces structured in terms of methods and
properties used by applications to access device
- functionality. Related interfaces may be grouped into
+ capabilities. Related interfaces may be grouped into
modules. Interfaces may be defined using WebIDL. Note that
- interfaces, by themselves, are not necessarily associated with a specific
- device capability. For example, a Stream interface (providing serial read,
- write and seek functionality) may be used to interact with a local file, or
- a Bluetooth connection. Similarly, the DCCI API could be used to access a
- wide range of different device capabilities through a common set of
- interfaces.
+ interfaces, by themselves, are not necessarily associated
+ with a specific
+ device capability.
</dd>
+ <dt>Feature</dt>
+ <dd>A Feature is a defined way
+of accessing certain specified define capabilities using an associated API.</dd>
<dt>device capability</dt>
<dd>device resource or functionality requiring access
- control. Examples of device capabilities are the ability to read a local
- file, or to discover nearby Bluetooth devices, or to send an SMS
- message. In principle, device capabilities can be defined in a way that is
+ control.</dd>
+ <dd> Examples of device capabilities are the ability to
+ read a local
+ file, or to discover nearby Bluetooth devices, or to send an
+ SMS
+ message. In principle, device capabilities can be defined
+ in a way that is
independent of the specific APIs that an application uses to access
- them. Note that a given API may require different
- capabilities, as in this JavaME example:
- Connector.open("file://sdcard/my_dog.jpg");
-
- would use a "local filesystem" feature, whereas
-
- Connector.open("btspp://<hostname>:<parameters>");
-
- would use a "Bluetooth serial port profile" feature.
-
- </dd>
- <dt>feature</dt>
- <dd> is ability to use capability for a specific API</dd>
+ them.
+ </dd>
</dl>
</section>
@@ -131,8 +125,8 @@
<ul>
<li>Access control policy MUST be stated in declarative manner.</li>
<li>The DAP security framework MUST allow a flexible choice of
- policy decisions for device capability and feature
- access.</li>
+ policy decisions for feature
+ access to device capabilities.</li>
<li>It MUST be possible to declare policy in XML
language</li>
<li>The DAP policy language MUST define an XML syntax for
@@ -193,29 +187,46 @@
less inclined to take any security decision seriously, which further
undermines the effectiveness of a user-driven access control system.
</p><p>
- There will unavoidably be situations, however, where the user is required to
- make access control decisions when web applications wish to use sensitive
- APIs. The key issue remains, therefore, and DAP needs to ensure a framework
- is provided that allows it to happen, and maximizes its effectiveness,
- rather than seeking to eliminate it altogether.
+ There will unavoidably be situations, however, where the
+ user is required to
+ make access control decisions when web applications wish to
+ use sensitive
+ APIs. The key issue remains, therefore, and DAP needs to
+ ensure a framework
+ is provided that allows it to happen, and maximizes its
+ effectiveness,
+ rather than seeking to eliminate it altogether.
</p><p>
- Modal prompts (i.e. prompts that block all other user interaction until
- dismissed) seriously compromise user experience and are avoidable.
+ Modal prompts (i.e. prompts that block all other user
+ interaction until
+ dismissed) seriously compromise user experience and are
+ avoidable.
</p><p>
- Any prompt or dialog that requests a user security decision at runtime (e.g.
- at the time a sensitive action is attempted) can be non-modal if the API
- that initiates it is asynchronous. DAP APIs must be designed so that all
- operations that could potentially trigger a prompt are asynchronous.
+ Any prompt or dialog that requests a user security decision
+ at runtime (e.g.
+ at the time a sensitive action is attempted) can be
+ non-modal if the API
+ that initiates it is asynchronous. DAP APIs MUST be designed
+ so that all
+ operations that could potentially trigger a prompt are
+ asynchronous.
</p><p>
- If a sensitive operation requires some user interaction to initiate it (such
- as choosing a file to upload, or pressing the shutter on a camera), then
- this interaction can be arranged so that it is an implicit user
- authorization. Whether or not this is possible depends on the operation or
- API in question.
+ The semantics of some APIs can be defined such that they
+ require user interaction that is meaningful to the user, yet
+ also imply consent to the action. Such implicit consent
+ eliminates the need for a security access dialog entirely,
+ incorporating it into the application semantics. An example is
+ a camera API that enables the user to take a photograph, but
+ requires them to press a shutter key to do so. Another example
+ is an API that produces a message template, but requires the
+ user to press "send" to actually send the message.
</p><p>
- Given the wide range of possible valid means of eliciting user security
- decisions, DAP should be minimally prescriptive about the user experience,
- and should not assume that the same user experience is appropriate for every
+ Given the wide range of possible valid means of eliciting
+ user security
+ decisions, DAP should be minimally prescriptive about the
+ user experience,
+ and should not assume that the same user experience is
+ appropriate for every
API.
</p>
</section>
Received on Sunday, 8 November 2009 18:59:45 UTC