2009/dap/policy-reqs FPWD.html,NONE,1.1

Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv14599

Added Files:
	FPWD.html 
Log Message:
add fpwd output for publication


--- NEW FILE: FPWD.html ---
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head>
    <title>Device API Access Control Requirements</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
    
    
    
  <link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Device API Access Control Requirements</h1><h2 id="w3c-working-draft-16-june-2010"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 16 June 2010</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100616/">http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100616/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/dap-policy-reqs/">http://www.w3.org/TR/dap-policy-reqs/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2009/dap/policy-reqs/">http://dev.w3.org/2009/dap/policy-reqs/</a></dd><dt>Editors:</dt><dd>Laura Arribas, <a href="http://vodafone.com/">Vodafone</a></dd><dd>Paddy Byers, <a href="http://aplx.com/">Aplix</a></dd><dd>Marcin Hanclik, <a href="http://access-company.com/">ACCESS Co., Ltd.</a></dd><dd>Frederick Hirsch, <a href="http://nokia.com/">Nokia</a></dd><dd>David Rogers, <a href="http://omtp.org/">OMTP</a></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium"><acronym title="World Wide Web Consortium">W3C</acronym></acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology"><acronym title="Massachusetts Institute of Technology">MIT</acronym></acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="htp://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
    <div id="abstract" class="introductory section"><h2>Abstract</h2>
      This document defines Device API Access Control Requirements  
      and the corresponding use cases. 
    </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> as a First Public Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-device-apis@w3.org">public-device-apis@w3.org</a> (<a href="mailto:public-device-apis-request@w3.org?subject=subscribe">subscribe</a>, a href="http://lists.w3.org/Archives/Public/public-device-apis/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/43696/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes cotains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#definitions" class="tocxref"><span class="secno">2. </span>Definitions</a></li><li class="tocline"><a href="#user-control" class="tocxref"><span class="secno">3. </span>User Managed Access</a><ul class="toc"><li class="tocline"><a href="#use-case-pm1--user-controlled-configuration" class="tocxref"><span class="secno">3.1 </span>Use case PM1: user-controlled configuration</a></li><li class="tocline"><a href="#use-case-pm2--user-delegated-configuratio" class="tocxref"><span class="secno">3.2 </span>Use case PM2: user-delegated configuration</a></li><li class="tocline"><a href="#use-case-pi2--portability-of-user-settings" class="tocxref"><span class="secno">3.3 </span>Use case PI2: portability of user settings</a></li><li class="tocline"><a href="#prompts" class="tocxref"><span class="secno">3.4 </span>Prompts</a></li><li class="tocline"><a href="#user-control-rqmts" class="tocxref"><span class="secno">3.5 </span>User Control Requirements</a></li><li class="tocline"><a href="#portable-policy" class="tocxref"><span class="secno">3.6 </span>Portable Policy</a></li></ul></li><li class="tocline"><a href="#enterprise-managed-access" class="tocxref"><span class="secno">4. </span>Enterprise Managed Access</a><ul class="toc"><li class="tocline"><a href="#use-case-pm3--external-policy-authority" class="tocxref"><span class="secno">4.1 </span>Use case PM3: external policy authority</a></li><li class="tocline"><a href="#use-case-pi1--device-independent-policy-defintion" class="tocxref"><span class="secno">4.2 </span>Use case PI1: device-independent policy definition</a></li><li class="tocline"><a href="#use-case-pi3--policy-provisioning-as-part-of-service-deployment" class="tocxref"><span class="secno">4.3 </span>Use case PI3: policy provisioning as part of service deployment</a></li><li class="tocline"><a href="#policy-interoperability" class="tocxref"><span class="secno">4.4 </span>Policy interoperability</a></li><li class="tocline"><a href="#enterprise-requirements" class="tocxref"><span class="secno">4.5 </span>Enterprise Requirements</a></li></ul></li><li class="tocline"><a href="#abuse-cases" class="tocxref"><span class="secno">5. </span>Abuse Cases</a><ul class="toc"><li class="tocline"><a href="#premium-rate-abuse" class="tocxref"><span class="secno">5.1 </span>Abuse Case AC1: Premium Rate Abuse</a></li><li class="tocline"><a href="#privacy-breach" class="tocxref"><span class="secno">5.2 </span>Abuse Case AC2: Privacy Breach</a></li><li class="tocline"><a hre="#integrity-breach" class="tocxref"><span class="secno">5.3 </span>Abuse Case AC3: Integrity Breach</a></li><li class="tocline"><a href="#phishing" class="tocxref"><span class="secno">5.4 </span>Abuse Case AC4: Phishing</a></li></ul></li><li class="tocline"><a href="#capabilities" class="tocxref"><span class="secno">6. </span>Capabilities</a><ul class="toc"><li class="tocline"><a href="#policy-capability-requirements" class="tocxref"><span class="secno">6.1 </span>Capability Requirements</a></li><li class="tocline"><a href="#issue---features--relationship-to-capabilities--crud" class="tocxref"><span class="secno">6.2 </span>Issue - Features, relationship to capabilities, CRUD</a></li></ul></li><li class="tocline"><a href="#framework" class="tocxref"><span class="secno">7. </span>Security Framework</a><ul class="toc"><li class="tocline"><a href="#framework-rqmts" class="tocxref"><span class="secno">7.1 </span>Security Framework Requirements</a><ul class="toc"><li class="tocline"><a href="#policy-integrity-rquirements" class="tocxref"><span class="secno">7.1.1 </span>Policy Integrity Requirements</a></li></ul></li><li class="tocline"><a href="#access-control-requirements" class="tocxref"><span class="secno">7.2 </span>Access Control Requirements</a></li></ul></li><li class="tocline"><a href="#examples-of-statements-or-rules-that-may-be-expressed-in-a-policy" class="tocxref"><span class="secno">8. </span>Examples of statements or rules that may be expressed in a policy</a></li><li class="tocline"><a href="#out-of-scope" class="tocxref"><span class="secno">9. </span>Out of Scope</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div> <!-- abstract -->

    <div id="introduction" class="section">
      <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
      <p>
        The DAP working group is defining APIs designed to enable
        application access to device resources, including personal
        contact information such as calendar and contacts information,
        system information such as network information, and other
        information. Much of this information is sensitive and
        potentially misused. For this reason the DAP working group
        charter explicitly calls out the need to control access to
        this information, such as through the use of policy.
      </p>
      <p>
        This is complicated by constraints in two dimensions, end user
        affiliation and application type. </p>
      <p>End user affiliation plays a role in determining what a user is
        allowed to do. An end user might 
        be an employee of a corporation or subscriber to
        an operator network. In either case, the corporation or
        network operator may wish to set constraints on what
        applications the user accesses may do, by defining and using
        an access control policy. Alternatively a user may not be
        acting as an employee and not subject to network operator
        constraints (at least for now with many Internet connections),
        but may wish to personally control what Internet applications are
        allowed to do.
      </p>
      <p>
        Second, there are two types of application under consideration by the
        DAP WG. First, there are <acronym title="World Wide Web Consortium">W3C</acronym> widgets, applications that are created
        with certain constraints, that might be signed by a source, enabling
        source authentication. Second are full web applications, which may
        come from any web site the user may access.  These two types of
        applications present different challenges and constraints.
      </p>
      <p>
        Taken together, these two cases provide four different possibilities.
        </p>
        <table class="simple">
	      <tbody><tr><th>Model/Environment</th><th>Widget</th><th>Web</th></tr>
	      <tr><td>User Controlled</td><td>Explicit permission by
	          dialog, policy with trust based on signed widget or secured installation</td><td>Explicit permission by dialog, user
	          mediated introduction, distributed trust mechanisms like  OAuth (?)</td></tr>
	      <tr><td>Enterprise/Operator</td><td>Policy, Trust based on signed
              widget or secured installation</td><td>Policy with trust based on Federated
              Identity</td></tr> 
        </tbody></table>
    </div>  <!-- introduction -->

    <div id="definitions" class="section">
      <!--OddPage--><h2><span class="secno">2. </span>Definitions</h2>
      <p>The following definitions are used in this document.</p>
      <dl>
        <dt>Access Control</dt>
        <dd><p>Controlled access to functionality or resources by a
          policy enforcement point based on rules defining which
          access is permitted. Enforcement can occur at runtime when
          supported by the API framework and is supported by
          applications declaring needed access.
          </p>
        </dd>
        <dt>Application</dt>
        <dd><p>An application is code  that may make use of DAP Device
          APIs. For the purposes of DAP, such  applications are either
          Javascript code contained in a web page or a <acronym title="World Wide Web Consortium">W3C</acronym> Widget.
        </p></dd>

        <dt>Device API</dt>
        <dd><p>A Device API is a collection of Javascript interfaces
          structured in
          terms of methods and properties. Device APIs are  used by
          applications to access Device
          Capabilities.</p>
        </dd>
        <dt>Device Capability</dt>
        <dd><p>A Device Capability is device
          functionality or device resource(s) exposed by standardized
          APIs.
        </p></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.  Device Capabilities may be defined
          in a way that is
          independent of the specific Device APIs that an application
          uses to access
          them.
        </dd>
        <dd><p>
          Although there are simple Device APIs that provide access only to
          a single Device Capability,  there are also
          more complex APIs that expose multiple Device Capabilities; examples
          might include a camera API that provides the ability to geotag a photo
          with the current location, or a messaging API that provides the
          ability to access documents stored locally and attach them to outgoing
          messages. Therefore, enabling or disabling access to a specific Device
          Capability may not directly correspond to enabling or disabling
          access to a single Device API interface.</p>
        </dd>
        <dt>Consent</dt>
        <dd><p>Consent is a user action that indicates that the user agrees
            with an action, such as using an API to expose information to an
            application. Such consent may be explicit or implicit.
        </p></dd>
        <dd><p>Explicit consent is a  user action directly related to
            a query for the user's consent, for an 
            action to be taken by the application, or for an
            application lifecycle 
            action. An example of explicit consent for an application
            action is a 
            positive user response to a query by the web runtime,
            asking whether an 
            application should be allowed to take a
            photograph. Examples of explicit 
            consent for an application lifecycle action include a positive user
            response to a query by:</p>
          <ul>
            <li>A positive user response to a query by the web runtime upon
                application installation, asking whether an explicitly
                disclosed set of 
              API requests by the application should be allowed.</li>
            <li>A positive user response to a query by the application
              storefront upon application selection and download,
              asking whether an 
              explicitly disclosed set of API requests by the
              application should be 
              allowed.</li>
          </ul>
        </dd>
        <dd><p>Implicit Consent occurs when a user takes an action that
          implies their desire to have an action occur, implying
          permission for needed resources.
          An example is pressing a camera
          shutter to take a photograph, implying consent to the act of
          taking a photograph.</p></dd>
      </dl>
    </div> <!-- definitions -->
    <div id="user-control" class="section">
    <!--OddPage--><h2><span class="secno">3. </span>User Managed Access</h2>
    <p>This section outlines use cases and requirements to support
    user controlled access control.</p>
    <div id="use-case-pm1--user-controlled-configuration" class="section">
      <h3><span class="secno">3.1 </span>Use case PM1: user-controlled configuration</h3>
      <p>
        In this use-case:
      </p>
      <ul>
        <li>
          the user of a device is the sole authority that decides
          access rights of 
          applications;
        </li>
        <li>
          there is a "universal default" initial policy configuration;
        </li>
        <li>
          there is no  external policy authority and hence no
          externally-triggered 
          policy update. Policy maintenance occurs only to the extent
          that the user 
          modifies configuration settings interactively via a
          "preferences" facility, or 
          asks the UA to remember certain responses to prompts.
        </li>
      </ul>
      <p>
        This use-case is the expected case in most situations where
        there is no 
        external policy authority such as a network operator or enterprise.
      </p>
      <p>
        Although the initial configuration is "empty" (ie it only
        contains universal 
        default rules), it is possible for the policy to be extended
        over time as the 
        cumulative result of explicit user configuration and
        persistently remembered 
        user decisions
      </p>
      <p>
        The configured policy, at any given time, may be stored
        locally on the device 
        or may be stored remotely and be accessible via a network
        service, or both. 
      </p>
    </div> <!-- PM1 -->
    <div id="use-case-pm2--user-delegated-configuration" class="section">
      <h3><span class="secno">3.2 </span>Use case PM2: user-delegated configuration</h3>
      <p>
        In this use-case:
      </p>
      <ul>
        <li>
          the user of a device delegates authority for access control
          policy to an 
          external service provider;
        </li>
        <li>
          the external service provider provides advice on the
          trustworthiness of 
          specific applications, and determines an access control
          policy that embodies 
          that advice. The advice may be based on a knowledgebase of
          known trustworthy 
          and/or malicious applications, or algorithms for detecting malicious
          behavior, or both;
        </li>
        <li>
          the policy defined by the external authority is updated
          regularly in 
          response to new information on known threats.
        </li>
      </ul>
      <p>
        The policy configuration provided by the external policy
        provider may be 
        supplemented by user control as in PM1.
      </p>
      <p>
        The configured policy, at any given time, may be stored
        locally on the device 
        or may be stored remotely and be accessible via a network
        service, or both. 
      </p>
      <p>
        This use-case mirrors current practice with products such as
        virus scanners or 
        other malware detectors.
      </p>
    </div> <!-- PM2 -->
    <div id="use-case-pi2--portability-of-user-settings" class="section">
      <h3><span class="secno">3.3 </span>Use case PI2: portability of user settings</h3>
      <p>
        A user may establish a policy configuration (through explicit
        configuration of 
        preferences, and remembered decisions) and there is the option
        of reusing this 
        configuration across multiple devices. A user with multiple
        devices may wish 
        for their security preferences to be consistent (or to at
        least have the 
        option of consistency) across those devices. Rather than have
        to manually 
        configure the preferences on each device, it should be
        possible for there to 
        be a seamless security experience across devices, e.g. by
        switching SIM card 
        between devices and as a result automatically applying a
        policy resident on 
        the SIM card or synchronizing with a network-based policy
        management system. A 
        specific case is the case where a user wishes to transfer a
        configuration from 
        an old device to a new device. This is relevant to Policy
        Management use cases 
        PM1, PM2, PM3.
      </p>
    </div> <!-- PI2 -->
    <div id="prompts" class="section">
      <h3><span class="secno">3.4 </span>Prompts</h3>
        <p>
          Prompts should be eliminated whenever possible. Many prompts
          do not provide 
          any meaningful security because:</p> 
          <ul>
            <li>they don't provide the user with the information
              needed to make an 
              informed security decision;</li>
            <li>with modal prompts, the user is inclined simply to
              dismiss the prompt and permit the operation 
              just because that's what's needed for the application to
              continue.</li>
          </ul>
      <p>
          If prompts are shown and dismissed as a matter of routine,
          then the user is 
          less inclined to take any security decision seriously, which further
          undermines the effectiveness of a user-driven access control system.
        </p><p>
          It is important to note that  modal prompts (i.e. prompts
          that block all other user
          interaction until
          dismissed) seriously compromise the user experience. Modal
          security prompts <em class="rfc2119" title="should">should</em> be avoided.
        </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 <em class="rfc2119" title="must">must</em> be designed
          so that all
          operations that could potentially trigger a prompt are
          asynchronous.
        </p>
        <p>
          If user decisions
          are themselves expressible in the policy language, then they can be
          "remembered" by
          adding a policy-set and/or rule to the policy. Similarly, user
          configuration settings should be possible in the policy
          language.  This means that the policy document is not just a
          way of creating
          an initial policy configuration, but can be the sole and complete
          representation of the access control configuration at any time.
        </p>
        <div class="issue">
        <ul>
          <li>      <p class="issue">User authorization vs other
          policy authority</p> 
            <p class="issue">
              Support for trust models other than user security
              decisions needed? 
            </p>
            <p>
              This issue is who makes security decisions; in
              particular whether the user 
              is the sole authority for decisions (whether by
              configuration of settings, 
              or responses to prompts, or both) or there is another
              authority that 
              determines the rights given to an application.
            </p><p>
              Many existing ecosystems for mobile applications are
              based on a trust model
              in which a particular distributor (such as a network
              operator) certifies an
              application as trustworthy, eliminating run-time user
              prompts in some cases. This approach
              avoids the disadvantages of prompts, but at the expense
              of taking real-time 
              control away from the user in those cases. Other
              approaches, such as 
              BONDI, do not
              hard-code this type of trust model, but nonetheless
              provide for a policy 
              authority to determine an access control policy, and
              this policy can require 
              that certain decisions are made without reference to the
              user. 
            </p><p>
              Although the role of any access control policy, and
              authority over it, are 
              beyond the scope of this particular issue, DAP's
              approach to prompting must 
              take these possibilities into account.</p> 
          </li>
          <li>Granularity of user decisions
            <p class="issue">
              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?
            </p><p>
              This issue is whether the user is presented with a
              single security decision 
              that covers multiple operations, or independent prompts
              for individual 
              operations. Blanket authorization for an application to
              use multiple APIs, 
              as often as required, eliminates run-time prompts but
              also may leave the 
              user without the context required to make a meaningful
              security decision. 
              Also, a user may not be prepared to give blanket
              approval for a certain 
              operation but may instead wish to give permission in
              specific circumstances 
              only.
            </p><p>
              DAP should not presuppose that an approach involving
              blanket permissions 
              only (e.g. implicit granting of blanket permission by
              allowing installation to 
              occur, or an explicit blanket permission given when the
              application is first 
              run) is the right answer. Different permission granularities have
              advantages for different use 
              cases and we should require a system that supports
              all use cases 
              effectively.
              DAP should follow industry practice 
              in these cases, and provide permission granularities
              consistent with 
              those widely deployed in the mobile market.
            </p>
          </li>
        </ul>
      </div>
    </div> <!-- prompts -->
    <div id="user-control-rqmts" class="section">
      <h3><span class="secno">3.5 </span>User Control Requirements</h3>
      <ul>
        <li>The security framework <em class="rfc2119" title="must not">must not</em> require User Agents to
          present modal dialogs to prompt users for security 
          decisions, while the application is running.
          <ul><li>Note: modal dialogs may be required
              for security prompts provided during application
              installation or invocation.</li></ul>
        </li>
        <li>The security framework <em class="rfc2119" title="should">should</em> allow users to have control
          over general configuration of security 
          decisions</li>
        <li>The security policy framework <em class="rfc2119" title="should">should</em> make it possible to record
          security configuration choices and interactive policy
          decisions using the policy markup language format.</li>
      </ul>
      </div>
      <div id="portable-policy" class="section">
        <h3><span class="secno">3.6 </span>Portable Policy</h3>
        <p>
          It should be possible for policy to be defined in a portable
          device-independent manner.
        </p>
        <ul>
          <li>Security Framework <em class="rfc2119" title="must">must</em> be separable from policy
            statements. Note that this may be a consequence of declarative
            policy statements.</li>
          <li>Access control policy <em class="rfc2119" title="must">must</em> be stated in declarative manner.</li>
          <li>The DAP policy language <em class="rfc2119" title="must">must</em> define an XML syntax for
            that language.</li>
        </ul>
        <p>
        </p>
      </div> <!-- portable -->
    </div> <!-- user control -->

    <div id="enterprise-managed-access" class="section">
    <!--OddPage--><h2><span class="secno">4. </span>Enterprise Managed Access</h2>
    <p>This section outlines use cases and requirements to support
    enterprise or network operator managed access control.</p> 
    <div id="use-case-pm3--external-policy-authority" class="section">
      <h3><span class="secno">4.1 </span>Use case PM3: external policy authority</h3>
      <p>
        In this use case:
      </p>
      <ul>
        <li>
          an external body has authority over the device and, in particular, security
          policy configuration.
        </li>
        <li>
          an initial security policy configuration may be provided by the external
          authority, together with any other associated device configuration (such as
          root certificates). The configured policy may determine access control policy
          without reference to the user, or may refer certain decisions to the user.
        </li>
        <li>
          the policy may be updated periodically under the authority of the policy
          authority. Policy maintenance may also occur as the cumulative effect of
          certain user decisions being remembered.
        </li>
      </ul>
      <p>
        The external policy authority may configure the policy as part of the
        commissioning of the device (eg a network operator's configuration applied by
        the manufacturer prior to sale, or an enterprise configuring device policy
        using a secured device management interface).
      </p>
      <p>
        In determining the policy, the policy authority has the opportunity to define
        a policy that supports a specific objective - such as to limit access to APIs
        to only those web applications that are themselves distributed by the policy
        authority (eg to control its exposure to the financial risk of abuse of device
        APIs).
      </p>
</div> <!-- PM3 -->
<div id="use-case-pi1--device-independent-policy-definition" class="section">
      <h3><span class="secno">4.2 </span>Use case PI1: device-independent policy definition</h3>
      <p>
        In this case case, a single policy authority wishes to define and configure a
        security policy for multiple dissimilar devices. A typical network operator's
        portfolio many include tens or even hundreds of models, each based on
        different platforms, and different UAs. A commonly supported interoperable
        format for configuration of a policy dramatically impacts the practicality of
        achieving the desired configuration across all devices. This is relevant to
        Policy Management use case PM3.
      </p>
</div> <!-- PI1 -->
<div id="use-case-pi3--policy-provisioning-as-part-of-service-deployment" class="section">
      <h3><span class="secno">4.3 </span>Use case PI3: policy provisioning as part of service deployment</h3>
      <p>
        Configuration of some parts of access control policy may be part of the
        overall configuration required to enable a particular application or service.
        This, along with many other configuration parameters, may be remotely
        configurable via device management. The configuration required to enable a
        service may be provided by the service provider as a policy fragment, to be
        added to the overall policy by the policy authority. An interoperable
        representation of such policy fragments would enable this to be done without
        authoring the configuration updates separately for each target device,
        platform, or UA.
      </p>
</div> <!-- PI3 -->
<div id="policy-interoperability" class="section">
      <h3><span class="secno">4.4 </span>Policy interoperability</h3>
      <p>
        These use cases relate to reading and writing of policy definitions in an
        interoperable format.
      </p>
</div>
<div id="enterprise-requirements" class="section">
  <h3><span class="secno">4.5 </span>Enterprise Requirements</h3>
  <p>

</p>
</div>
</div>
<div id="abuse-cases" class="section">
      <!--OddPage--><h2><span class="secno">5. </span>Abuse Cases</h2>
	  <p>
	  This section outlines some abuse cases for misuse of APIs.
	  </p>
	  <p>
	  The landscape that is being created is the enablement of
	  cross-platform, cross-device, easy to develop, highly functional
	  applications based on browser technology that has been proven
	  repeatedly to be untrustworthy - a perfect recipe for evil. Will
	  this meet all the criteria for really successful malware on
	  mobile devices for example? 
	  </p>
	  <p>
	  Up until now the measures taken by the mobile industry have
	  proven highly successful in ensuring no major malware incident
	  has affected the industry. There have been attempts: the
	  MMS-spreading Commwarrior is probably the most infamous, along
	  with the Spyware tool, Flexispy. An additional factor in
	  ensuring the success of mobile security has been the fact that
	  mobile platforms have been too fragmented and complex, therefore
	  not representing an attractive target so far. Existing modus
	  operandi from technology-related attacks can provide indicators
	  as to the types of attack and abuse that can be expected on
	  widgets and web applications as device APIs are opened up.  
	  </p>
    <div id="premium-rate-abuse" class="section">
      <h3><span class="secno">5.1 </span>Abuse Case AC1: Premium Rate Abuse</h3>
			<p>A widget that seems benign but is actually spewing out
			SMSs to premium rate numbers without the user’s
			knowledge. This could be modified from an original safe
			widget such as a game. For the malware author, the key
			piece to solve is to dupe the user into thinking that the
			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
			days of dial-up networking). There have been recent
			warnings about this kind of abuse from security firms. 
			</p>
</div> <!-- premium rate Abuse -->
      <div id="privacy-breach" class="section">
<h3><span class="secno">5.2 </span>Abuse Case AC2: Privacy Breach</h3>
			<p>An application that gains access to locations, contacts
			and gallery, silently uploading the data in the background
			to a site owned by the attacker. This is something that
			has been a clear goal for attackers already. There have
			been numerous high-profile examples in the past in the
			mobile world. Celebrities such as Paris Hilton, Miley
			Cyrus and Lindsay Lohan have all had private pictures,
			phone numbers and voicemails stolen from devices or
			networks in clear breach of their privacy. There has been
			embarrassment for teachers who had their pictures and
			videos copied by the children in their class and spread
			around school. The most high-profile case in the UK of a
			mobile related privacy breach was that of the News of the
			World's use of voicemail hacking to gain access to private
			information about Royalty. The Royal editor, Clive Goodman
			was jailed for four months and the editor, Andy Coulson
			resigned over this blatant privacy breach. Given the
			appetite for breaching privacy, users need to be safe in
			the knowledge that their personal data will not leak in
			any way. 
			</p>
      </div> <!-- privacy-breach -->
      <div id="integrity-breach" class="section">
        <h3><span class="secno">5.3 </span>Abuse Case AC3: Integrity Breach</h3>
			<p>A widget that replaces the voicemail number with a
              premium rate number instead? There are number of reasons
              why an attacker would want to breach the integrity of
              the device. Simply changing the telephone number of the
              voicemail that is stored on the device could be enough
              to make an attacker a lot of money. Users usually have a
              shortcut key to their voicemail and may not notice for a
              long time that anything is wrong. A more sinister use
              could be to plant evidence on a device. Pictures, files
              and even criminal contacts could potentially be
              anonymously planted all without the user's consent or
              knowledge. Proving innocence could suddenly become very
              difficult. 
There are also a number of reasons why somebody would want to steal
              data. The contents of corporate e-mails would be very
              interesting to a competitor, as would sabotaging data
              stored in spreadsheets and presentations on the target
              phone. 
			</p>
      </div> <!-- integrity-breach -->
      <div id="phishing" class="section">
        <h3><span class="secno">5.4 </span>Abuse Case AC4: Phishing</h3>
			<p>A widget that replaces the voicemail number with a
              premium rate number instead? There are number of reasons
              why an attacker would want to breach the integrity of
              the device. Simply changing the telephone number of the
              voicemail that is stored on the device could be enough
              to make an attacker a lot of money. Users usually have a
              shortcut key to their voicemail and may not notice for a
              long time that anything is wrong. A more sinister use
              could be to plant evidence on a device. Pictures, files
              and even criminal contacts could potentially be
              anonymously planted all without the user's consent or
              knowledge. Proving innocence could suddenly become very
              difficult. 
There are also a number of reasons why somebody would want to steal
              data. The contents of corporate e-mails would be very
              interesting to a competitor, as would sabotaging data
              stored in spreadsheets and presentations on the target
              phone. 
			</p>
      </div> <!-- phishing -->
</div> <!-- Abuse -->
<div id="capabilities" class="section"> 
      <!--OddPage--><h2><span class="secno">6. </span>Capabilities</h2>
        <p>
Declarative policy is used for access control decisions for various 
 capabilities, such as actions that may be performed, as invoked by
 specific API calls for example. 
</p>
        <p>
          Examples of device capabilities independent of API include the "read
          local filesystem" device capability or the "geolocation" device
          capability. A corresponding access control decision based on
          capability alone is a policy stating that  an application shall have
          no access to geolocation, regardless of API used.
          Examples of feature access control include a messaging API that permits
          files to be attached to messages using
          the "read local filesystem" device capability, or a camera API that
          permits captured photos to be geotagged,  using the
          "geolocation" device capability.
        </p>
        <p>
          Capabilities need to be defined portably. Examples of
          granularity - a shared file needs to be distinguishable from an
          application's private file, and a Bluetooth port needs to be distinguishable
          from a USB serial port.
        </p>
      <div id="policy-capability-requirements" class="section">
        <h3><span class="secno">6.1 </span>Capability Requirements</h3>
<ul>
          <li>Capabilities <em class="rfc2119" title="must">must</em> be defined for all sensitive device resources
            and functionality.
          </li>
          <li>Capabilities <em class="rfc2119" title="must">must</em> be identified by strings associated
            with API definitions produced by the DAP WG.
          </li>
</ul>
</div>
        <div id="issue---features--relationship-to-capabilities--crud" class="section">
        <h3><span class="secno">6.2 </span>Issue - Features, relationship to capabilities, CRUD</h3>
        <p class="issue">
          Features defined according to CRUD, one feature for Create,
          Read, Update, Delete?
        </p>
        <p class="issue">
          Feature parameters to avoid explosion of capabilities and
          features? e.g. file open with either read or write
          parameter.
          ( see
          <a href="http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/minutes-2009-10-07.html#item03">discussions in minutes of October 7 call</a> )
        </p>
      </div> <!-- Policy Definition Requirements issues -->

</div>

      <div id="framework" class="section">
<!--OddPage--><h2><span class="secno">7. </span>Security Framework</h2>
      <div id="framework-rqmts" class="section">
      <h3><span class="secno">7.1 </span>Security Framework Requirements</h3>
      <div id="policy-integrity-requirements" class="section">
        <h4><span class="secno">7.1.1 </span>Policy Integrity Requirements</h4>
<p>It should be possible for policy to be integrity protected during
various points in its life-cycle.</p>
<ul>
  <li>It <em class="rfc2119" title="must">must</em> be possible to provide integrity protection and
    source authentication for policy.</li>
</ul>
</div>
        <ul>
          <li>The DAP security framework <em class="rfc2119" title="must not">must not</em> preclude different
            authorities defining the security policy.
          </li>
          <li>The Security Framework <em class="rfc2119" title="must">must</em> allow multiple instantiations of a web
            runtime with independent security decisions</li>
          <li>The Security Framework <em class="rfc2119" title="must">must</em> be application language
            independent</li>
          <li>The Security Framework <em class="rfc2119" title="must">must</em> be Javascript capable and
            define a Javascript binding</li>
          <li>It <em class="rfc2119" title="must">must</em> be possible to have separate policy decision and
            enforcement points</li>
          <li>The DAP security model <em class="rfc2119" title="should">should</em> be compatible with the
            same origin policy.</li>
        </ul>
      </div> <!-- security framework requirements -->
<div id="access-control-requirements" class="section">
  <h3><span class="secno">7.2 </span>Access Control Requirements</h3>
    <ul>
      <li>Access control decisions may be made at both the
        granularity of Features
        and Device Capabilities.
      </li>
      <li>The security framework <em class="rfc2119" title="must">must</em> support access control
        decisions based on device capabilities, independent of API.
      </li>
      <li>The security framework <em class="rfc2119" title="must">must</em> support access control
        decisions based on features (one or more capabilities
        bound to a device API).
      </li>
      <li>The security framework <em class="rfc2119" title="must">must</em> support sufficient granularity
        for sensible access control decisions.
      </li>
    </ul>
    <p class="issue">
     ( see <a href="http://www.w3.org/2009/dap/track/issues/21">ISSUE-21 - OPEN</a>  ) Is access control at the feature level required or is access control
      at the device capability level adequate?
    </p>
  </div> <!-- access control requirements -->
</div> <!-- requirements -->
<div id="examples-of-statements-or-rules-that-may-be-expressed-in-a-policy" class="section">
      <!--OddPage--><h2><span class="secno">8. </span>Examples of statements or rules that may be expressed in a policy</h2>
      <p>
        These use cases are specific examples of statements or rules that may be
        expressed in a policy.
      </p>
        <ul>
          <li>
            A widget whose signature chains to operator root can read and write
            from the PIM databases.
          </li><li>
            A widget downloaded from <code>weather.example.com</code> can access
            geolocation coordinates if the user says it’s OK.
          </li><li>
            The <code>weather.example.com</code> widget can connect to
            <code>weather.example.com</code> without
            notifying the user, except when roaming.
          </li><li>
            All widgets with a reliably identified author can save data
            persistently if the user says it’s OK.
          </li><li>
            No widget can get my location, no matter who trusts it.
          </li><li>
            No widget can access <code>evil.example.org</code>.
          </li><li>
            An unsigned widget cannot launch another application without user
            consent.
          </li>
        </ul>
      <p>Example web site use cases, to give examples of the types of
        policy that might be expressed:</p>
        <ul>
          <li>
            A reliably identified website can access geolocation
            coordinates if the 
            user confirms it’s OK.
          </li><li>
            Any website in a subdomain
            of <code>mynetwork.example.com</code> can read phone
            status 
            properties.
          </li><li>
            Reliably identified websites can send and receive SMS
            except to premium 
            rate numbers.
          </li><li>
            <code>evil.example.com</code> cannot access any device APIs.
          </li><li>
            The <code>weather.example.com</code> <var>foo</var> widget
            can access geolocation coordinates but 
            only if it’s embedded on the <var>foo</var> home page.
          </li>
        </ul>
</div>
<div id="out-of-scope" class="section">
  <!--OddPage--><h2><span class="secno">9. </span>Out of Scope</h2>
  <p>
  </p>
  <ul>
    <li>The management of security policies ... is out of scope
      (charter)</li>
    <li>Identity Revocation</li>
  </ul>
</div>

<div class="appendix section" id="acknowledgements">
  <!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
  <p>
    The editors would like to extend special thanks to Nokia, OMTP
    BONDI, and PhoneGap for providing
    the foundation of the working group's requirements discussion.
  </p>
</div>


<div id="respec-err" style="position: fixed; width: 350px; top: 10px; right: 10px; border: 3px double #f00; background: #fff" class="removeOnSave"><ul><li style="color: #c00">There appears to have been a problem fetching the style sheet; status=0</li></ul></div><div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">B. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">B.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">B.2 </span>Informative references</h3><p>No informative references.</p></div></div></body></html>

Received on Wednesday, 16 June 2010 19:27:37 UTC