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

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

From: Laura Arribas via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 02 Jun 2010 13:23:26 +0000
To: public-dap-commits@w3.org
Message-Id: <E1OJnuo-00054X-Lo@lionel-hutz.w3.org>
Update of /sources/public/2009/dap/policy
In directory hutz:/tmp/cvs-serv19479

Added Files:
	Profile.html 
Log Message:
XACML profile doc created

--- NEW FILE: Profile.html ---
<!DOCTYPE html> <html>
  <head>
    <title>Device API Policy Profile: XACML</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-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="values-and-types">
	<h3>Values and Types</h3>
	  <p>Each value in an expression is conceptually a
	  <em>bag</em> of potentially multiple simple values. The
	  bag can be empty, containing no simple values. In
	  practice almost every value encountered in the model is
	  either an empty bag or a bag containing a single simple
	  value. When a bag contains one or more simple values,
	  all the simple values have the same type, one of: </p>
	  <ul>
	    <li>String</li> <li>IRI</li>
	  </ul> <p> Each <a href=#modifier-function>modifier
	  function</a> defines its result type, and how the
	  function's effect depends on the type of the input. </p>
	  <p> Each <a href=#matching-function>matching
	  function</a> defines how it depends on the type of its
	  input. </p> <p> Where a modifier function or matching
	  function does not specify how it treats an input of a
	  particular type, it implicitly converts the value to a
	  bag of strings before performing its operation. </p> <p>
	  When evaluating an access control query at a given
	  application Execution Phase, an expression may have
	  undetermined value if one or more of the attributes on
	  which it depends has undetermined value at that
	  execution phase. </p> <p> For each <a
	  href=#modifier-function>modifier function</a> and <a
	  href=#matching-function>matching function</a>, its
	  result for a given set of inputs is determined if and
	  only if all of its inputs are determined. </p> <p> The
	  syntax used for encoding a certificate fingerprint in
	  DAP Security Policy documents is the SDP syntax defined
	  in [[!RFC4572]] without the "fingerprint" scheme, as
	  follows: </p> <pre><code> dapfingerprint = hash-func SP
	  fingerprint hash-func = "sha-1" / "sha-224" / "sha-256"
	  / "sha-384" / "sha-512" / "md5" / "md2" / token ;
	  Additional hash functions can only come ; from updates
	  to [[!RFC3279]] Fingerprint = 2UHEX *(":" 2UHEX) ; Each
	  byte in upper-case hex, separated ; by colons. UHEX =
	  DIGIT / %x41-46 ; A-F uppercase </code></pre>
	</section> <!-- values-and-types -->
      <section id="attribute-match">
	<h3>Attribute Match</h3>
	  <p>An attribute match is a statement about one attribute
	  whose truth can be evaluated, that is it evaluates to
	  true or false (or undetermined). An attribute match is a
	  subject match, resource match or environment match,
	  depending on whether the attribute being matched is a
	  subject, resource or environment attribute. </p> <p>An
	  attribute match is an expression with a boolean result
	  whose form is limited to one of the following:
	  <ul> <li>matchfunc(modifierfunc(attr),
	  value)</li> <li>matchfunc(attr, value)</li>
	  </ul>
	  Matchfunc is the matching function, a function with a
	  boolean result and two non-boolean inputs. Its result is
	  undetermined if either input is undetermined. </p> <p>In
	  the first case, modifierfunc is a function with a
	  non-boolean result and a single non-boolean input. The
	  result of modifierfunc is undetermined if its input is
	  undetermined. </p> <p> In the second case, there is no
	  modifierfunc. </p> <p>The value to match (matchfunc's
	  second input) is a sequence of literal text and other
	  attribute references implicitly combined using string
	  concatenation. Thus its type is bag containing a single
	  string, unless there is any reference to an attribute
	  resolving to an empty bag, in which case it is an empty
	  bag. Any reference to a non-string attribute is
	  converted to string bag first. Any reference to an
	  attribute whose value is a bag containing two or more
	  values causes the whole match value to be undefined. Any
	  reference to an undetermined attribute causes the whole
	  value to match to be undetermined. </p> <p> For a
	  subject attribute match, only a single literal string is
	  allowed, with no attribute references. </p> <p> If the
	  attribute does not exist, then it has the empty bag
	  value. </p>
	</section> <!-- attribute-match -->
      <section id="subject-specification">
	<h3>Subject Match</h3>
	  <p>A <em>subject</em> specification consists of a
	  conjunctive sequence of <em>subject</em> matches. </p>
	  <p> A specification is evaluated as follows:
	  <ul> <li>is determined and has value TRUE if
	  each of the <em>subject</em> matches has value
	  TRUE</li> <li>otherwise, is undetermined if any
	  or the <em>subject</em> matches is
	  undetermined</li> <li>otherwise is determined
	  and has value FALSE.</li> </ul>
	  A <em>subject</em> match is an attribute match where the
	  attribute being matched is a <em>subject</em> attribute,
	  and the match value is a literal string and does not
	  contain any attribute references. </p>
      </section> <!-- subject-specification -->
  <section id="target">
	<h3>Target</h3>
	  <p>The <em>target</em> of a <em>policy</em> or
	  <em>policy set</em> identifies the set of
	  <em>subjects</em> to which the <em>policy</em> or
	  <em>policy set</em> applies. </p> <p>The <em>target</em>
	  consists of a disjunctive sequence of <em>subject</em>
	  specifications. </p> <p> A target specification is
	  evaluated as follows:
	  <ul> <li>has value TRUE if at least one of the
	  subject specifications has value TRUE</li>
	  <li>otherwise has value FALSE</li> <li>A
	  <em>policy</em> or <em>policy-set</em> that has
	  no <em>target</em> explicitly specified is
	  treated as having a <em>target</em> that
	  evaluates unconditionally to TRUE.</li> </ul>
	  </p>
  </section> <!-- target -->
  <section id="decision">
	<h3>Decision</h3>
	  <p>If determined, the result of a <em>rule</em> or
	  <em>policy</em> or <em>policy set</em> is a
	  <em>decision</em>, either “not applicable” or any one of
	  the <a href="#effect"><em>effects</em></a> “permit”,
	  “prompt-blanket”, “prompt-session”, “prompt-oneshot” or
	  “deny”. </p> <p> The result of a <em>rule</em> or
	  <em>policy</em> or <em>policy set</em> may be
	  undetermined under conditions specified for each below.
	  </p>
  </section> <!-- decision -->
  <section id="rule">
	<h3>Rule</h3>
	  <p>
	  A rule consists of a <a href=#condition>condition</a> and an <a href=#effect>effect</a>.
	  </p> <p>
	  The result of a rule is determined if and only if its condition has determined value.
	  </p>
  </section> <!-- decision -->
  <section id="condition">
	<h3>Condition</h3>
	  <p>The <em>condition</em> of a <em>rule</em> specifies
	  extra criteria that need to be matched before the
	  <em>rule</em> becomes applicable. </p> <p> The
	  <em>condition</em> consists of one or more attribute
	  matches, combined with AND and OR operators into an
	  arbitrarily nested tree. </p> <p> The AND operator is
	  evaluated as follows: <ul> <li>is determined and has
	  value “no match” if any input is “no match”</li>
	  <li>otherwise is undetermined if any input is
	  undetermined</li> <li>otherwise is determined and has
	  value “match”</li> </ul> The OR operator is evaluated as
	  follows: <ul> <li>is determined and has value “match” if
	  any input is “match”</li> <li>otherwise is undetermined
	  if any input is undetermined</li> <li>otherwise is
	  determined and has value “no match”</li> </ul> </p>
  </section> <!-- decision -->
  <section id="policy">
	<h3>Policy</h3>
	  <p>A <em>policy</em> has a <em>target</em>, and a list
	  of zero or more <em>rules</em> combined using a <a
	  href=#combining-algorithm><em>rule-combining
	  algorithm</em></a>. Where a directive attribute query
	  finds more than one applicable directive attribute set,
	  the first one is used. </p> <p>A <em>policy</em>
	  optionally has a textual description. </p> <p> A
	  <em>policy</em> optionally has an id. If an
	  implementation provides a means to provision a security
	  policy fragment to replace an existing one, this id can
	  be used to identify the <em>policy</em> or <em>policy
	  set</em> to replace. No management of ids is mandated,
	  therefore it is recommended that a standardised textual
	  representation of a UUID should be used as the id. </p>
	  <p> The result of a policy is determined if and only if
	  its combining rule has determined value. </p>
  </section> <!-- policy -->
  <section id="policy-set">
	<h3>Policy Set</h3>
	  <p>The overall security framework is a <em>policy
	  set</em>. </p> <p> A <em>policy set</em> is a target
	  with a list of zero or more <em>policies</em> and
	  <em>policy sets</em> combined using a <a
	  href=#combining-algorithm><em>policy-combining
	  algorithm</em></a>. Where a directive attribute query
	  finds more than one applicable directive attribute set,
	  the first one is used. </p> <p> A <em>policy set</em>
	  optionally has an id. If an implementation provides a
	  means to provision a security policy fragment to replace
	  an existing one, this id can be used to identify the
	  <em>policy</em> or <em>policy set</em> to replace. No
	  management of ids is mandated, therefore it is
	  recommended that a standardised textual representation
	  of a UUID should be used as the id. </p> <p> The result
	  of a policy is determined if and only if its combining
	  rule has determined value. </p>
  </section> <!-- policy-set -->
  <section id="policy-document">
	<h3>Policy Document</h3>
	  <p>Where the implementation supports deployment of a
	  fragment of policy to add to the existing security
	  policy framework or to replace a part of it, the
	  <em>policy document</em> is the unit of addition or
	  replacement. A <em>policy document</em> can be either a
	  <em>policy</em> or a <em>policy set</em>. </p>
		</section> <!-- policy-document -->
  <section id="signed-policy-document">
	<h3>Signed Policy Document</h3>
	  <p>Where the implementation supports deployment of
	  policy fragments as above, the <em>signed policy
	  document</em> is the cryptographically signed unit of
	  deployment. It contains one or more <em>policy
	  documents</em> as well as a single signature. </p>
  </section> <!-- signed-policy-document -->
  <section id="matching-function">
	<h3>Matching Function</h3>
	  <p>The matching function used in an attribute match is
	  one of the following. </p>
	  <section id="string-equality-matching-function">
	    <h4>String Equality Matching Function</h4>
	      <p>True if and only if some string from one input string
	      bag is byte-for-byte equal to some string from the other
	      input string bag. Thus an empty bag is not equal to
	      anything, not even another empty bag. An input of type
	      other than empty bag or string bag is converted to
	      string bag first. </p>
	  </section> <!-- string-equality-matching-function -->
	  <section id="globbing-matching-function">
	    <h4>Globbing Matching Function</h4>
	      <p>True if and only if, for some string in the first
	      input string bag, the entire string matches the glob
	      pattern in some string in the second input string bag.
	      If either input is the empty bag, the result is false.
	      An input of type other than empty bag or string bag is
	      converted to string bag first. </p> <p>A glob pattern is
	      as described in [[!SUS3]] section 2.13 Pattern Matching Notation
	      but excluding 2.13.3 Patterns Used for Filename
	      Expansion. </p> <!-- Shell & Utilities Volume of the SUSv3 spec --><p>Using this function with a glob
	      pattern of “*” (a single asterisk) is a convenient way
	      to test whether the first input is not an empty bag.
	      </p>
	  </section> <!-- globbing-matching-function -->
	  <section id="regular-expression-matching-function">
	    <h4>Regular Expression Matching Function</h4>
	      <p>True if and only if, for some string in the first
	      input string bag, some part of the string matches the
	      regular expression pattern in some string in the second
	      input string bag. If either input is the empty bag, the
	      result is false. An input of type other than empty bag
	      or string bag is converted to string bag first. </p>
	      <p>This uses the definition of regular expressions in
	      ECMAScript 3rd edition [[!ECMA-262]]. </p>
	  </section> <!-- regular-expression-matching-function -->
  </section> <!-- matching-function -->
  <section id="modifier-function">
	<h3>Modifier Function</h3>
	  <p>The modifier function optionally specified in each
	  attribute in a target or condition is one of the
	  following. </p>
	  <section id="uri-scheme-modifier-function">
	    <h4>URI-Scheme Modifier Function</h4>
	      <p>If the input is a string bag, first it is converted
	      to a URI bag by interpreting each string as a URI. Any
	      string that does not have the form of a URI is removed
	      from the bag. </p> <p>Each URI in the bag is converted
	      to a string by taking the URI’s scheme component. </p>
	      <p>Thus the result type is either the empty bag or
	      string bag. </p>
	  </section> <!-- uri-scheme-modifier-function -->
	  <section id="uri-authority-modifier-function">
	    <h4>URI-Authority Modifier Function</h4>
	      <p>If the input is a string bag, first it is converted
	      to a URI bag by interpreting each string as a URI. Any
	      string that does not have the form of a URI is removed
	      from the bag. </p> <p>Each URI in the bag is converted
	      to a string by taking the URI’s scheme and authority
	      components. If the URI does not have an authority
	      component, it is removed from the bag. </p> <p>Thus the
	      result type is either the empty bag or string bag. </p>
	  </section> <!-- uri-authority-modifier-function -->
	  <section id="uri-scheme-authority-modifier-function">
	    <h4>URI-Scheme-Authority Modifier Function</h4>
	      <p>If the input is a string bag, first it is converted
	      to a URI bag by interpreting each string as a URI. Any
	      string that does not have the form of a URI is removed
	      from the bag. </p> <p>Each URI in the bag is converted
	      to a string by taking the URI’s scheme and authority
	      components. If the URI does not have an authority
	      component, it is removed from the bag. </p> <p>Thus the
	      result type is either the empty bag or string bag. </p>
	  </section> <!-- uri-scheme-authority-modifier-function -->
	  <section id="uri-host-modifier-function">
	    <h4>URI-Host Modifier Function</h4>
	      <p>If the input is a string bag, first it is converted
	      to a URI bag by interpreting each string as a URI. Any
	      string that does not have the form of a URI is removed
	      from the bag. </p> <p>Each URI in the bag is converted
	      to a string by taking the URI’s scheme and authority
	      components. If the URI does not have an authority
	      component, it is removed from the bag. </p> <p>Thus the
	      result type is either the empty bag or string bag. </p>
	  </section> <!-- uri-host-modifier-function -->
	  <section id="uri-path-modifier-function">
	    <h4>URI-Path Modifier Function</h4>
	      <p>If the input is a string bag, first it is converted
	      to a URI bag by interpreting each string as a URI. Any
	      string that does not have the form of a URI is removed
	      from the bag. </p> <p>Each URI in the bag is converted
	      to a string by taking the URI’s scheme and authority
	      components. If the URI does not have an authority
	      component, it is removed from the bag. </p> <p>Thus the
	      result type is either the empty bag or string bag. </p>
	  </section> <!-- uri-path-modifier-function -->
  </section> <!-- modifier-function -->
  <section id="combining-algorithm">
	<h3>Combining Algorithm</h3>
	  <p>The <em>policy-combining algorithm</em> for a
	  <em>policy set</em> determines how child
	  <em>policies</em> and <em>policy sets</em> are combined.
	  </p> <p>The <em>rule-combining algorithm</em> for a
	  <em>policy</em> determines how child <em>rules</em> are
	  combined. </p> <p>The algorithms are described in the
	  following subsections. The term <em>child</em> is used
	  to mean the child <em>rules</em> in the <em>policy</em>
	  when applying the <em>policy's rule-combining
	  algorithm</em>, or the child <em>policies</em> and
	  <em>policy sets</em> in the <em>policy set</em> when
	  applying the <em>policy set's policy-combining
	  algorithm</em>. </p>
	  <section id="deny-overrides-combining-algorithm">
	    <h4>Deny-Overrides Combining Algorithm</h4>
	      <p>The Deny-Overrides Combining Algorithm is usable as a
	      policy-combining algorithm and as a rule-combining
	      algorithm. </p> <p>The overall result of a
	      <em>query</em> is evaluated as follows: <ul> <li>if any
	      child evaluates to "deny", then the overall result is
	      "deny";</li> <li>otherwise, if any child is
	      undetermined, then the overall result is
	      undetermined;</li> <li>otherwise, if any child evaluates
	      to "prompt-oneshot", then the overall result is
	      "prompt-oneshot";</li> <li>otherwise, if any child
	      evaluates to "prompt-session", then the overall result
	      is "prompt-session";</li> <li>otherwise, if any child
	      evaluates to "prompt-blanket", then the overall result
	      is "prompt-blanket";</li> <li>otherwise, if any child
	      evaluates to "permit", then the overall result is
	      "permit";</li> <li>otherwise, the overall result is
	      "inapplicable".</li> </ul> </p>
	  </section> <!-- deny-overrides-combining-algorithm -->
	  <section id="permit-overrides-combining-algorithm">
	    <h4>Permit-Overrides Combining Algorithm</h4>
	      <p>The Permit-Overrides Combining Algorithm is usable as
	      a policy-combining algorithm and as a rule-combining
	      algorithm. The overall result of a <em>query</em> is
	      evaluated as follows: <ul> <li>if any child evaluates to
	      "permit", then the overall result is "permit";</li>
	      <li>otherwise, if any child is undetermined, then the
	      overall result is undetermined;</li> <li>otherwise, if
	      any child evaluates to "prompt-blanket", then the
	      overall result is "prompt-blanket";</li> <li>otherwise,
	      if any child evaluates to "prompt-session", then the
	      overall result is "prompt-session";</li> <li>otherwise,
	      if any child evaluates to "prompt-oneshot", then the
	      overall result is "prompt-oneshot";</li> <li>otherwise,
	      if any child evaluates to "deny", then the overall
	      result is "deny";</li> <li>otherwise, the overall result
	      is "inapplicable".</li> </ul> </p>
	  </section> <!-- permit-overrides-combining-algorithm -->
	  <section id="first-applicable-rule-combining-algorithm">
	    <h4>First-Applicable Rule Combining Algorithm</h4>
	      <p>The First-Applicable Rule Combining Algorithm is
	      usable as a rule-combining algorithm. </p> <p>The
	      overall result of a query is evaluated by processing the
	      children in written order as follows: <ul> <li>if the
	      current child is determined and does not evaluate to
	      "inapplicable", the overall result is the result of the
	      current child;</li> <li>otherwise, if the current child
	      is undetermined, the overall result is
	      undetermined;</li> <li>otherwise, if the current child
	      is determined and has value "inapplicable", continue
	      processing at the next child. If already processing the
	      final child, the overall result is "inapplicable".</li>
	      </ul> </p>
	  </section> <!-- first-applicable-rule-combining-algorithm -->
	  <section id="first-matching-target-policy-combining-algorithm">
	    <h4>First-Matching-Target Policy Combining Algorithm</h4>
	      <p>The First-Matching-Target Policy Combining Algorithm
	      is usable as a policy-combining algorithm. </p> <p>The
	      overall result of a query is evaluated by processing the
	      children in written order as follows: <ul> <li>if the
	      current child has a target that matches the overall
	      result is the result of the current child;</li>
	      <li>otherwise, continue processing at the next child. If
	      already processing the final child, the overall result
	      is "inapplicable".</li> </ul> </p>
	  </section> <!-- first-matching-target-policy-combining-algorithm -->
  </section> <!-- combining-algorithm -->
  <section id="effect">
	<h3>Effect</h3>
	  <p>The <em>effect</em> of a <em>rule</em> is one of the
	  following: </p>
	  <section id="permit">
	    <h4>Permit</h4>
	      <p>This <em>effect</em> allows requested access without
	      user interaction. </p>
	  </section> <!-- permit -->
	  <section id="deny">
	    <h4>Deny</h4>
	      <p>This <em>effect</em> denies requested access without
	      user interaction. </p>
	  </section> <!-- deny -->
	  <section id="prompt-x">
	    <h4>Prompt-x</h4>
	      <p>The prompt-oneshot, prompt-session and prompt-blanket
	      effects allow requested access after explicit
	      confirmation by the user. The implementation <em
	      title="must" class="rfc2119">must</em> prompt the user
	      before allowing access. </p> <p>The implementation <em
	      title="must" class="rfc2119">must</em> only provide the
	      user the option to grant permission up to the maximum
	      allowed by the <em>effect</em>, ie: <ul>
	      <li>prompt-oneshot: "deny always", "deny this time",
	      "allow this time";</li> <li>prompt-session:
	      prompt-oneshot options plus "deny for this session",
	      "allow for this session";</li> <li>prompt-blanket:
	      prompt-session options plus "allow always".</li> </ul>
	      The implementation <em title="must"
	      class="rfc2119">must</em> provide a means to respond
	      with any available option that is applicable in the
	      context in which the prompt is displayed. </p> <p> Any
	      default action <em title="must"
	      class="rfc2119">must</em> be at least as restrictive as
	      "deny this time". </p> <p> If the user has the option of
	      deferring a response indefinitely and the user does not
	      respond explicitly, the requested access <em title="must
	      not" class="rfc2119">must not</em> be allowed. </p> <p>
	      For a widget, a session lasts while the application is
	      still running and the terminal has not been switched off
	      or placed in standby mode. </p> <p> For a website,
	      another visit to the same page in the same Browser tab
	      or window is part of the same session. </p>
	  </section> <!-- prompt-x -->
  </section> <!-- effect -->
  <section id="query">
	<h3>Query</h3>
	  <p>A <em>query</em> represents a specific instance of a
	  security policy being evaluated in order to make an
	  access control decision relating to an attempted
	  operation by a web application. </p> <p>A <em>query</em>
	  is characterised by the collection of <em>subject
	  attributes</em> associated with the web application
	  instance, the collection of <em>resource attributes</em>
	  associated with the attempted operation, and the
	  collection of <em>environment attributes</em> associated
	  with the circumstances of the attempt. The
	  determinedness of each of these attributes is in
	  accordance with the <em>execution phase</em> of the
	  attempt. </p> <p>A <em>query</em> is evaluated against a
	  <em>policy-set</em>, resulting in a <em>decision</em> in
	  accordance with the evaluation rules defined in this
	  specification. </p>
  </section> <!-- query -->
</section> <!-- security-model-definition -->
  <section id="security-policy-document-format">
    <h2>Security Policy Document Format</h2>
      <p> This section defines a method for representing a Security Policy (e.g. for
      interchange or device management purposes). </p>
      <section id="schema">
      <h3>Schema</h3>
	<section id="signed-policy">
	  <h4>The <code>&lt;signed-policy&gt;</code> Element</h4>
	    <p>The root element of a signed policy document is a
	    <code><code>&lt;signed-policy&gt;</code></code>. </p>
	    <p><code>&lt;signed-policy&gt;</code> contains, in any
	    order, exactly one <code>&lt;signature&gt;</code>
	    element and one or more elements each of which is either
	    <code>&lt;policy-set&gt;</code> or
	    <code>&lt;policy&gt</code>;. </p>
	</section>
	<section id="signature">
	  <h4>The <code>&lt;signature&gt;</code> Element</h4>
	    <p>The <code>&lt;signature&gt;</code> element, as a
	    child of <code>&lt;signed-policy&gt;</code>, specifies
	    the detached digital signature of the signed policy
	    document as defined in XML Digital Signature
	    [[!XMLDSIG-CORE2]], with the following additional
	    constraints: </p> <ul>
	      <li>the <code>&lt;signature&gt;</code> element <em
	      title="must" class="rfc2119">must</em> contain one or
	      more valid &lt;Reference&gt; elements;</li> <li>the
	      URL attribute of each &lt;Reference&gt; element <em
	      title="must" class="rfc2119">must</em> contain a
	      reference to a <code>&lt;policy&gt</code>; or
	      <code>&lt;policy-set&gt;</code> element that is a
	      sibling of the <code>&lt;signature&gt;</code> element
	      in the same Signed Policy Document;</li> <li>the
	      &lt;Reference&gt; element <em title="must"
	      class="rfc2119">must not</em> have any
	      &lt;Transform&gt; elements;</li> <li>the widget user
	      agent <em title="must" class="rfc2119">must</em> treat
	      the <code>&lt;signed-policy&gt;</code> as invalid if
	      it has a child <code>&lt;policy&gt</code>; or
	      <code>&lt;policy-set&gt;</code> element for which
	      there is no &lt;Reference&gt; element.</li>
	    </ul> <p> Processing of the signature is specified in
	    section (*** change ref ***). </p>
	</section> <section id="policy-set">
	  <h4>The <code>&lt;policy-set&gt;</code> Element</h4>
	    <p>The root element of a policy document is either a
	    <code>&lt;policy-set&gt;</code> or a
	    <code>&lt;policy&gt</code>;.
	    <code>&lt;policy-set&gt;</code> has two possible
	    attributes: </p> <ul>
	      <li>combine, which <em title="must"
	      class="rfc2119">must</em> take a value of
	      "deny-overrides", "permit-overrides" or
	      "first-matching-target". The attribute is optional; if
	      it is omitted, the default value is
	      "deny-overrides";</li> <li>id, whose value is a
	      textual identifier for the
	      <code>&lt;policy-set&gt;</code>.</li>
	    </ul> <p> <code>&lt;policy-set&gt;</code> contains an
	    optional <code>&lt;target&gt</code>;, then zero or more
	    <code>&lt;policy&gt</code>; and/or
	    <code>&lt;policy-set&gt;</code> elements. </p>
	</section>
	<section id="rule">
	  <h4>The <code>&lt;rule&gt;</code> Element</h4>
	    <p><code>&lt;rule&gt;</code> has one possible attribute,
	    effect, which must take a value of "permit",
	    "prompt-blanket", "prompt-session", "prompt-oneshot" or
	    "deny". The attribute is optional; if it is omitted, the
	    default value is "permit". </p>
	    <p><code>&lt;rule&gt;</code> contains an optional
	    <code>&lt;condition&gt;</code>. </p>
	</section>
	<section id="target">
	  <h4>The <code>&lt;target&gt;</code>  Element</h4>
	    <p><code>&lt;target&gt;</code> contains one or more
	    <code>&lt;subject&gt;</code> elements. </p>
	</section>
	<section id="subject">
	  <h4>The <code>&lt;subject&gt;</code> Element</h4>
	    <p><code>&lt;subject&gt;</code> contains one or more
	    <code>&lt;subject-match&gt;</code> elements. </p>
	</section>
	<section id="condition">
	  <h4>The <code>&lt;condition&gt;</code> Element</h4>
	    <p> <code>&lt;condition&gt;</code> has one possible
	    attribute, combine, which must take a value of "and" or
	    "or". The attribute is optional; if it is omitted, the
	    default value is "and". </p>
	    <p><code>&lt;condition&gt;</code> contains one or more
	    elements, each of which is one of
	    <code>&lt;condition&gt;</code>,
	    <code>&lt;subject-match&gt;</code>,
	    <code>&lt;resource-match&gt;</code> or
	    <code>&lt;environment-match&gt;</code>. </p>
	</section>
	<section id="subject-match, resource-match, environment-match">
	  <h4>The <code>&lt;subject-match&gt;</code>, <code>&lt;resource-match&gt;</code>, <code>&lt;environment-match&gt;</code> Elements</h4>
	    <p><code>&lt;subject-match&gt;</code> represents a
	    condition on a single subject attribute to be matched in
	    a target or condition.
	    <code>&lt;resource-match&gt;</code> represents a
	    condition on a single resource attribute to be matched
	    in a condition. <code>&lt;environment-match&gt;</code>
	    represents a condition on a single environment attribute
	    to be matched in a condition. </p> <p>The element has up
	    to three (XML) attributes: </p> <ul>
	      <li>(mandatory) attr: the name of the subject,
	      resource or environment (respectively) attribute to
	      check. The attribute name is optionally followed by
	      one of the suffixes ".scheme", ".authority",
	      ".scheme-authority", ".host" or ".path", causing the
	      equivalently named URI modifier function to be applied
	      to the attribute value before matching.</li>
	      <li>(optional) match: the literal text to match. If
	      this attribute is omitted, then the contents of the
	      element are used instead.</li> <li>(optional) func:
	      the match function to use. If it is present, it must
	      be one of "equal", "glob" or "regexp". If func is
	      omitted, then the default is "glob".</li>
	    </ul> <p>The contents of a
	    <code>&lt;subject-match&gt;</code>,
	    <code>&lt;resource-match&gt;</code> or
	    <code>&lt;environment-match&gt;</code> element represent
	    the value to match, only if the match attribute is
	    absent. If the match attribute is present, then the
	    element contents are ignored. For a
	    <code>&lt;subject-match&gt;</code>, the contents are
	    PCDATA. For the others, the contents can be any
	    combination of PCDATA,
	    <code>&lt;subject-attr&gt;</code>,
	    <code>&lt;resource-attr&gt;</code> and
	    <code>&lt;environment-attr&gt;</code> elements, giving
	    the literal text to match after expanding any
	    attributes. </p>
	</section>
	<section id="subject-attr, resource-attr, environment-attr">
	  <h4>The <code>&lt;subject-attr&gt;</code>, <code>&lt;resource-attr&gt;</code>, <code>&lt;environment-attr&gt;</code> Elements</h4>
	    <p>
	    Each of these elements represents the value of a
	    subject, resource or environment attribute
	    respectively.
	    </p> <p>
	    The element has one (XML) attribute, attr, giving the
	    name of the attribute to expand. It has no contents.
	    </p>
	</section>
  </section>
</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:23:28 GMT

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