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] | [List Home]

Subject: Proposed text change to core spec, associated w Errata issue #4

The issue is about Sec 5.42 of the core spec:

The issue was raised on the email list entitled:
  Subject: Re: [xacml] Issue: Ambiguity in defn of Request wrt Attributes Category,
 and Erik suggested, and I agreed that it should be handled in the Errata:

Sometime after the issue was posted on the wiki for Errata (issue #4):
    4 Multiple Category Elements

Erik added the following comment:
'Note from Erik: The core spec is intended to operate only on single instances of a given attribute category.
  Anything else is specified in the multiple decision profile.
  This is stated in section 5.42

      "There may be multiple <Attributes> elements with the same Category attribute
         if the PDP implements the multiple decision profile, see [Multi].
        Under other conditions, it is a syntax error
          if there are multiple <Attributes> elements with the same Category (see Section 7.19.2 for error codes)." '
I agree that the above text addresses the issue, but I believe there is still a problem
that the text is located in the wrong place.

The problem is that I raised this issue when I was actually implementing this use case
as part of the OpenAz project upgrade to XACML 3.0, and I was using the core spec
for guidance, but did not see the text that Erik quoted above.

In retrospect, after reading Erik's note to errata,
 the reason that I didn't notice the text was that
  I was looking for the rules governing use of the <Attributes> element
   in the part of sec 5.42 that describes the <Attributes> element that says the following:
"<Attributes>   [One to Many]
         Specifies information about attributes of the request context by listing a sequence of <Attribute> elements
            associated with an attribute category.
         One or more <Attributes> elements are allowed.
         Different <Attributes> elements with different categories are used to represent information
           about the subject, resource, action, environment or other categories of the access request."
Unfortunately, this text does not say anything about the syntax error condition, that is described
in the header part of Sec 5.42.

By comparison, the next child element of the Request element, is described as follows:
"<MultiRequests>   [Optional]
               Lists multiple request contexts by references to the <Attributes> elements.
               Implementation of this element is optional.
               The semantics of this element is defined in [Multi].
               If the implementation does not implement this element,
                  it MUST return an Indeterminate result if it encounters this element. See section 5.50."
i.e. in this case the description of the child element contains the complete description,
including what constitutes an error and how it should be handled, and where to
find more info.

Therefore, my recommendation is to move the text quoted by Erik above, from the
header section of 5.42, and append it starting on a new line immediately following the
current text that describes the <Attributes> element. This will make the <Attributes> element
description consistent in scope w other elements, such as the <MultiRequests> described
above i.e. put the whole description of the child element in one place,
 not divided between the header and the element descriptions.


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