1. Fine Granularity Policy Based Device Access Security Claes Nilsson - Sony Ericsson 2009-12-18

2. Content of presentation A proposal for “Fine Granularity Policy Based Device Access Security”. This is response to ACTION-38: “Should issue recommendation on the granularity of the security system”

3. Use cases In a file API access to certain data is restricted to certain applications In a file or contacts API differentiation based on application identity between "read-only" and “read and write” access A "Secure credential manager“ for retrieving API-keys used for application log in to social networking web services

4. Proposal for “Fine Granularity Policy Based Device Access Security” Based on “Policy Based Device Access Security” (Steve Lewontin/Nokia http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/att-0012/SecurityPolicy_09.pdf)http://lists.w3.org/Archives/Public/public-device- apis/2009Nov/att-0012/SecurityPolicy_09.pdf Added finer granularity to restrict access to APIs based on application identity Assumptions: – The origin and integrity of the web application can be securely verified. Examples: Signed web widget Web application accessed through SSL/TLS – The identity of the web application can be securely verified. Examples: The application identity is included in a widget's (signed) configuration file (assumes some kind of centralized widget signing) The application identity is included in a widget's certificate (makes distributed signing possible)

5. Web Execution Environment Web Application, e.g. Widget package html CSS JS Dig Signature cert Conf doc Content Engine 2. GetTrustAttributes Returns OriginURl, Certificate, Digital Signature, Conf Doc,etc 6. Result = AccessDeviceFunc (AppId, Params….) Assumptions: The origin and integrity of the web application can be securely verified. The identity of the web application can be securely verified. Trust Manager 3. GetTrustDomain(TrustAttributes, TrustPolicy) Trust Policy “Device API” 4. CallAPI (Params…, TrustDomain, AppId) Access Manager 5. Access allowed? (TrustDomain, Access Policy) Returns TrustDomain + AppId 1. navigator.device.API.method(Params…) Returns Allowed/ NotAllowed Returns “Result “, which will be a callback to navigator.device.API.method( “Device functionality to be accessed with the granularity of AppId” Access Policy

6. Logical flow for “Fine Granularity Policy Based Device Access Security” 1.The web application, e.g. a signed web widget, accesses device functionality that is restricted to this specific application. 2.The content engine loads the content and gets any needed content trust attributes, e.g. the origin URL, the digital signature, the certificate, the configuration document etc. 3.The content engine queries the trust manager to get the trust domain of the content and the application identity, passing the relevant trust attributes, and the path to the appropriate trust policy to the trust manager. The actual name/id of the application could for example be included in a widget's (signed) configuration document (assumes some kind of centralized widget signing) or it could be included in the certificate (makes distributed signing possible). The application’s name/id must be relative to the origin of the application, typically the PKI-identity, e.g. the Certificate Authority (CA) of a signed widgets certificate. This means that the CA must coordinate the application names/ids. So, an application identity (AppId) consists of two parts: - Origin of the application, typically the PKI-identity - Actual name/id of application 4.The content engine makes an API request, passing relevant parameters and the trust domain and application id to the device API implementation. 5.The device API implementation creates a security session with the access manager, passing the path to the appropriate access policy and the content trust domain. The device API implementation asks the security manager for an access decision (via the security session) passing the required capabilities. 6.Based on the result of the access control decision, the service invokes the requested operation, passing the application id, or throws a security exception. The “Device Functionality” will only open up the part that is available for this application according to the application id.