W3C home > Mailing lists > Public > public-dap-commits@w3.org > June 2010

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

From: Laura Arribas via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 02 Jun 2010 13:52:59 +0000
To: public-dap-commits@w3.org
Message-Id: <E1OJoNP-0007FW-JD@lionel-hutz.w3.org>
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv27840

Added Files:
	Framework.html 
Log Message:
policy framework doc updated

--- NEW FILE: Framework.html ---
<!DOCTYPE html> <html>
  <head>
    <title>Device API Policy Framework</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="security-framework">
  <h2>Security Framework</h2>
    <section id="framework-overview">
    <h3>Framework Overview</h3>
   <p>
      This security model is based on a clear
      separation between the definition of the general framework and the creation
      of specific trust and access policies. This allows the configured policies of
      a web runtime to be adapted to the needs of different stakeholders at any
      time during the lifecycle of a product. This includes, but is not limited
      to, the embedding and configuration of web runtimes at manufacture as well
      as post-sales installation of web runtimes.
    </p> <p>
      As a general high-level objective, it should be noted that the security
      framework is intended to protect the device and its user from web applications
      that pose a security risk from unintentional but undetected implementation flaws
      as well as those that are malicious.
    </p> <p>
      The intention is that the framework, at the most general level, allows a very
      wide range of policies to be represented (although manageability and
      interoperability concerns require there to be a certain level of similarity and
      compatibility in policy structure). However, the framework must permit
      fine-grained security policies to be represented as well as policies based on
      broad groupings of APIs and assignment of web applications to a small number of
      trust domains. For example, a fine-grained access policy is necessary to grant
      or deny access to individual APIs for individual web applications.
    </p> <p>
      This framework is based on a very general model that governs both trust domain access by subjects
      to resources based on a hierarchy of <a href=#trust-policy>trust policies</a>, <a href=#access-policy>access policies</a> and <a href=#policy-set>policy sets</a>, where each policy
      consists of a number of <a href=#rule>rules</a>. Subjects and resources are characterised by a
      number of defined <a href=#subject-attributes>subject attributes</a> and <a href=#resource-attributes>resource attributes</a>. A range of
      attributes is defined so that access policies can be expressed based
      on a widget resource signer’s identity, or an individual widget resource
      identity, or the widget resource signature’s root certificate, or a website’s
      URL. Therefore, the generality of this framework derives from the range of
      attributes that are supported, as well as the flexible structure of policies and
      policy sets in the security model.
    </p> <p>
      This general model is defined using concepts,
      terminology and semantics from the eXtensible Access Control Markup Language
      [[!XACML20]] framework. Trust and access policies are capable of
      representation in a compact XML format (and other formats, including a compact
      binary representation if necessary).
    </p> <p>
      It is intended that trust and access policies are also eventually capable of representation
      in XACML, using a specific dictionary of attributes and a subset of XACML
      elements; however this is not currently possible without defining a number of
      extensions to XACML. It is hoped that this becomes possible with future
      revisions of the XACML standard.
    </p>
    </section> <!-- framework overview-->
    <section id="layer-model">
    <h3>Layer Model</h3>
     <p>
      A web application uses a mechanism specified in this document to gain access to (or bind to)
      a JavaScript API by stating one or more features exposed by the JavaScript API. This access is given on a basis of the trust domain that has been assigned to the web application.
      The implementation of the API, in turn, makes use of one or more device
      capabilities, defined in terms of facilities that might be provided by APIs at
      the device, platform or OS level, but without reference to any particular API.
      Where a JavaScript API is defined within the DAP model, each function definition
      specifies which feature it implements, and which device capabilities it uses.
    </p> <p>
      The mechanisms provided in this specification to bind to APIs, and to control access (both to
      the features and the device capabilities exposed by them) are generic, and are
      not themselves dependent on any particular set of JavaScript APIs. This
      model envisages that these controls apply, irrespective of whether the APIs in
      use are defined by DAP or any independent entity. <!-- This “layering” of
      JavaScript APIs and mediating access control is illustrated in the figure below. -->
    </p>
    <section id="trust-domain-control-layer">
    <h4>Trust Domain Control Layer</h4>
      <p>
	The trust domain control layer controls the assignment of the appropiate
	trust domain to the web application via the relevant trust policy. In
	general, trust policies will select one trust domain or another
	depending on the <a href=#subject-attributes>subject attributes</a> and<a href=#environment-attributes>environment attributes</a> that
	identify the web application.
      </p>
    </section> <!-- trust domain control layer -->
    <section id="api-access-control-layer">
    <h4>Javascript API Access Control Layer</h4>
      <p>
	The JavaScript API access control layer controls access
	to all JavaScript APIs exposed by the web runtime. Each feature is
	identified uniquely by URI, and this security layer mediates access to
	features on the basis of that ID, <a href=#api-feature><code>api-feature</code></a>.
      </p>
    </section> <!-- API access control layer -->
    <section id="device-capability-access-control-layer">
    <h4>Device Capability Access Control Layer</h4>
      <p>
	The device capability access Control layer controls
	access to the underlying capabilities of the device when used from JavaScript
	APIs. These device capabilities themselves are identified so that it is possible
	to write security policies that control access to specific capabilities
	independently of the JavaScript APIs used to access them.
      </p>
    </section> <!-- device capability access control layer -->
    <section id=feature-capability-reqs>
    <h4>Considerations</h4>
      <p>
	This explicit separation of features and their dependent device capabilities addresses a
	number of significant requirements, as follows.
      </p>
      <ul>
	<li><p><strong>Extensibility is an intrinsic part of the security model.</strong> It is expected that APIs will be defined and implemented
	independently, and the nature of those APIs will not necessarily be known to the
	author of a security policy. Therefore, if a security policy author wishes to
	deny access to a specific device capability, then there must be a way of doing
	this that is independent of the JavaScript API being used.</p></li>
	<li><p><strong>The web runtime must only grant access to features that are
	advertised as being dependencies of the web application.</strong> The access control system must ensure
	that only requested features are accessible to the web
	application. This requires that the access control system is able to
	control access based on the ID of a Feature, <a href=#api-feature><code>api-feature</code></a>.</p></li>
	<li><p><strong>There will not be a direct 1-1 correspondence between JavaScript APIs
	and device capabilities.</strong> Although there will be simple JavaScript APIs that
	provide access only to a single device capability, it must be expected that
	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 will not directly
	correspond to enabling or disabling access to a single JavaScript API.</p></li>
	<li><p><strong>Implementations of JavaScript APIs need not be as highly
	trusted as the web runtime.</strong> Authors of access policies may require the ability to
	control access to specific JavaScript APIs, or families of APIs, based on the
	identity of the API (and not just the device capabilities it exposes), according
	to the trustworthiness of the author of the API.</p></li>
	<li><p><strong>It must be possible to represent both trust and access policies
	portably.</strong> This implies that all identifiers used in a security
	policy (both for features and for device capabilities) must be portably defined,
	and not (for example) based on any platform-specific API names. This requires
	that the identifiers for device capabilities are defined in a
	platform-independent way. <!-- BONDI defines a set of these capabilities in
	Appendix A.--></p></li>
      </ul>	
    </section> <!-- feature-caps requirements -->
    </section> <!-- layer model -->
    <section id="logical-model">
    <h3>Logical Model</h3>
     <p>
      On the one hand, the trust domain control system explained in this
      document, from a logical perspective, represents the system by which a web
      application that attempts to access device capabilities using JavaScript
      APIs, is assigned a trust or security domain. This trust domain will then
      be used in subsequent access requests, simplifying the whole process. On
      the other hand, the access control system, implementing a specific access
      control policy, has the sole effect of making and enforcing an access
      control decision in relation to each attempted access. (In order to make
      that decision the access control system may request interactive
      confirmation from the user, but this is invisible to the requesting web
      application.)
    </p> <p>
      Both the trust and access control systems consist of a number of logically distinct
      elements. <!-- Specific DAP requirements and interfaces are specified in terms of
      these separate functional components. --> This logical breakdown and associated
      terminology is adopted from  XACML [[!XACML20]] and illustrated below.
    </p>
    <!-- ILLUSTRATION XACML DATAFLOW -->
    <!-- <object type="image/svg+xml" data="dataflow.svg"> -->
 <img src="dataflow.png" alt="graphical representation of the data flow" title="Security model, derived from XACML Specification Schema" width="700" height="700"/> <!-- </object> -->
    <p>
      The specified functional components are as follows:
      <ul>
      <li><p><strong>Policy Decision Point (PDP):</strong> the module that
      evaluates whether or not a device API can be accessed by a web
      application, based on the current policy.</p></li>
      <li><p><strong>Policy Enforcement Point (PEP):</strong> the module that
      allows or prevents access to device APIs.</p></li>
      <li><p><strong>Policy Information Point (PIP):</strong> the module that gathers information to
      be used by the PDP to evaluate an access control request. In particular it
      collects the subject attributes (i.e. how the web application was identified and
      its associated security attributes), the resource attributes (i.e. which device
      API is being requested and using which parameters) and the environment (i.e.
      status of the device).</p></li>
      <li><p><strong>Policy Administration Point (PAP):</strong> the authority that
      defines the policy. It could be a network operator, a terminal manufacturer, a
      web runtime developer, an enterprise or a user at run-time. Policies can be
      provided by the PAP in different ways, for instance using a preloaded file or
      data structure, or a remote management mechanism (e.g. OMA DM).</p></li>
      </ul>
      <div class="issue">
	<p>OMA DM reference missing?</p>
	<p>Should we include this?: In the present phase, DAP does not define any specific external interface requirements for
      the PAP, although this may be in scope for later phases. The security policy
      itself is not defined by DAP, although a default policy may be recommended by
      DAP at a future stage.</p></div> 
    </p>
    <p>
      The functionality required in each of these components is specified in terms of the following entities:
      <ul>
      <li><p><strong><a href=#subject>Subject</a>:</strong> the web application
      that requires access to JavaScript APIs. Examples of subjects are websites
      and widgets.</p></li>
      <li><p><strong><a href=#subject-attributes>Subject
      attribute</a>:</strong> each subject is associated with a set of
      attributes. Subject attributes allow the identification of the web
      application that is attempting access to device capabilities using device
      APIs. The identified web application is then assigned a trust domain
      according to the appropiate trust policy. Subject attributes include
      specific attributes that represent the identity of the web application
      attempting access to a resource. Valid identity attributes include the
      widget identifier URI for widgets and the URL for websites; other
      identifiers may be supported. Subject attributes also include the
      credentials used to verify the authenticity and integrity of the subject,
      e.g. a TLS or code signing digital certificate. Other
      credentials may be supported.</p></li>
      <li><p><strong><a href=#environment-attributes>Environment
      attribute</a>:</strong> the collection of device status and context
      attributes that may be relevant to the circumstances of a resource access
      attempt, but are not directly associated with either the subject or
      resource. For example, environment attributes can include terminal
      charging, network connection status, whether roaming.</p></li>
      <div class="issue">
	<p>environment attributes</p>
	<p>in this new model, aren't env attrs directly related to subject and trust policies?</p></div> 
      <li><p><strong><a
      href=#resource>Resource</a>:</strong> the resources that subjects may
      request access to. The device features or services (e.g. the location
      module or PIM database) are the actual resources that are being protected,
      but from the point of view of the security framework these resources are
      associated with the API Features and device capabilities used to access
      them.</p></li>
      <li><p><strong><a href=#resource-attributes>Resource
      attribute</a>:</strong> each resource is associated with a set of
      attributes. Resource attributes include an identifier. Other attributes
      may be associated with a resource, and these can include specific
      parameters that are specified as part of the request when attempting
      access.</p></li>
      </ul>
    </p>
    </section> <!-- logical model -->
    <section id="trust-domain-policy-structure">
    <h3>Policy Structure</h3>
    <p>
      Both trust domain and access control policies share the same underlying structure. The policy in effect in any given context is logically expressed as a collection of specific access control <strong><em><a href=#rule>rules</a></em></strong>. The rules are organised into groups, termed <strong><em><a href=#policy>policies</a></em></strong>, and these in turn are organised into groups termed <strong><em><a href=#policy-set>policy sets</a></em></strong>. This structuring serves a number of purposes:
    </p>
    <ul>
      <!-- <li><p>the rules that apply to a specific web application, or group of web applications, can be grouped together, which simplifies writing and maintaining the policy;</p></li> -->
      <li><p>it helps organise the rules into groups that can be independently created and maintained, sometimes under different authority (and subject to differing degrees of control);</p></li>
      <li><p>it provides a way of ensuring that the correct precedence is applied when processing rules. This makes some rules easier to write because their applicability is more narrowly scoped by their enclosing policy. More significantly, it ensures that security requirements determined by one authority are not wrongly overridden by rules provided by a subordinate authority.</p></li>
    </ul>
    <p>
      Simplistically, each rule is specified by defining a <strong><em><a href=#condition>condition</a></em></strong>, which is a set of statements which must be satisfied in order for that particular rule to apply, and an <strong><em><a href=#effect>effect</a></em></strong> which represents the rule's outcome – ie whether that rule indicates that the access request should be permitted or not. 
    </p>
    <!-- ILLUSTRATION POLICY LANGUAGE MODEL -->
    <object type="image/svg+xml" data="languagemodel.svg">
 <img src="languagemodel.png" alt="graphical representation of the XACML policy language model" title="DAP policy language model, derived from XACML  Specification Schema" width="250" /> </object>
    </section> <!--policy structure -->
  <section id=rule-processing>
    <h3>Rule Processing</h3>
    <p>
     The following steps illustrate the logical processing required when a <a href=#policy-set>policy set</a> is used to determine the outcome of a particular access attempt:
    </p>
    <ul>
      <li><p>the identity of the calling web application, <a href=#subject>subject</a>, is known and is used to determine the <a href=#subject-attributes>subject attributes</a> for that web application;</p></li>
      <li><p>the application in question attempts an action (attempts to invoke a JavaScript API, say). This identifies the <a href=#resource>resource</a> and all associated <a href=#resource-attributes>resource attributes</a> including <a href=#api-feature><code>api-feature</code></a> and, where applicable, <a href=#device-cap><code>device-cap</code></a> resource attribute if the action entails use of a device capability. Any parameters used by any such device capability use, where designated as being security-relevant, are also captured within a <a href=#parameter><code>param:name</code></a> resource attribute;</p></li>
      <li><p>the <a href=#environment-attributes>environment attributes</a> are also captured;</p></li>
      <li><p>the set of subject, resource and environment attribute values captured is embodied in a <a href=#query>query</a> which is evaluated in the context of the top-level policy set associated with the configured security policy;</p></li>
      <li><p>based on the subject, resource and environment attribute values presented in the query, the conditions associated with each rule and <a href=#target>target</a> can be evaluated, and the applicable rules, policies and policy sets can be determined;</p></li>
      <li><p>the effect of each applicable rule is determined;</p></li>
      <li><p>based on the evaluated effect of each applicable rule, the relevant combining rules are used to determine the policies, policy sets and rules with precedence, which in turn determines the overall effect of evaluating the query;</p></li>
      <li><p>if the effect requires the user to be prompted, this is done, and the results of the user’s decision are recorded where appropriate.</p></li>
    </ul>
    <p>
>From a logical perspective, an access control query can be evaluated at any time between the point that the necessary attribute values become available and when the attempted operation is performed. In the case of a JavaScript API call for which arguments supplied to the call are designated resource attributes, the relevant attributes are only known once the API call has been made by the calling web application. However, in other cases the information may be known earlier. For example, if all feature requirements are stated in a widget configuration document, and none of the API access operations have conditions depending on API call parameters, then all access control queries may be evaluated fully at widget resource installation time.
    </p>
    </section> <!-- rule processing -->
</section> <!-- security framework-->

<section id="security-model-definition">
  <h2>Security Model Definition</h2>
  <p> This section defines the formal model underlying the general security
  framework. This includes definitions of each of the entities involved in the
  definition of an access control policy, and a definition of the attributes of
  each entity that are recognised and are required to be supported. This
  specification uses [[!XACML20]]. </p>
      <section id="application-execution-phases">
	<h3>Application Execution Phases</h3>
	  <p>The <em>execution</em> phase of a web application
	  reflects the state of that application at the time an
	  associated access control query is made. The defined
	  execution phases are listed below. </p> <table
	  border="1" summary=""> <caption> <dfn
	  id="execution-phases-table">Execution Phases
	  Table</dfn></caption> <thead> <tr> <th
	  scope="col">Execution Phase</th> <th
	  scope="col">Description</th> </tr> </thead> <tbody> <tr>
	  <td>widget-install</td> <td>Applies to access control
	  queries made by a widget user agent during the
	  processing of a widget resource as part of an
	  installation or update operation.</td> </tr> <tr>
	  <td>widget-instantiate</td> <td>Applies to access
	  control queries made by a widget user agent during the
	  instantiation of a widget.</td> </tr> <tr>
	  <td>website-bind</td> <td>Applies to access control
	  queries made in response to a call to requestFeature()
	  in the course of execution of a website</td> </tr> <tr>
	  <td>invoke</td> <td>Applies to access control queries
	  made in response to invocation of a JavaScript API in
	  the course of execution of a web application</td> </tr>
	  </tbody> </table>
</section>
      <section id="subject-attributes">
	<h3>Subject Attributes</h3>
	  <p> A <strong><em><a id="subject">subject</a></em></strong> corresponds to an entity that may attempt
	  security-relevant actions and corresponds to a single
	  “identity”. (In practice, some web applications might
	  have multiple identities – for example is a widget
	  resource is signed by multiple signers – but for the
	  purposes of this model, each access control query is
	  considered to involve a single subject and hence a
	  single identity.) </p>
	  <p> The identity of a subject is in one of the following classes. The
	  class determines which attributes are available; other
	  attributes have the undefined value. </p>
	  <p> All <strong><em>subject attributes</em></strong> are determined for all applicable
	  application Execution Phases. </p>
      <section id="widget-resource-identity">
	<h4>Widget Resource Identity</h4>
	  <p> The widget identity type applies to all operations
	  associated with a widget resource, or occurring in the
	  execution of a document belonging to a widget resource.
	  </p> <p> Operations occurring in the execution of a
	  remotely hosted document that has been loaded by a
	  widget (for example in an iframe) use a <a
	  href=#website-identity>website identity</a>. </p> <table
	  border="1" summary=""> <caption> <dfn
	  id="widget-subject-attributes-table">Widget Subject
	  Attributes Table</dfn></caption> <thead> <tr> <th
	  scope="col">Attribute</th> <th scope="col">Type</th> <th
	  scope="col">Value</th> </tr> </thead> <tbody> <tr>
	  <td>class</td> <td>string</td> <td>This has the value
	  “widget” if and only if the subject is a widget.</td>
	  </tr> <tr> <td>install-uri</td> <td>URI</td> <td>The URI
	  that the widget resource was originally retrieved from
	  before installation, if known, otherwise the empty
	  bag.</td> </tr> <tr> <td>id</td> <td>URI</td> <td>The
	  identity of the widget. For a W3C widget specification
	  compliant widget resource, this is the value of the id
	  attribute of the <widget> element in the widget
	  configuration document converted from IRI to URI based
	  on RFC3987. In this case, it is a URI that uniquely
	  identifies the widget. Empty bag if there is no id
	  attribute.</td> </tr> <tr> <td>version</td>
	  <td>string</td> <td>Version of the widget resource. For
	  a W3C widget specification compliant widget resource,
	  this is the version attribute of the <widget> element in
	  the widget Configuration Document. Empty bag if there is
	  no version attribute.</td> </tr> <tr>
	  <td>distributor-key-cn</td> <td>string</td> <td>The
	  common name of the end entity certificate for the
	  applicable widget resource distributor signature. Empty
	  bag if none.</td> </tr> <tr>
	  <td>distributor-key-fingerprint</td> <td>string</td>
	  <td>The fingerprint of the end-entity certificate for
	  the applicable widget resource distributor signature.
	  Empty bag if none.</td> </tr> <tr>
	  <td>distributor-key-root-cn</td> <td>string</td> <td>The
	  common name of the root certificate for the applicable
	  widget resource distributor signature. Empty bag if
	  none.</td> </tr> <tr>
	  <td>distributor-key-root-fingerprint</td>
	  <td>string</td> <td>The fingerprint of the root
	  certificate for the applicable widget resource
	  distributor signature.Empty bag if none.</td> </tr> <tr>
	  <td>author-key-cn</td> <td>string</td> <td>The common
	  name of the end entity certificate for the widget
	  resource author signature. Empty bag if none.</td> </tr>
	  <tr> <td>author-key-fingerprint</td> <td>string</td>
	  <td>The fingerprint of the end entity certificate for
	  the widget resource author signature in SDP syntax.
	  Empty bag if none.</td> </tr> <tr>
	  <td>author-key-root-cn</td> <td>string</td> <td>The
	  common name of the root certificate for the widget
	  resource author signature. Empty bag if none.</td> </tr>
	  <tr> <td>author-key-root-fingerprint</td>
	  <td>string</td> <td>The fingerprint of the root
	  certificate for the widget resource author signature.
	  Empty bag if none.</td> </tr> <tr>
	  <td>widget-attr:name</td> <td></td> <td>The value of the
	  named attribute of the &lt;widget&gt; element whose type
	  and value are set up in the widget configuration
	  document for use in the DAP security framework. Empty
	  bag if no such named attribute is defined.</td> </tr>
	  </tbody> </table>
      </section> <!-- widget-resource-identity -->
      <section id="website-identity">
	<h4>Website Identity</h4>
	  <p> The website identity type applies to all operations
	  occurring in the execution of a remotely-hosted
	  document, whether this is the top-level docment of the
	  website or is associated with some child browsing
	  context (such as an iframe). </p> <table border="1"
	  summary=""> <caption> <dfn
	  id="widget-subject-attributes-table">Widget Subject
	  Attributes Table</dfn></caption> <thead> <tr> <th
	  scope="col">Attribute</th> <th scope="col">Type</th> <th
	  scope="col">Value</th> <th scope="col">Meaning</th>
	  </tr> </thead> <tbody> <tr> <td>class</td>
	  <td>string</td> <td>"website"</td> <td>Has the value
	  “website” if and only if the subject is of this
	  class.</td> </tr> <tr> <td rowspan="4">sign-schema</td>
	  <td rowspan="4">string</td> </tr> <tr> <td>** (empty
	  string)</td> <td>Not signed</td> </tr> <tr>
	  <td>“tls”</td> <td>The page was fetched using HTTPS and
	  the browser has verified that the site certificate’s
	  Common Name matches the host that the page was fetched
	  from, and it has already applied its own policies
	  regarding whether the root certificate is in an
	  acceptable trust domain.</td> </tr> <tr>
	  <td>“tls-ev”</td> <td>As “tls”, and, additionally, the
	  site certificate has an extended validation field and
	  the browser's internal policy allows that information to
	  be passed to the DAP security framework.</td> </tr> <tr>
	  <td>uri</td> <td>URI</td> <td colspan="2">The URI used
	  to access the document that embeds or refers to the
	  JavaScript code, corresponding to the window.location
	  property of the browsing context. In the case of that a
	  Feature is accessed from a child browsing context (for
	  example from within a &lt;iframe&gt; within some outer
	  document), this attribute provides the location of the
	  child context.</td> </tr> <tr> <td>uri-top</td>
	  <td>URI</td> <td colspan="2">The URI used to access the
	  website that embeds or refers to the JavaScript code,
	  corresponding to the top.window property of the browsing
	  context. In the case that the Feature is accessed from a
	  child browsing context (for example from within an
	  &lt;iframe&gt;), this attribute provides the location of
	  the top-level browsing context. If the current browsing
	  context is a child of a widget top-level browsing
	  context, this attribute contains an IRI with the widget:
	  scheme that corresponds to the top-level containing
	  document from the widget resource.</td> </tr> <tr>
	  <td>key-root-cn</td> <td>string</td> <td colspan="2">The
	  common name of the root certificate chained to by the
	  site certificate. Empty bag if none.</td> </tr> <tr>
	  <td>key-root-fingerprint</td> <td>string</td> <td
	  colspan="2">The fingerprint of the root certificate
	  chained to by the site certificate. Empty bag if
	  none.</td> </tr> </tbody> </table> </section> <!--
	  website-identity -->
	</section> <!-- subject-attributes -->
      <section id="resource-attributes">
	<h3>Resource Attributes</h3>
	  <p>
	  The device features or services (e.g. the location module or PIM
	  database) are the actual <strong><em><a id="resource">resources</a></em></strong> that are being protected, but from
	  the point of view of the security framework these resources
	  are associated with the API features and device capabilities used to
	  access them.
	  </p> <p>The resource is identified by one or more of
	  the following attributes: </p> <table border="1"
	  summary=""> <caption> <dfn
	  id="widget-subject-attributes-table">Widget Subject
	  Attributes Table</dfn></caption> <thead> <tr> <th
	  scope="col">Attribute</th> <th scope="col">Type</th> <th
	  scope="col">Value</th> <th scope="col">Comment</th>
	  </tr> </thead> <tbody> <tr> <td id="api-feature">api-feature (*** ref:
	  ****)</td> <td>URI</td> <td>The IRI identifier of the
	  requested Feature converted to URI as per RFC3987
	  [[!IRI]].</td> <td>This uses the same naming scheme as
	  in a widget's &lt;feature&gt; element. See Appendix A
	  (*** change this ref ****). Determined for all
	  applicable application Execution Phases.</td> </tr> <tr>
	  <td id="device-cap">device-cap</td> <td>string</td> <td>Device
	  capability being accessed, if any. Empty bag if
	  none</td> <td>See Appendix A (*** change this ref ***).
	  Determined for all applicable application Execution
	  Phases.</td> </tr> <tr> <td id=parameter>param:name</td> <td>See
	  comment</td> <td>The value of parameter name.</td>
	  <td>The specification of each Device Capabilities lists
	  the parameters associated with that Device Capability
	  and the type and semantics of each. Empty bag if the
	  parameter is not defined. Determined in the invoke
	  execution phase. Undetermined in all other execution
	  phases.</td> </tr> <tr> <td colspan="4">The following
	  resource attributes give information on the source of
	  the implementation of the API Feature.</td> </tr> <tr>
	  <td>feature-install-uri</td> <td>URI</td> <td>The URI
	  that the API implementation was originally retrieved
	  from before installation, if known, otherwise the empty
	  bag.</td> <td>Determined for all applicable application
	  Execution Phases.</td> </tr> <tr>
	  <td>feature-key-cn</td> <td>string</td> <td>The common
	  name of the end entity certificate for the signature
	  associated with the Feature implementation. Empty bag if
	  none.</td> <td>Determined for all applicable application
	  Execution Phases.</td> </tr> <tr>
	  <td>feature-key-root-cn</td> <td>string</td> <td>The
	  common name of the root certificate for the signature
	  associated with the Feature implementation. Empty bag if
	  none</td> <td>Determined for all applicable application
	  Execution Phases.</td> </tr> <tr>
	  <td>feature-key-root-fingerprint</td> <td>string</td>
	  <td>The fingerprint of the root certificate of the
	  signature associated with the Feature implementation.
	  Empty bag if none.</td> <td>Determined for all
	  applicable application Execution Phases.</td> </tr> <tr>
	  </tbody> </table>
      </section> <!-- resource-attributes -->
      <section id="environment-attributes">
	<h3>Environment Attributes</h3>
	  <p>Attributes of the <em>environment</em> capture
	  contextual information relating to the device or other
	  circumstances of the access attempt. </p> <table
	  border="1" summary=""> <caption> <dfn
	  id="widget-subject-attributes-table">Widget Subject
	  Attributes Table</dfn></caption> <thead> <tr> <th
	  scope="col">Attribute</th> <th scope="col">Type</th> <th
	  scope="col">Value</th> <th scope="col">Comment</th>
	  </tr> </thead> <tbody> <tr> <td>roaming</td>
	  <td>string</td> <td>"national", "international", or
	  empty string</td> <td>Determined in the following
	  Execution Phases:
	  <ul> <li>widget-instantiate</li>
	  <li>website-bind</li> <li>invoke</li> </ul>
	  Undetermined in the following Execution Phases:
	  <ul> <li>widget-install</li> </ul>
	  </td> </tr> <tr> <td>bearer-type</td> <td>string</td>
	  <td>The type of the current network bearer over which a
	  network request will be served, either by request of the
	  application or by default (per the current serving
	  network or the one over which the request will be
	  served, if multiple networks are available). A
	  comma-separated list of one or more of the bearer types
	  given as examples in W3C DCO [[DCONTOLOGY]].</td>
	  <td>Determined in the following Execution Phases:
	  <ul> <li>widget-instantiate</li>
	  <li>website-bind</li> <li>invoke</li> </ul>
	  Undetermined in the following Execution Phases:
	  <ul> <li>widget-install</li> </ul>
	  </td> </tr> </tbody> </table>
      </section> <!-- environment-attributes -->
</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:53:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 June 2010 13:53:02 GMT