OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [xacml] Initial set of Change Requests

These are the change requests I culled from recent mailings.
Please review to be sure I have captured all your change requests

To make future tracking of changes easier, I propose the
following procedure:

a. All future mailings that request a change MUST have [CR]
   in the subject line.  The remainder of the subject should
   include enough keywords about the change to identify it.
   For example, Change Request 0001 below would have been
   submitted with a subject line of:

   [CR] Add AttributeValue element to support sequence-of values

b. Separate change requests MUST be submitted in separate
c. Responses to change requests MUST keep the same subject line
   (module Re: [xacml]) so that discussion can be tracked.
d. Change requests MUST begin with the exact text proposed.  This
   allows a specific change to be voted on.
e. Change requests SHOULD continue with a Rationale explaining
   why the change is needed.
f. Try to be succinct.


Title:   Change Requests
Version: 1.1, 02/08/22 (yy/mm/dd)

0001. [Daniel] Add AttributeValue element to support sequence-of values

    Currently <attributeValue> element is an extension of
    anyType, with specified DataType.  XACML functions arguments
    are, in general, a sequence of typed elements - as it can be
    returned by a designator from context.  While most accept
    only single values (sequence of size 1), some set operation
    functions have an arbitrary length sequence as an argument.
    We need to provide syntax to express a sequence of values as
    a literal argument in set operations (like union, member_of,

    I propose adding element Value, of anyType, and defining
    <AttributeValueType> as sequence of <Value>, with DataType
    attribute, applicable to all elements in the sequence.  It
    supports 0 size of the sequence, to support empty set in
        <xs:element name="Value" type="xs:anyType"/>
        <xs:element name="AttributeValue"/>
       <xs:complexType name="AttributeValueType">
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
           <xs:element ref="Value"/>
          <xs:attribute name="name" type="xs:anyURI" use="required"/>

0002. [Anne] Add mandatory action-id attribute

        Create a reserved attribute identifier
        "urn:oasis:names:tc:xacml:1.0:action:action-id".  Make inclusion
        of an <Attribute> with AttributeId of this identifier mandatory
        under the <Action> element of the <Request> context.  Change
        minOccurs for <Attribute> under <Action> 1.


        We had previously decided that <Action> would have a single
        string value that would be the action id.  Now we need a
        specific AttributeId for this.

        This is consistent with the way resource-id is handled.  It
        provides a consistent, interoperable way of specifying the
        action.  The <DataType> of the <Attribute> can specify whether
        the action value is a string or URI.

0003. [Anne] Add optional action-namespace attribute

        Create a reserved attribute identifier
        "urn:oasis:names:tc:xacml:1.0:action:action-namespace".  Make
        inclusion of an <Attribute> with AttributeId of this identifier
        optional under the <Action> element of the <Request> context.


        We previously decided that an <Action> value might be
        associated with a specific namespace, and that an XML attribute
        was needed to express this.

0004. [Anne] Add optional action:implied-action identifier

        Create a reserved identifier
        "urn:oasis:names:tc:xacml:1.0:action:implied-action" to
        represent the value of an action that is implied by the


        We have agreed to this concept, but have not reserved an
        identifier for it.

0005. [Anne] Change <Result> ResourceURI xml attribute to ResourceId


        Since the Request <Resource> identifier is now called
        resource-id, and can be of any data type, the <Result> should
        be consistent.

0006. [Anne] Add missing-attribute identifier for StatusCode


        We have values for ok, processing-error, and syntax-error.
        Although we discussed the use case for missing attributes
        extensively, we have not defined a standard identifier for this

0007. [Anne] Make context Resource Attribute minoccurs=1

        Current value is minOccurs=0 maxOccurs=unbounded.  Change this
        to minOccurs=1 maxOccurs=unbounded.


        Since Resource MUST contain a resource-id attribute, minimum
        value should be 1.

0008. [Anne] list mandatory vs. non-mandatory functions

      Add a list of all functions, with an indicator as to
      whether the function is mandatory to implement, to the
      Conformance Section.

      This list should be updated based on the final resolution
      of CR#23.


        I forgot to include these when I created the original list.

      Text to be inserted:

      M indicates mandatory-to-implement.

         Function identifier
      M  function:integer-add
      M  function:decimal-add
         function:add-yearMonthDuration-to dateTime
      M  function:integer-subtract
      M  function:decimal-subtract
      M  function:integer-multiply
      M  function:decimal-multiply
      M  function:integer-divide
      M  function:decimal-divide
      M  function:integer-mod
      M  function:decimal-mod
      M  function:round
      M  function:floor
      M  function:abs
      M  function:integer
      M  function:decimal
      M  function:integer-equal
      M  function:decimal-equal
      M  function:boolean-equal
      M  function:string-equal
      M  function:rfc822Name-equal
      M  function:x500Name-equal
      M  function:date-equal
      M  function:time-equal
      M  function:datetime-equal
      M  function:gregorian-equal
      M  function:hex-binary-equal
      M  function:base64-binary-equal
      M  function:anyURI-equal
      M  function:QName-equal
      M  function:NOTATION-equal
      M  function:integer-greater-than
      M  function:decimal-greater-than
      M  function:string-greater-than
      M  function:date-greater-than
      M  function:time-greater-than
      M  function:datetime-greater-than
      M  function:integer-greater-than-or-equal
      M  function:decimal-greater-than-or-equal
      M  function:string-greater-than-or-equal
      M  function:date-greater-than-or-equal
      M  function:time-greater-than-or-equal
      M  function:datetime-greater-than-or-equal
      M  function:string-match
      M  function:rfc822Name-match
      M  function:x500Name-match
      M  function:and
      M  function:ordered-and
      M  function:or
      M  function:ordered-or
      M  function:n-of
      M  function:not
      M  function:present
         [where X can be any supported data type]
      M  X-intersection
      M  X-union
      M  X-member-of
      M  X-first
      M  X-rest
      M  X-length

0009. [Daniel] Function naming convention

    Change function names to blah_blah


    Dashes are not always supported.

0010. [Anne] allow more than two arguments to "add"

      Allow function:integer-add and function:decimal-add to take
      more than two arguments.


      This saves having to write nested statements for these simple

0011. [Carlisle] state *Match is matched against AttributeValue

      In section 5.7 (Element <SubjectMatch>), I think we need to
      specify that whatever is returned by
      SubjectAttributeDesignator or AttributeSelector is matched
      against the value carried in AttributeValue.  The same is
      true for <ResourceMatch> and <ActionMatch> (sections 5.10
      and 5.13).


      This behaviour is not spelled out anywhere.  (In fact,
      AttributeValue is not even described in the "list of
      elements contained in <SubjectMatch>" discussion; it only
      appears in the schema fragment.)

0012. [Carlisle] <AttributeSelector> in <SubjectMatch> should be [optional]

      Make <AttributeSelector> in <SubjectMatch> [optional]
      rather than [required].


      Also, in the "list of elements contained in <SubjectMatch>"
      discussion, why is <AttributeSelector> described as
      [required]?  I thought it was optional.

0013. [Carlisle] <SubjectMatch> in <SubjectAttributeDesignatorWhere> min/max

      Make minOccurs="1" and maxOccurs="unbounded" for
      <SubjectMatch> in <SubjectAttributeDesignatorWhere>.


      In section 5.26 (Element
      <SubjectAttributeDesignatorWhere>), why does the element
      <SubjectMatch> have minOccurs="0"?  If this element was
      omitted, you wouldn't use SubjectAttributeDesignatorWhere;
      you would just use SubjectAttributeDesignator.  In any
      case, the verbal description says that SubjectMatch has
      [Any Number], so I suspect that minOccurs="0" in the schema
      should be changed to maxOccurs="unbounded".

0014. [Carlisle] 10. "Security and Privacy Considerations"

      Change title of Section 10 to "Security and Privacy


      Should this be called "Security and Privacy Considerations"
      instead of just "Security and Privacy"?

0015. [Carlisle] 10. "Statement Level Confidentiality": rules/policies

      In the 10. "Statement Level Confidentiality" section, 1st
      paragraph, say "... a PRP only needs access to the target
      elements in order to find the appropriate policies".


      Currently says: "... a PRP only needs access to the target
      elements in order to find the appropriate rules".  Should
      this say "rules/policies", or just "policies", instead of

0016. [Carlisle] 10. "Policy Integrity": rule/policy

      In the 10. "Policy Integrity" section, 4th paragraph, say
      "The PDP SHOULD NOT request a policy based on who signed
      the policy...".


      In the "Policy Integrity" section, 4th paragraph, it
      currently says "The PDP SHOULD NOT request a rule based on
      who signed the rule...".  Should both occurrences of "rule"
      be "policy"?

0017. [Carlisle] 10. "Resource Matching": NotApplicable treated as Permit

      In 10. "Resource Matching" section, say, 'although the
      policy result of "Not Applicable" is treated as equivalent
      to "Permit" by many web servers, this behavior is not


      In the "Resource Matching" section, 1st paragraph, it says
      "... the policy result of "Not Applicable" is treated as
      equivalent to "Permit" as is common in many web servers".
      I'm a bit surprised that this is true (although I probably
      shouldn't be!).  In any case, we probably don't want to
      encourage this behaviour.  Should we simply not mention
      this, or should we at least say that this behaviour is not

      Hal's rejoinder:

      First of all, this is intended as a cautionary
      example. However, this is a real world problem that affects
      my product, and all of our compeitors. I can show you
      security holes posted to BUGTRAQ, for example, where this
      occurred. We have struggled with it for years. The Not
      Applicable == Permit behavior is not only standard for web
      servers, it is embedded in the Java Servlet and JSP

      The logic is that only a small portion of the resources on
      a public web server are protected, so people want to only
      specify rules for those that are. If the namespace is not
      conveniencely laid out (as most are not) it may require a
      number of rules just to specify all the pages that are not

0018. [Carlisle] C.3 use "First Applicable"

      Call Section C.3, "First Applicable" rather than "First
      Applicable Rule Combining Algorithm".

      In first sentence of C.3, change "First Determinate"
      rule-combining algorithm to "First Applicable".


      Section C.3, should this be called "First Applicable"
      rather than "First Applicable Rule Combining Algorithm"?
      This would be more consistent with both C.1 and C.2, and
      would also be more consistent with the fact that C.3
      contains both a rule combining algorithm and a policy
      combining algorithm.

      The first sentence of C.3 calls it the "First Determinate"
      rule-combining algorithm; this should be changed to "First

0019. [Carlisle] C. consistent error behavior

      Policy combiner should halt and return Indeterminate when
      an error is encountered.


      The behaviour specified in the policy-combining algorithm
      when an error is encountered is different from the
      behaviour specified in the rule-combining algorithm when an
      error is encountered (the rule combiner says halt and
      return Indeterminate, whereas the policy combiner says to
      keep looking for an applicable policy).  Is this what we

      More importantly, might the policy combiner behaviour not
      lead to different answers for the same inputs?  For
      example, say there are two policies that are to be combined
      using this algorithm.  Given a particular set of input
      values, the first policy would return a decision of
      "Permit" and the second policy would return a decision of
      "Deny".  Now we give all the inputs to two different PDPs.
      The first PDP retrieves the first policy, gets an answer of
      "Permit", and returns this to the PEP.  The second PDP has
      trouble retrieving the first policy for whatever reason
      and, according to the combining algorithm, retrieves the
      second policy; it then returns a "Deny" to the PEP. Isn't
      this the sort of result we want to avoid?  Wouldn't the
      behaviour specified in the rule combining algorithm be
      preferable (that way, the first PDP would return "Permit"
      and the second would return "Indeterminate", which seems
      fine to me)?

0020. [Michiharu] B.10: Resource Attributes scope value

      In B.10, the identifier indicates the scope of the request
      with regard to the resource. When this attribute is
      specified in the request, the value MUST be either
      'Immediate', 'Children', or 'Descendant'.

0021. [Michiharu] 8.1 Operational Model: PDP description change

      8.1 Policy Decision Point (PDP)

      Given a valid XACML "Policy" or a "PolicySet", a compliant XACML PDP MUST
      evaluate that statement in accordance to the semantics specified in Section
      4,5, and 6 when applied to a specific input context. The PDP MUST return an
      output context, with one value of "Permit", "Deny", "Indeterminate", or

      If a permit is returned, the PEP permit access to the requested resource.
      If a denial is returned, the PEP denies access to the requested resource.
      If a permit with one or more obligations is returned, the PEP permits
      access provided that every obligations are fulfilled successfully. If a
      denial with one or more obligations is returned, the PEP denies access but
      still fulfills the obligations. In each case, when fulfilling obligations
      failed, the PEP SHOULD raise an error. How the error is raised is out of
      the scope of XACML. In any case, the PDP can return additional information
      in the status code element in the response context. For 'Permit' decision,
      it MAY specify which rules are used in decision making.

      If an indeterminate is returned, it means that the PDP could not make
      decision due to some reason. The PDP MAY return decision of "indeterminate"
      with a status code of "urn:oasis:names:tc:xacml:1.0:missing-attribute",
      signifying that more information is needed. In this case, the decision MAY
      list the names of any attributes of the subject and the resource that are
      needed by the PDP to refine its decision. A PEP MAY resubmit a refined
      request context in response to a decision of "indeterminate" with a status
      code of "missing-attribute" by adding attribute values for the attribute
      names that are listed in the response. When the PDP returns an decision of
      "indeterminate", with a status code of "missing-attribute", a PDP MUST NOT
      list the names of any attribute of the subject or the resource of the
      request for which values were already supplied in the request. Note, this
      requirement forces the PDP to eventually return a decision of "permit",
      "deny", or "indeterminate" with some other reason, in response to
      successively-refined requests.

      If not applicable is returned, it means that the PDP's policy does not
      cover the request, implying that the PEP should ask another PDP.

      XACML does not assume how top-level XACML policies should be configured.
      For example, a top-level policy might be a 'Policy' element containing a
      target element that matches every request, or it might be a 'Policy'
      element containing a target element that matches only a specific subject.

0022. [Michiharu] 8.1 Operational Model: New sections

      8.2 Hierarchical Resource

      It is often the case that a target resource is organized as a hierarchy
      (e.g. file system, XML document). Some applications may require access to
      an entire subtree of the resource. XACML allows the PEP (or Context
      Handler) to specify whether the access is just for a single resource or for
      a subtree below the specified resource. The latter is equivalent to
      repeating a single request for the entire subtree. When a request context
      contains a resource attribute of
      'urn:oasis:names:tc:xacml:1.0:resource:scope' with a value of 'Immediate',
      or does not contain that attribute in the context, then it means that the
      access is just for a single resource specified by 'ResourceId' attribute.
      When 'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a
      value of 'Children', it means that the access is for both a specified
      resource and its children resources. When
      'urn:oasis:names:tc:xacml:1.0:resource:scope' attribute specifies a value
      of 'Descendant', it means that the access is for both a specified resource
      and all the descendant resources. In the case of 'Children' and
      'Descendant', the access decision may include multiple results for the
      multiple resources. XACML response can contain multiple result elements. In
      such case, the status element SHOULD be included only in the first result
      element (the remaining result elements SHOULD NOT include the status
      element). Note that the method how PDP finds out whether the resource is
      hierarchically organized or not is out of the scope of the XACML.

      8.3 Propagation through Data Hierarchy

      When the resource is hierarchically organized, it is often the case that an
      access control rule associated to a certain node propagates down to the
      descendant nodes. The XACML core rule combining algorithm does not support
      such propagation with regard to access control rules. Policy writers who
      need propagation MUST implement their own local algorithm and specify that
      algorithm ID in RuleCombiningAlgId in policy element.

0023. [Daniel, Polar] function names, types, semantics

      This change request is a place-holder.  I propose that
      Daniel and Polar come up with a list of functions,
      semantics, and types table that they BOTH agree on.  This
      will be the Change Request inserted here to be voted on.

      CR#8 should be updated based on the final list of functions
      to show which are mandatory-to-implement.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC