2009/dap/policy Examples.html,NONE,1.1

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

Added Files:
	Examples.html 
Log Message:
Policy examples doc created

--- NEW FILE: Examples.html ---
<!DOCTYPE html> <html>
  <head>
    <title>Device API Policy Examples</title> <meta http-equiv='Content-Type'
    content='text/html;charset=utf-8'/> <script src='../ReSpec.js/js/respec.js'
    class='remove'></script> <script class='remove'>
      var respecConfig = { specStatus: "ED", shortName: "policy",
      // publishDate: "2009-10-23", previousPublishDate: "1977-03-15",
      edDraftURI: "http://dev.w3.org/2009/dap/policy/",
      // lcEnd: "2009-08-05",
      };
    </script> <script src='../common/configPolicy.js' class='remove'></script>
  </head> <body>
    <section id='abstract'>
      This document specifies a policy framework for device APIs.
    </section> <!-- abstract -->

    <section id='introduction'>
      <h2>Introduction</h2> <p>
	This document is an editors draft and currently does not reflect
	consensus of the WG but rather is a starting point for further work. It
	is based on input documents and list discussion.
      </p> <p>
	The policy framework described in this document is intended to be
	applicable both to widgets and web applications (web site access to
	Device APIs).
      </p>
    </section> <!-- introduction -->
<section id="example-abuse-policies">
  <h2>Example Policies to mitigate Abuse Use Cases</h2>
    <p> This section outlines some example policies that could be used to
    deal with abuses of device APIs. </p>
    <section id="premium-rate-defence">
      <h3>Defending against premium rate abuse</h3>
	<p>The example assumes that a number of mechanisms have
	already been defeated in the security chain – the
	application is trusted and is on the device. If the user
	(or the policy provider) has stated that they don’t want
	to call premium rate numbers in the UK: </p>
	<pre><code>
	<code>&lt;target&gt;</code>
	    <code>&lt;subject&gt;</code>
		&lt;subject-match attr="author-key-root-fingerprint" match="sha256 ******** root fingerprint of author ****" /&gt; &lt;-- to identify the Identified domain, the same would
	    apply for the Unidentified domain--&gt;
	&lt;/target&gt;
         &lt;rule effect="one-shot"&gt;
	    <code>&lt;condition&gt;</code>
		&lt;resource-match attr="dev-cap" match="messaging.*.send"
		param:recipients="+4409*" func="glob"/&gt; &lt;-- to block UK premium
		rate numbers --&gt;
	    &lt;/condition&gt;
	&lt;/rule&gt; </pre></code>
	We could extend this to other countries if we are concerned that premium rate
	numbers would not only be from the host country. Here is an example of a policy
	fragment for blocking Spanish premium rate numbers that could be added, along
	with the condition combining operator (please note: there are probably more
	elegant ways of expressing this by using regular expressions): <pre><code>
	    &lt;condition combine="or"&gt;
		&lt;resource-match attr="dev-cap" match="messaging.*.send"
		param:recipients="+4409*" func="glob"/&gt; &lt;-- to block UK premium
		rate numbers --&gt; &lt;resource-match attr="dev-cap"
		match="messaging.*.send" param:recipients="+34806*" func="glob"/&gt;
		&lt;-- to block Spanish premium rate numbers --&gt;
	    &lt;/condition&gt;
	</pre></code> If the malicious widget is out in the wild already and has been
	identified, then we want to prevent it from installing and executing on devices,
	halting the spread of the malware in its early stages of distribution. </p> <p>
	Clearly, if the widget is prevented from installing, then it cannot call a
	device API – these functions are shown as a belt and braces example:
	<pre><code> <code>&lt;target&gt;</code>
	    <code>&lt;subject&gt;</code>
		&lt;subject-match attr="id" match="http://maliciouswidget1.example.org"&gt;
	    &lt;/subject&gt;
	&lt;/target&gt; &lt;rule effect="deny"&gt;
	   &lt;condition combine="or"&gt;
	    &lt;resource-match attr="widget-install" /&gt; &lt;resource-match
	    attr="widget-instantiate" /&gt; &lt;resource-match attr="api-feature" match="*"
	    /&gt; &lt;resource-match attr="dev-cap" match="*" /&gt; &lt;/condition&gt;
	  &lt;/rule&gt;
	</code></pre>
    </section> <!-- premium-rate-abuse -->
</section> <!-- example policies -->

<section id="out-of-scope"> <h2>Out of Scope</h2>
  <p> </p> <ul>
    <li>The management of security policies ... is out of scope
      (charter)</li>
    <li>Identity Revocation</li>
  </ul>
</section>

<section class='appendix'>
  <h2>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>
</section>
</body>
</html>

Received on Wednesday, 2 June 2010 13:24:12 UTC