This document specifies a policy framework for device APIs.

Introduction

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.

The policy framework described in this document is intended to be applicable both to widgets and web applications (web site access to Device APIs).

Example Policies to mitigate Abuse Use Cases

This section outlines some example policies that could be used to deal with abuses of device APIs.

Defending against premium rate abuse

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: 


	<target>
	    <subject>
		<subject-match attr="author-key-root-fingerprint" match="sha256 ******** root fingerprint of author ****" /> <-- to identify the Identified domain, the same would
	    apply for the Unidentified domain-->
	</target>
         <rule effect="one-shot">
	    <condition>
		<resource-match attr="dev-cap" match="messaging.*.send"
		param:recipients="+4409*" func="glob"/> <-- to block UK premium
		rate numbers -->
	    </condition>
	</rule>
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): 

	    <condition combine="or">
		<resource-match attr="dev-cap" match="messaging.*.send"
		param:recipients="+4409*" func="glob"/> <-- to block UK premium
		rate numbers --> <resource-match attr="dev-cap"
		match="messaging.*.send" param:recipients="+34806*" func="glob"/>
		<-- to block Spanish premium rate numbers -->
	    </condition>
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.

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: 

 <target>
	    <subject>
		<subject-match attr="id" match="http://maliciouswidget1.example.org">
	    </subject>
	</target> <rule effect="deny">
	   <condition combine="or">
	    <resource-match attr="widget-install" /> <resource-match
	    attr="widget-instantiate" /> <resource-match attr="api-feature" match="*"
	    /> <resource-match attr="dev-cap" match="*" /> </condition>
	  </rule>

Out of Scope

Acknowledgements

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.