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] Current list of Change Requests


Appended is a list of current Change Requests.  I will send out
an updated copy 1 hour before tomorrow's conference call, but
this copy may be helpful for those of you who will not be able to
print or study that copy in time.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Title:   Change Requests Set 3
Author:  Anne Anderson
Version: 1.9, 02/10/16 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests3.txt

This file contains all Change Requests not reflected in the
v0.18c.doc version of the XACML Specification; these include all
unresolved e-mail between archive messages
http://lists.oasis-open.org/archives/xacml/200210/msg00123.html
and
http://lists.oasis-open.org/archives/xacml/200210/msg00188.html

ACTION ITEMS
============
None

LEGEND
======
NQ=no quorum; official vote required
Q=quorum

SUMMARY
=======
AA01: Remove Table 4 - Attribute Identifiers from A.13.1
  STATUS: not yet considered
AA02: New section in Appendix A on Structured  datatypes
  STATUS: not yet considered
HL01: Typos in 18c
  STATUS: Editorial.  Vote not required.
HL02: Policy Indexing
  STATUS: not yet considered.  Modified with Polar's text.
AA03: typo: 2.10.Actions performed in conjunction with enforcement
  STATUS: Editorial.  Vote not required.
PH01: Clarifications changes on 18c
  STATUS: CLOSED. Broken out into PH04-PH10, plus additions to HL02.
PH02: Review of Obligations Section 5.32
  STATUS: not yet considered.
PH03: Section 7.5
  STATUS: not yet considered.
AA04: 5.1 PolicySetId explanation clarification
  STATUS: revised based on comment from Tim.
AA05: editorial: PolicyCombiningAlgId reference
  STATUS: Editorial.  Vote not required.
AA06: clarify computed <Target>s
  STATUS: not yet considered
HL03: Question about Anonymous Access Subject
  STATUS: not yet considered.
PH04: 2.3 Combining algorithms, add "Only-one-applicable-policy"
  STATUS: not yet considered.
PH05: 5.22 Element <Function>: clarify description
  STATUS: not yet considered.
PH06: 5.23 AttributeDesignator selects collection, not set
  STATUS: not yet considered.
PH07: 5.29 Clarify <AttributeSelector>
  STATUS: not yet considered.
PH08: 5.32 Clarify <Obligation>
  STATUS: not yet considered.
PH09: New section 7.4.2 Attributes
  STATUS: not yet considered.
PH10: 7.5 Clarify Authorization decision
  STATUS: not yet considered.
AA07: point to 7.x Obligations from other places
  STATUS: not yet considered.
AA08: specify default XPathVersion
  STATUS: Not yet considered.
AA09: editorial: remove 10.3.1 XPathNamespace
  STATUS: Editorial.  Vote not required.
AA10: editorial: Add reference [IBMSDA] to references
  STATUS: Editorial.  Vote not required.
AA11: Clarify "MatchId" functions
  STATUS: Not yet considered.  Bag functions omitted per comment from Polar.
AA12: editorial: move B.5 Environment attributes after B.8Action attributes
  STATUS: Editorial.  Vote not required.
SteveHanna01: integer-mod takes two arguments
  STATUS: Not yet considered.
SatoshiHada01: How many namespaces does XACML define?
  STATUS: not yet considered.
AA13: Remove B.11 Identifiers used in conformance tests
  STATUS: not yet considered.
AA14: amended: editorial: get Piras' name right
  STATUS: Editorial. Vote not required.  Revised to add additional location.
AA15: editorial: glossary Policy and PolicySet "componet" to "component"
  STATUS: Editorial.  Vote not required.  AA16 merged in.
AA16: editorial: Glossary Policy set "componet" to "component"
  STATUS: CLOSED (replaced by revised AA15)
AA17: editorial: use "Requester", not "Requestor"
  STATUS: Editorial.  Modified based on comments.
AA18: editorial: change "implementor" to "implementer"
  STATUS: Editorial.  Revised based on comments.
AA19: editorial: "interdeterminate" to "indeterminate"
  STATUS: Editorial.  Vote not required.
AA20: editorial: replace "First-Appplicable" with"First-Applicable"
  STATUS: Editorial.  Vote not required.
AA21: editorial: change "URI os the" to "URI of the"
  STATUS: Editorial.  Vote not required.
AA22: editorial: fix reference to RFC 2821 in B.4
  STATUS: Editorial.  Vote not required.
AA23: editorial: change "the URLfrom which" to"the URL from which"
  STATUS: Editorial.  Vote not required.
AA24: Add references for Haskel
  STATUS: Editorial.  Vote not required.
AA25: editorial: A.3 add reference to [IBMSDA]"
  STATUS: Editorial.  Vote not required.
AA26: typo: 10.3.3 "alorithm" to "algorithm"
  STATUS: Editorial.  Vote not required.
AA27: typo: Sun Microsystems, not Sun Micrososytems
  STATUS: Editorial.  Vote not required.
AA28: typo: change "adverary" to "adversary"
  STATUS: Editorial.  Vote not required.
AA29: typo: 7.4.1 Hierarchial resources to Hierarchicalresources
  STATUS: Editorial.  Vote not required.
AA30: typo: 6.11 replace "retrieveing" with "retrieving"
  STATUS: Editorial.  Vote not required.
AA31: typo: 6.11 replace "network errrors" with"network errors"
  STATUS: Editorial.  Vote not required.
AA32: clarify use of "dn"
  STATUS: not yet considered.
AA33: typo: xs:complType to xs:complexType
  STATUS: Editorial.  Vote not required.
AA34: editorial: B.3 XACML functions see Appendix A
  STATUS: Editorial.  Vote not required.  [was 2nd AA11]
AA35: typo: 6.2 "ulitmately" to "ultimately"
  STATUS: Editorial.  Vote not required.
AA36: typo: 6.1 replace "contextby" with "context by"
  STATUS: Editorial.  Vote not required.
AA37: typo: 6.1 "<Subject> elements.Each" to"<Subject> elements. Each"
  STATUS: Editorial.  Vote not required.
AA38: typo: 5.28 "<xacml-contex:" to "<xacml-context:"
  STATUS: Editorial.  Vote not required.
AA39: typo: 5.7 "context.and" to "context and"
  STATUS: Editorial.  Vote not required.
AA40: typo: 5.5 "conjuctive" to "conjunctive"
  STATUS: Editorial.  Vote not required.
AA41: typo: "PolicyIdReferece" to "PolicyIdReference"
  STATUS: Editorial.  Vote not required.
AA42: typo: change "explicitely" to "explicitly"
  STATUS: Editorial.  Vote not required.
AA43: use "xs:" or "xsi:"?
  STATUS: not yet considered.
AA44: 6.10 change "resource-uri" to "resource-id"
  STATUS: Editorial.  Vote not required.
SP01: 18c comments.  Forwarded message from Seth Proctor.
  STATUS: Not yet considered.
AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
  STATUS: not yet considered.
AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
  STATUS: not yet considered.

DETAILS
=======
AA01: Remove Table 4 - Attribute Identifiers from A.13.1
  e-mail sent 11 Oct 2002 09:53:48 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00123.html

  STATUS: not yet considered

  TEXT LOCATION: Section A.13.1, following x500Name-equal function
  description (p.191, line 3527 in my copy of 18c :-)

  TEXT CHANGE: Remove "Table 4 - Attribute identifiers"

  RATIONALE: This table is no longer part of the normalization step
  for x500Name types and is no longer referenced.  The description
  of normalization now simply refers to IETF RFC2253.

AA02: New section in Appendix A on Structured  datatypes
  e-mail sent 11 Oct 2002 10:27:09 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00124.html

  STATUS: not yet considered

  TEXT LOCATION: Section A, following "A.2 Primitive
  types" (p. 86, between lines 3345 and 3346 in my copy of 18c :-)

  TEXT CHANGE: Add following new section

    A.3 Structured types

    An XACML <AttributeValue> MAY contain an instance of a structured
    xml data type, for example <ds:KeyInfo>.  XACML 1.0 supports
    three ways of comparing such <AttributeValue>s.

    1) In some cases, such an <AttributeValue> may be compared
       using one of the XACML string functions, such as
       regexp-string-match, described below.  This requires the
       structured data, including its tags and attributes, to be
       treated as an <xs:string>.  In general, this method will not
       be adequate unless the structured data type is quite simple.

    2) An <AttributeSelector> element may be used to select the value
       of a leaf sub-element of the structured data type.  That value
       may then be compared using one of the supported XACML
       functions appropriate for its primitive data type.

    3) An <AttributeSelector> element may be used to select the value
       of any node in the structured type.  This node may then be
       compared using one of the XPath-based functions described
       below.

    Methods 2) and 3) require support for optional XACML features
    (XPath expressions and XPath functions) by the PDP.

    A fourth alternative is for a community of XACML users to define
    separate attribute identifiers for each leaf sub-element of a
    given structured data type.  Using these identifiers, the Context
    Handlers used by that community of users can flatten instances of
    the structured data type into a sequence of <Attribute>s.  Each
    such <Attribute> will have an <AttributeValue> that is and
    instance of one of the XACML-supported primitive Datatypes, and
    thus can be compared using the XACML-supported functions.

  RATIONALE: this change was proposed in "[xacml] Proposed text for
  new section in Appendix A on Structureddatatypes", 03 Oct 2002
  14:16:09 -0400(EDT),
  http://lists.oasis-open.org/archives/xacml/200210/msg00017.html

  On 11 October, Daniel Engovatov writes:
   > How can <AttributeValue dataType="ds:KeyInfo"> with required attribute  used
   > as an xs:string?  Is not it a type error?  Would be the syntax for such
   > <apply>?

  Declare the DataType as xs:string, not ds:KeyInfo.  This is not
  very workable, since there must be an EXACT string equality, or
  else a very complex regular expression, used in the Policy.  But,
  as I said, in some cases this might work.

  Example:

  Request:
  <Subject>
      <Attribute
            AttributeId="urn:oasis:names:tc:xacml:1.0:subject:key-info"
            DataType="xs:string">
          <AttributeValue><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue>
      </Attribute>
  </Subject>

  Policy:
  <Target>
      <Subjects>
          <Subject>
              <SubjectMatch
                    MatchId="function:string-match">
                  <SubjectAttributeDesignator
                        AttributeId="urn:oasis:names:tc:xacml:1.0:subject:key-info"
                        DataType="xs:string"/>
                  <AttributeValue
                        DataType="xs:string"><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue>
              </SubjectMatch>
          </Subject>
      </Subjects>
  ....

HL01: Typos in 18c
  e-mail sent 11 Oct 2002 11:17:52 -0400
  http://lists.oasis-open.org/archives/xacml/200210/msg00125.html

  STATUS: Editorial.  Vote not required.

  Section 2. Background (Non-mormative), line 309:
      Non-mormative --> Non-normative

  Section 6.2 Element <Subject>, line 2474
      Distingwished --> Distinguished

HL02: Policy Indexing
  e-mail sent 11 Oct 2002 12:10:39 -0400
  http://lists.oasis-open.org/archives/xacml/200210/msg00128.html

  STATUS: not yet considered.  Modified with Polar's text.
  SEE ALSO: AA06, SP01a

  TEXT LOCATION: Section 2.8 Policy indexing, p. 14, lines
  471-545

  TEXT CHANGE: replace existing numbered paragraphs and the
    paragraph starting with "In either case" with following

  1. Policy statements may be stored in a database, whose
     data-model is congruent with that of the <Target> element.
     The PDP should use the contents of the decision request that
     it is processing to form the database read command by which
     applicable policy statements areretrieved.  Nevertheless,
     the PDP should still evaluate the <Target> element of the
     retrieved policy or policy set statements as defined by the
     XACML specification.

  2. Alternatively, the PDP may evaluate the <Target> element
     from each of the policies or policy sets that it has
     available to it, in the context of a particular decision
     request, in order to identify the policies and policy sets
     that is applicable to that request.

  TEXT LOCATION: Section 7.1 "Initial policy", p. 68, lines
  2825-2827

  TEXT CHANGE: replace 'A PDP SHALL represent one Policy, or
    Policy Set. Should the PDP be dynamic in nature in retrieving
    policies based on the request, the PDP SHALL act as if
    represents a single Policy Set with the "Only One Applicable
    Policy" policy combining algorithm.' with

    'A PDP SHALL represent one Policy, or Policy Set. Should the
    PDP be dynamic in nature in retrieving policies based on the
    request with no explicit policy combining algorithm, the PDP
    SHALL act as if represents a single Policy Set with the "Only
    One Applicable Policy" policy combining algorithm.'

  RATIONALE: Section 2.8 describes two policy indexing
  strategies. This seems like a reasonable discussion to motivate
  the use of target, but I have a couple of concerns.

  1. My most important concern is that it states that "only one
  policy statement applies". This is contrary to my understanding
  (or what are combining algorithms for?) and it appears to
  contradict section 2.2 specifically.

  2. I really don't see that strong a distinction between the two
  cases and I suspect that they are not the only possibilities
  either. It seems to me that the general case is basically that
  you have a bunch of policies stored someplace and you need to
  find the ones (hopefully using some efficient technique) who's
  Targets match the corresponding fields in the Request
  Context. Period.

  Am I missing some subtleties here? If there is general
  agreement, I would be willing to draft some text, but I don't
  want to do so until there is consensus.

  [Tim] Hal - I have no objection to your redrafting that
  section.  Remember, though, that separate policies applicable
  to the same request do not identify an algorithm for combining
  them, unless they are encapsulated in a policy set containing
  an identifier for a combining algorithm.  That policy set
  becomes the single policy applicable to the request.  I am open
  to the idea that the current explanation may be confusing.
  But, by my understanding, we cannot present a PDP with multiple
  policies for a request, because it won't know how to combine
  them.

  [Polar] I agree. I drafted a One-applicable-policy combining
  algorithm to handle this case. In conjunction, in Section 7.1,
  it states that a PDP shall represent One Policy or Policy Set.

  That should take care of it.

  However, the next sentence in 7.1. may be worrysome, which says
  "Should the PDP be dynamic in nature in retrivin policies based
  on the request, the PDP ShALL act as if it represents a single
  policy set with the "Only One APplicable Policy" policy
  combining algorithm."

  So, what I think this is saying is that if you do not explicity
  configure your PDP with a single Policy or Policy Set, it
  specifies a default behavior of finding the "only" policy that
  should apply.

  I think we should really get rid of the text that stipulates
  that only one policy applies in Section 2.8, and leave it to
  the 7.1 section.


AA03: typo: 2.10.Actions performed in conjunction with enforcement
  e-mail sent 11 Oct 2002 12:37:06 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00129.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 2.10, 4th line down (p. 15, line 510 in my
  copy of 18c :-)

  TEXT CHANGE: replace
    evalution in the <Obligations> element. which idea was described
                                            ^^^^^
  with
    evaluation in the <Obligations> element.  This idea was described
  
PH01: Clarifications changes on 18c
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: CLOSED. Broken out into PH04-PH10, plus additions to HL02.

  I've just attached a copy of 18c with some editorial changes. I've put
  the change bars on so you can see what they are, and Simon or Tim can
  merge them into their version of the document.

  I've changed only a few things that are manly clarifications based on our
  agreements on Thursday. I think I address to Hal's concerns about the
  policy indexing and the attribute things, as well as some other concerns
  about attributes and datatypes.

  Currently I see change bars in:

  Section 2 header (non-morative)
  Section 2.3 Added Only-one-applicable combining algorithm and description
  Section 2.8 Policy indexing clarifications
  Section 5.22 Function clarification with cross references
  Section 5.29 Attribute Selector clarifications
  Section 5.32 Obligation clarifications
  Section 7.1 Initial Policy clarification
  Section 7.4.2 Added Attribute Section
  Section 7.5 Authorization Decision about listing datatypes with missing
              attribute ids.

PH02: Review of Obligations Section 5.32
  e-mail sent 11 Oct 2002 14:05:37 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00134.html

  STATUS: not yet considered.

  I think we should take out the "semantic" definitions on the fulfillment
  of Section 5.32 Obligations in this element definition. (i.e. in this
  section).

  TEXT CHANGE: change the sentence "The FulfillOn attribute SHALL indicated the
  decision value for which this obligation MUST be fulfilled." to

  The FulfillOn attribute SHALL indicated the effect for which
  this obligation applies.

  FulfillOn [required]

  The effect for which this obligation applies.


  RATIONALE: The fulfillment of obligations is taken care of in
  the Chapter 7.

PH03: Section 7.5
  e-mail sent 11 Oct 2002 14:12:05 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00135.html

  STATUS: not yet considered.

  The second to last paragraph in Section 7.5 says "If a decision value of
  "NotApplicable" is returned, it means that the PDP's policy is not
  applicable to the request, implying that the PEP should send its request
  to another PDP.

  I think we should get rid of "implying that the PEP should send its
  request to another PDP" which contradicts the later sections.

  [Bill]that would seem to be consistent with our singular
  treatment of PDPs in section 7.

AA04: 5.1 PolicySetId explanation clarification
  e-mail sent 11 Oct 2002 15:56:51 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00138.html

  STATUS: revised based on comment from Tim.

  TEXT LOCATION: Section 5.1 (PolicySet), explanation of
  PolicySetId (p. 44, lines 1845-1848 in my copy of 18c)

  TEXT CHANGE: Change "The party assigning the identifier MUST
  minimize the potential of some other party reusing the same
  identifier." to

  "It is the responsibility of the PAP to ensure that no two
  policies visible to a PDP have the same identifier."

AA05: editorial: PolicyCombiningAlgId reference
  e-mail sent 11 Oct 2002 16:01:00 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00139.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 5.1 (PolicySet), explanation of
  PolicyCombiningAlgId (p. 44, lines 1852-1853 in my copy of 18c).

  TEXT CHANGE: Change "Standard policy-combining algorithm
  identifiers are listed in Section Combining Algorithms." to
  "Standard policy-combining algorithm identifiers are listed in
  Appendix B.10 Combining Algorithms."

AA06: clarify computed <Target>s
  e-mail sent 11 Oct 2002 16:36:51 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00142.html

  STATUS: not yet considered
  SEE ALSO: HL02, SP01a

  TEXT LOCATIONs:
  1) Section 5.1 (PolicySet), explanation of <Target>
     element (p. 44, lines 1661-1863 in my copy of 18c).
  2) Section 5.17 (Policy), explanation of <Target> element (p. 52,
     lines 2170-2172).

  TEXT CHANGE: In both locations above, replace

    "The <Target> element MAY be declared by the creator of the
    [<PolicySet>|<Policy>] or it MAY be computed from the <Target>
    elements of the referenced [<PolicySet> and <Policy>|<Rule>]
    elements, either as an intersection or as a union."

  with

    "See Section 5.5 Target for more information about the <Target>
    element."
  ---------------------
  TEXT LOCATION: In Section 5.5 Element <Target>, just before the
  schema fragment (p. 46, after line 1908 in 18c).

  TEXT CHANGE: Add

    "See Section 7.4 Target construction for more information about
    how a <Target> element may be constructed."
  ---------------------
  TEXT LOCATION: following Section "7.3 Policy evaluation".

  TEXT CHANGE: Add new section as follows:

    7.4 Target construction

    An XACML <PolicySet>, <Policy>, or <Rule> has a <Target>
    element that specifies the set of Subjects, Resources, and
    Actions to which the <PolicySet>, <Policy>, or <Rule> applies.
    The <Target> of a <PolicySet> or <Policy> may be declared by
    the creator of the <PolicySet> or <Policy>, or may be
    constructed prior to evaluation of the <PolicySet> or <Policy>
    from the <Target> elements of the referenced <PolicySet>s,
    <Policy>s, and <Rule>s.

    The component that might construct a <Target> dynamically is
    outside the scope of XACML, but there are two logical methods
    that might be utilized.  In one method, the <Target> of the
    outer <PolicySet> or <Policy> (the "outer component") is
    constructed as the union of all the <Target>s of the referenced
    <PolicySet>s, <Policy>s, or <Rule>s (the "inner components").
    In another method, the <Target> of the outer component is
    constructed as the intersection of all the <Target>s of the
    inner components.  The results of evaluation will be very
    different depending on which method is chosen: in the first
    case, the <Target> of the outer component makes it applicable
    to any Request that matches the <Target> of at least one inner
    component; in the second case, the <Target> of the outer
    component makes it applicable only to Requests that match the
    <Target> of every inner component.  Note that computing the
    intersection of a set of <Target>s is not necessarily easy.  It
    is also not possible to compute a perfect intersection in every
    case.

    In cases where the <Target> of a <Policy> is specified by the
    <Policy> creator, any component <Rule>s in the <Policy> that
    have the same <Target> may omit the <Target> element.  Such
    <Rule>s inherit the <Target> of the <Policy> in which they are
    contained.

  RATIONALE: How it is constructed should be completely transparent
  to the XACML policy evaluator, but how it is constructed will
  affect the results of the policy.

HL03: Question about Anonymous Access Subject
  e-mail sent 11 Oct 2002 11:56:37 -0400
  http://lists.oasis-open.org/archives/xacml/200210/msg00126.html

  STATUS: not yet considered.

  Is there a cannonical way to represent an anonymous access
  subject in the Request Context? This seems to me to be an
  extremely common case that should be described in the spec. (My
  preference would be to leave out the access subject entirely,
  but I see that it is mandatory)

  [Anne] Yes, there is a canonical way.  The sequence of
  Attributes under <Subject> is minOccurs=0, so you can have a
  Request Context in which the one <Subject> element has no
  Attributes (such as no subject-id).

  [Polar] A question that we are wrestling with in our logical
  analysis of the security protocols, namely CSIv2, is whether
  not having a prncipal is really an anonymous principal.

  I think we are finding that there is a "default" principal, of
  which you associated a principal with by either configuration
  (let's say a request that comes over a VPN).

  Also, you can assert an anonymous principal, which actually
  states that you really do not know who it is. This principal is
  supremely weaker than all other principals.

  We might come up with a particular identifier saying
  "Anonymous", but should make sure it isn't used for the
  "default" case, unless the default case is truly anonymous.

  In constrast to the default case, we could have a "default"
  principal id, or, we direct the PEP to "fill" the principal in
  with the default principal's id.

  [Daniel] ..And to write rules on anonymous subject I presume
  one has to use <anysubject> for target? Right?  Does missed
  subject have applicable rules written on <anysubject> ?

  [Bill] that was my understanding.

PH04: 2.3 Combining algorithms, add "Only-one-applicable-policy"
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 2.3 Combining algorithms, p. 12, lines
  382-383

  TEXT CHANGE: Replace
    o Permit-overrides and
    o First applicable

  with
    o Permit-overrides,
    o First-applicable and
    o Only-one-applicable-policy

  TEXT LOCATION: p. 12, line 390, at end of paragraph starting
  "In the first case"

  TEXT CHANGE: Add
  The "Only-one-applicable-policy" combining algorithm only
  applies to polcies. The result of this combining algorithm
  ensures that only one policy or policy set applies by virtue of
  their targets. If no policy or policy set applies, the result
  is "NotApplicable", but if more than one policy or policy set
  applies, then the result is "Indeterminate". When exactly one
  policy or policy set applies, the result of the combining
  algorithm is the result of evaluating the applicable policy or
  policy set.

PH05: 5.22 Element <Function>: clarify description
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 5.22 Element <Function>, p. 55, lines
  2276-2286

  TEXT CHANGE: replace "The Function element SHALL be used to
  name a function that is applied by the bag functions to every
  element of a bag." with

  "The Function element SHALL be used to name a function that is
  applied by the higher order bag functions to every element of a
  bag. The higher order bag functions are described in Appendix
  Higher-order bag functions."

  TEXT CHANGE: replace description of "FunctionId [Required]": 
  "The identifier for the function that is applied to the
  elements of a bag." with

  "The identifier for the function that is applied to the
  elements of a bag by the higher order bag functions."

PH06: 5.23 AttributeDesignator selects collection, not set
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 5.23 Complex type
  AttributeDesignatorType, 2nd paragraph, first sentence, p. 55,
  line 2292

  TEXT CHANGE: replace "Elements of AttributeDesignatorType type
  select a set of attribute values from the request
  context." with

  "Elements of AttributeDesignatorType type select a collection
  of attribute values from the request context."

PH07: 5.29 Clarify <AttributeSelector>
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 5.29 Element <AttributeSelector>, first
  paragraph, p. 58, lines 2410-2411

  TEXT CHANGE: Replace "The AttributeSelector element evaluates
  to a bag of a single primitive values that is implied by the
  type system, i.e. the function application in which the
  selector appears." with

  "The AttributeSelector element evaluates to a bag of values of
  a single primitive type, specified by the selector's
  DataType. In the case where the XPATH expression matches
  attributes in the request context by AttributeId, it must also
  match the attribute's DataType with the selector's DataType."

PH08: 5.32 Clarify <Obligation>
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 5.32 Element <Obligation>, p. 59, lines
  2470-2471

  TEXT CHANGE: Replace "The FulfillOn attribute SHALL indicate
  the decision value for which this obligation MUST be
  fulfilled." with

  "The FulfillOn attribute SHALL indicate the effect for which
  this obligation applies."

  TEXT LOCATION: Section 5.32 Element <Obligation>, p. 59,
  description of "FulfillOn [required]" attribute, line 2487.

  TEXT CHANGE: Replace "The decision value for which this
  obligation MUST be fulfilled." with

  "The effect for which this obligation applies."

PH09: New section 7.4.2 Attributes
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Following Section 7.4.1 "Hierarchi[c]al
  resources", p. 70, after line 2911.

  TEXT CHANGE: Add following new sections:

  7.4.2 Attributes

  Attributes are specified in the request context and are
  referred to in the policy by the subject, resource, action, and
  environment attribute designators. Each attribute specifies an
  AttributeId and a DataType, and each attribute desigator
  specifies an AttributeId and DataType. Attribute Designators
  SHALL match attributes by using string equality on both the
  AttributeId and DataType values.

  7.4.2.1 Attribute Retrieval

  The PDP SHALL retrieve the values of attributes that match the
  particular attribute designator and form them into a bag of
  values with the specified DataType. If no attributes from the
  request context match, the attribute shall be considered
  missing, and an empty bag is said to be retrieved.

  7.4.2.2 Missing Attributes

  The PDP MAY return an authorization decision of "Indeterminate"
  result in evaluating an expression that requires at least one
  value to be present from an attribute designator. The
  AttributeId and DataType of the attribute MAY be listed in the
  result as described in Section Authorization decision. However,
  a PDP MAY fail to issue such information due to security
  concerns.

PH10: 7.5 Clarify Authorization decision
  e-mail sent 11 Oct 2002 16:13:36 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00141.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 7.5 Authorization decision, paragraph 2,
  following first occurrence of the missing-attribute URN.

  TEXT CHANGE: Replace "In this case, the <Status> element MAY
  list the names of any attributes of the subject and the
  resource that are needed by the PDP to refine its decision." 
  with

  "In this case, the <Status> element MAY list the names and data
  types of any attributes of the subject and the resource that
  are needed by the PDP to refine its decision."

  TEXT LOCATION: Section 7.5 Authorization decision, paragraph 2,
  following third occurrence of the missing-attribute URN.

  TEXT CHANGE: Replace "it MUST NOT list the names of any
  attribute of the subject or the resource of the request for
  which values were supplied in the request." with

  "it MUST NOT list the names and data types of any attribute of
  the subject or the resource of the request for which values
  were supplied in the request."

  TEXT LOCATION: Section 7.5 Authorization decision, paragraph 3.

  TEXT CHANGE: Delete the following paragraph:

  'If a decision value of "NotApplicable" is returned, it means
  that the PDP's policy is not applicable to the request,
  implying that the PEP should send its request to another PDP.'

AA07: point to 7.x Obligations from other places
  e-mail sent 14 Oct 2002 09:23:19 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00147.html

  STATUS: not yet considered.

  TEXT LOCATIONS:
  1) 5.1 Element <PolicySet>, description of
     <Obligations>[Optional], p. 45, lines 1874-1875.
  2) 5.17 Element <Policy>, description of <Obligations>[Optional],
     p. 52, lines 2179-2181.
  3) 5.32 Element <Obligation>, p. 59, lines 2468-2510
  4) 6.10 Element <Result>, description of
     <xacml:Obligations>[Optional], p. 66, lines 2742-2745

  TEXT CHANGE: In each location, add:

  "See Section 7.6 Obligations, for a description of how the set
   of Obligations to be returned to the PEP are determined."

AA08: specify default XPathVersion
  e-mail sent 14 Oct 2002 09:26:08 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00148.html

  STATUS: Not yet considered.

  TEXT LOCATION: Section 5.4 Element <XPathVersion>, p. 45, lines
  1896-1900

  TEXT CHANGE: Append:

  "If the <XPathVersion> element is omitted, then the XPath 1.0
  specification is used by default."

  RATIONALE: Specify which XPathVersion is used in case the
  <XPathVersion> element is not included.

AA09: editorial: remove 10.3.1 XPathNamespace
  e-mail sent 14 Oct 2002 09:30:40 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00149.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 10.3.1 Schema elements, entry for
  "Xacml:Policy XPathNamespace  O", p. 79, table lines between
  3238-3239.

  TEXT CHANGE: remove the line identifying the XPathNamespace
  schema element from this list.

  RATIONALE: element no longer exists.

AA10: editorial: Add reference [IBMSDA] to references
  e-mail sent 14 Oct 2002 09:33:46 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00150.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 11. References

  TEXT CHANGE: Add following new reference entry

    "[IBMSDA]   IBM Standard Decimal Arithmetic.  Available at
     http://www2.hursley.ibm.com/decimal/decarith.html";;

  RATIONALE: referenced from A.1 Introduction, but not included in
  11. References.

AA11: Clarify "MatchId" functions
  e-mail sent 14 Oct 2002 09:48:04 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00151.html

  STATUS: Not yet considered.  Bag functions omitted per comment from Polar.

  TEXT LOCATION: Section A.11 Matching elements, p. 89, lines
  3446-3456.

  TEXT CHANGE: Replace following paragraph:

    "The match elements: <SubjectMatch>, <ResourceMatch> and
     <ActionMatch> SHALL use XACML standard functions to perform
     the match evaluation.  The function used for determinaing a
     match is named in the MatchId attribute of these elements.
     Each of these elements contains a <AttributeDesignator> or
     <AttributeSelector> element and an explicit attribute value.
     The restriction on the function is that the MatchId attribute
     must name a binary function, such that its result type is
     "xs:boolean".  Also, each argument to the named function must
     match the appropriate primitive types for the
     <AttributeDesignator> or <AttributeSelector> element and the
     following explicit attribute value, such that the explicit
     attribute value is placed as the first argument to the
     function, while an element of the bag returned by the
     <AttributeDesignator> or <AttributeSelector> element is placed
     as the second argument to the function."

    with the following:

    "The match elements: <SubjectMatch>, <ResourceMatch> and
     <ActionMatch> SHALL use functions that match two arguments,
     returning a result type of "xs:boolean", to perform the match
     evaluation.The function used for determinaing a match is named
     in the MatchId attribute of these elements.  Each argument to
     the named function must match the appropriate primitive types
     for the <AttributeDesignator> or <AttributeSelector> element
     and the following explicit attribute value, such that the
     explicit attribute value is placed as the first argument to
     the function, while an element of the bag returned by the
     <AttributeDesignator> or <AttributeSelector> element is placed
     as the second argument to the function.

     The XACML standard functions that may be used as a MatchId
     attribute value are:

        function:*-equal
        function:*-greater-than
        function:*-greater-than-or-equal
        function:*-less-than
        function:*-less-than-or-equal
        function:*-match

  RATIONALE: explanation of which functions may be used as MatchId
  functions is not clear.  Also, function used need not be a
  "standard" function as long as it returns a boolean and its
  arguments follow the required format.

AA12: editorial: move B.5 Environment attributes after B.8Action attributes
  e-mail sent 14 Oct 2002 09:55:37 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00153.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Appendix B

  TEXT CHANGE: Move current "B.5 Environment attributes" section to
  follow current "B.8 Action attributes" section.

  RATIONALE: Environment attributes follow all the Subject,
  Resource, and Action attributes in the Request Context.

SteveHanna01: integer-mod takes two arguments
  personal communication to Anne Anderson on 14 Oct 2002

  STATUS: Not yet considered.

  TEXT LOCATION: Section A.13.2 Arithmetic functions, p. 92,
  4569, list of functions that take a single argument.

  TEXT CHANGE: Move "integer-mod" up to the list of functions
  that take two arguments.

SatoshiHada01: How many namespaces does XACML define?
  e-mail to xacml-comment 15 Oct 2002 13:51:19 +0900

  STATUS: not yet considered.

  It is unclear to me how many namespaces XACML tries to define.

  Appendix B.1 says that the following two namespace URIs are defined.
    urn:oasis:names:tc:xacml:1.0:policy
    urn:oasis:names:tc:xacml:1.0:context

  However, it seems to me that XACML tries to define at least two other
  namespaces.

  (1) One is for function identifiers, i.e.,
      urn:oasis:names:tc:xacml:1.0:function.  Indeed, the type of
      the "FunctionID" attribute is xs:QName and so I think this
      URN should be one of namespace URIs defined in the XACML
      specification.

  (2) The other is for data types, i.e.,
      urn:oasis:names:tc:xacml:1.0:datatype. Currently, the type
      of the "DataType" attribute is xs:anyURI.

      I think it should be xs:QName and this URN should be one of
      namespace URIs defined in the XACML specification.

AA13: Remove B.11 Identifiers used in conformance tests
  e-mail sent 14 Oct 2002 09:58:56 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00154.html

  STATUS: not yet considered.

  TEXT LOCATION: Section B.11, p. 111, lines 4325-4328

  TEXT CHANGE: remove entire Section "B.11 Identifiers used only
  in XACML conformance tests"

  RATIONALE: just as for identifiers used in examples, I don't
  think we need to spell out the identifiers used in conformance
  tests.

AA14: amended: editorial: get Piras' name right
  e-mail sent 14 Oct 2002 11:30:20 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00162.html

  STATUS: Editorial. Vote not required.  Revised to add additional location.

  TEXT LOCATIONS:
  1) Title page, Contributors, p. 1, line 24
  2) Appendix D. Acknowledgments, p. 119, line 4694

  TEXT CHANGE: Replace "Piras Vilandai Thiyatarajan, Sun
  Microsystems" with "Pirasenna Velandai Thiyagarajan, Sun
  Microsystems"

AA15: editorial: glossary Policy and PolicySet "componet" to "component"
  e-mail sent 14 Oct 2002 11:07:10 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00157.html

  STATUS: Editorial.  Vote not required.  AA16 merged in.

  TEXT LOCATION:
  1) Section Glossary "1.1.1 Preferred terms", entry for
     "Policy", p. 8, line 242
  2) Section Glossary "1.1.1 Preferred terms", entry for "Policy
     set", p.9, line 252

  TEXT CHANGE: replace "componet" with "component"

AA16: editorial: Glossary Policy set "componet" to "component"
  e-mail 14 Oct 2002 11:09:04 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00158.html

  STATUS: CLOSED (replaced by revised AA15)

AA17: editorial: use "Requester", not "Requestor"
  e-mail sent 14 Oct 2002 11:19:48 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00159.html

  STATUS: Editorial.  Modified based on comments.

  TEXT LOCATIONS:
  1) Section 1.1.2 "Related terms", last sentence in section,
     p. 9, line 267.
  2) Section 4.2.4 "Rule 2", explanation for [48]-[82], p. 35,
     line 1372
  3) Section 4.2.4 "Rule 2", explanation for [51]-[65], p. 35,
     line 1377
  4) Section 4.2.4.5 "Example PolicySet", each bullet item,
     pp. 41-42, lines 1723-1726

  TEXT CHANGE: change spelling from "Requestor" to "Requester"

  RATIONALE: Some locations in the document already use
  "requester".  We should be consistent.  American Heritage
  Dictionary spells it this way. [Bill - Websters allows for
  both, but lists "requester" first]

AA18: editorial: change "implementor" to "implementer"
  e-mail sent 14 Oct 2002 11:26:03 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00160.html

  STATUS: Editorial.  Revised based on comments.

  TEXT LOCATIONS:
  1) Section 10. Conformance, 10.1 Introduction, item "1.",
     p. 78, line 3221
  2) Section 10. Conformance, 10.2 Attestation, p. 78, first
     sentence.
  3) Appendix F. Notices, first paragraph, last sentence, p. 121,
     line 4706

  TEXT CHANGE: replace "implementor" with "implementer".

  RATIONALE: Some locations in the document already use
  "implementer".  We should be consistent.  [Bill - Websters
  allows for both, but lists "implementer" first]

AA19: editorial: "interdeterminate" to "indeterminate"
  e-mail sent 14 Oct 2002 11:34:58 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00163.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section C.4 Only-one-applicable policy, 2nd
  paragraph, final word, p. 118, line 4638

  TEXT CHANGE: replace "interdeterminate" with "indeterminate"

AA20: editorial: replace "First-Appplicable" with"First-Applicable"
  e-mail sent 14 Oct 2002 11:37:56 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00165.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section C.3 First-applicable, following first
  pseudo-code block, p. 117, line 4586

  TEXT CHANGE: replace "First-Appplicable" with
  "First-Applicable"

AA21: editorial: change "URI os the" to "URI of the"
  e-mail sent 14 Oct 2002 11:42:41 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00166.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section B.6 Subject attributes, last paragraph,
  second line, p. 109, line 4270

  TEXT CHANGE: Replace "to the URI os the LDAP specification." 
  with "to the URI of the LDAP specification."

AA22: editorial: fix reference to RFC 2821 in B.4
  e-mail sent 14 Oct 2002 11:46:14 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00167.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section B.4 "Data types", paragraph starting "An
  rfc822Name...", last word, p. 108, line 4220.

  TEXT CHANGE: change 'under the term "Mailbox".Numeric' to 'under
  the term "Mailbox".'

AA23: editorial: change "the URLfrom which" to"the URL from which"
  e-mail sent 14 Oct 2002 11:50:26 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00168.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section B.2 Access subject categories, paragraph
  starting "This identifier indicates a system entity associated
  wiht a local or remove codebase", second sentence, p. 107, line
  4200.

  TEXT CHANGE: Change "the URLfrom which" to "the URL from which"

AA24: Add references for Haskel
  e-mail sent 14 Oct 2002 12:29:06 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00169.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: A.13.11 Higher-order bag functions, p.99, line
    3850
  TEXT CHANGE: add "[Haskell]" after "functional language called
    Haskell"

  TEXT LOCATION: Section 11. References, p. 84, line 3270
  TEXT CHANGE: add new entry as follows:
    [Haskell]  "Haskell, A Purely Functional Language",
    http://www.haskell.org/

AA25: editorial: A.3 add reference to [IBMSDA]"
  e-mail sent 14 Oct 2002 12:37:38 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00170.html

  STATUS: Editorial.  Vote not required.
  SEE ALSO: AA10

  TEXT LOCATION: Section A.3 Representations

  TEXT CHANGE: replace "XACML SHALL use the conversions described
  in IBM Standard Decimal Arithmetic document at the following URL:
  http://www2.hursley.ibm.com/decimal/decarith.html";; with

    "XACML SHALL use the conversions described in IBM Standard
    Decimal Arithmetic [IBMSDA]."

  RATIONALE: put the details in one place, the References section.

AA26: typo: 10.3.3 "alorithm" to "algorithm"
  e-mail sent 14 Oct 2002 12:42:05 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00171.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 10.3.3 Algorithms, entry for
  only-one-applicable-policy, p. 80, table between lines 3243 and
  3244

  TEXT CHANGE: Replace
    "urn:oasis:names:tc:xacml:1.0:policy-combining-alorithm:only-one-applicable-policy"
  with
    "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable-policy"

AA27: typo: Sun Microsystems, not Sun Micrososytems
  e-mail sent 14 Oct 2002 12:46:11 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00172.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 10.2 Attestation, p. 78, line 3231

  TEXT CHANGE: replace "Sun Micrososytems" with "Sun Microsystems"

  RATIONALE: might make people think of a certain competitor.

AA28: typo: change "adverary" to "adversary"
  e-mail sent 14 Oct 2002 12:48:43 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00173.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: 9.2.3.1 "Communication confidentiality", first
  paragraph, 4th line, p. 78, line 3140

  TEXT CHANGE: change "for an adverary to know" to "for an
  adversary to know"

AA29: typo: 7.4.1 Hierarchial resources to Hierarchicalresources
  e-mail sent 14 Oct 2002 12:51:27 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00174.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 7.4.1 Hierarchial resources, section
  title, p. 70, line 2890

  TEXT CHANGE: change "Hierarchial" with "Hierarchical"

AA30: typo: 6.11 replace "retrieveing" with "retrieving"
  e-mail sent 14 Oct 2002 12:53:59 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00175.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: 6.11 Element <Decision>, description of
  "Indeterminate", p. 66, line 2763

  TEXT CHANGE: replace "while retrieveing policies," with "while
  retrieving policies,"

AA31: typo: 6.11 replace "network errrors" with"network errors"
  e-mail sent 14 Oct 2002 12:55:46 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00176.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 6.11 Element <Decision>, paragraph
  describing "Indeterminate", p. 66, line 2763.

  TEXT CHANGE: replace "network errrors" with "network errors"

AA32: clarify use of "dn"
  e-mail sent 14 Oct 2002 12:59:38 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00177.html

  STATUS: not yet considered.

  TEXT LOCATION: Section 6.7 Element <Attribute>, description of
  "Issuer [Optional]", p. 64, line 2685

  TEXT CHANGE: replace "This MAY be a dn that binds to a public
  key" with "This MAY be an X.500 Distinguished Name that binds
  to a public key"

AA33: typo: xs:complType to xs:complexType
  e-mail sent 14 Oct 2002 13:02:18 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00178.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 6.4 Element <ResourceContent>, last line
  of schema fragment, p. 63, line 2623

  TEXT CHANGE: replace "</xs:complType>" with "</xs:complexType>"

AA34: editorial: B.3 XACML functions see Appendix A
  e-mail sent 14 Oct 2002 09:51:08 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00152.html

  STATUS: Editorial.  Vote not required.  [was 2nd AA11]

  TEXT LOCATION: Section B.3 XACML functions, second sentence,
  p. 107, line 4208.

  TEXT CHANGE: Change "See Section Introduction" to "See Appendix
  A. Standard data types, functions and their semantics."

AA35: typo: 6.2 "ulitmately" to "ultimately"
  e-mail sent 14 Oct 2002 13:04:23 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00179.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 6.2 Element <Subject>, p. 62, line 3573

  TEXT CHANGE: replace "subject is the entity ulitmately
  associated" with "subject is the entity ultimately associated"

AA36: typo: 6.1 replace "contextby" with "context by"
  e-mail sent 14 Oct 2002 13:06:19 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00180.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 6.1 Element <Request>, explanation of
  <Subject>[One to Many], p. 61, line 2536

  TEXT CHANGE: replace "Specifies information about a subject of
  the request contextby listing" with "Specifies information about
  a subject of the request context by listing"

AA37: typo: 6.1 "<Subject> elements.Each" to"<Subject> elements. Each"
  e-mail sent 14 Oct 2002 13:08:32 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00181.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 6.1 Element <Request>, 2nd paragraph, 2nd
  line at end, p. 60, line 2518

  TEXT CHANGE: replace "<Subject> elements.Each" with "<Subject>
  elements.  Each"

AA38: typo: 5.28 "<xacml-contex:" to "<xacml-context:"
  e-mail sent 14 Oct 2002 13:11:52 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00182.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 5.28 Element
  <SubjectAttributeDesignatorWhere>, end of first paragraph, p. 57,
  line 2374

  TEXT CHANGE: replace "<xacml-contex:Request>" with
  "<xacml-context:Request>"

AA39: typo: 5.7 "context.and" to "context and"
  e-mail sent 14 Oct 2002 13:22:07 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00183.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 5.7 Element <Subject>, explanation of
  <SubjectMatch>[One to Many], last paragraph, p. 47, line 1954

  TEXT CHANGE: replace "context.and" with "context and"

AA40: typo: 5.5 "conjuctive" to "conjunctive"
  e-mail sent 14 Oct 2002 13:24:25 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00184.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 5.5 Element <Target>, 2nd paragraph, first
  sentence, p. 46, line 1905

  TEXT CHANGE: replace "conjuctive" with "conjunctive"

AA41: typo: "PolicyIdReferece" to "PolicyIdReference"
  e-mail sent 14 Oct 2002 13:28:11 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00185.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 5.1 Element <PolicySet>, schema fragment,
  p. 44, line 1833

  TEXT CHANGE: replace "<xs:element ref="xacml:PolicyIdReferece"/>"
  with "<xs:element ref="xacml:PolicyIdReference"/>"

AA42: typo: change "explicitely" to "explicitly"
  e-mail sent 14 Oct 2002 13:31:38 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00186.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 4.2.4.5 Example PolicySet, last sentence,
  explanation of [43]-[60], p. 43, line 1803

  TEXT CHANGE: replace "Policy 2 is explicitely included" with
  "Policy 2 is explicitly included"

AA43: use "xs:" or "xsi:"?
  e-mail sent 14 Oct 2002 13:36:53 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00187.html

  STATUS: not yet considered.

  In some places we use "xsi:<some datatype>", while in other
  places we use "xs:<some datatype>".  We should pick one.  I
  propose "xs:" just because it is shorter.

AA44: 6.10 change "resource-uri" to "resource-id"
  e-mail sent 14 Oct 2002 13:47:15 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00188.html

  STATUS: Editorial.  Vote not required.

  TEXT LOCATION: Section 6.10 Element <Result>, explanation of
  "ResourceId [Optional]", p. 65, line 2735

  TEXT CHANGE: replace 'If this attribute is omitted, then the
  resource identity is specified by the
  "urn:oasis:names:tc:xacml:1.0:resource:resource-uri" resource
  attribute in the <Request> element.'

  with

  'If this attribute is omitted, then the resource identity is
  specified by the
  "urn:oasis:names:tc:xacml:1.0:resource:resource-id" resource
  attribute in the <Request> element.'

SP01: 18c comments.  Forwarded message from Seth Proctor.
  e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00192.html

  STATUS: Not yet considered.

  a. 3.3.2.1 (PolicyTarget) still makes it unclear that Policy Target is
    computed before arriving at the PDP. I know you're working on new
    language, so that may just not have been added yet.

    [Anne] A new "Section 7.x Target Construction" is proposed in AA06.
    This also affects HL02 "Policy Indexing".

    I suggest that all discussion of how Policy and PolicySet targets
    are computed be replaced with "See Section 7.x Target
    Construction for information about how targets may be
    constructed." and with the actual text of such a Section 7.x.

    This includes the following locations:
    1) Section 2.8 Policy indexing, p. 14-15, lines 470-480,
       beginning with "Two approaches are supported" and ending with
       "In either case, it is the policy writer's responsiblity to
       ensure that only one policy statement applies to a particular
       decision request."
    2) Section 3.3.2.1 Policy target, p. 20, lines 630-645, beginning
       with "The target may be declared by the writer of the
       policy,or..." and ending with "In this case, the targets may
       be omitted from the ocmponent rules."
    3) Section 5.1 Element <PolicySet>, p. 44, lines 1861-1863,
       beginning with "The <Target> element MAY be declared..." and
       ending with "either as an intersection or as a union."
    4) Section 5.5 Element <Target>, p. 46, following line 1908,
       just before the schema fragment and after the sentence ending
       with "...<Target> element and the corresponding section of the
       <xacml-context:Request> element."
    5) Section 5.17 Element <Policy>, p. 52, lines 2170-2172,
       replacing "The <Target> element MAY be declared by the creator
       of the <Policy> element, or it MAY be computed from the
       <Target> elements of the referenced <Rule> elements either as
       an intersection or as a union."

  b. In section 5, when the <Function> tag is explained in Apply, it
    should have a pointer to the higher-order bag section so people
    understand what it's there for

    [Anne] To be more specific, in Section 5.21 Element <Apply>,
    explanation of <Function> [Optional], p. 54, line 2260,
    following "The name of a function that is applied to the
    elements of a bag.", append: "See Section A.13.11
    Higher-order bag functions."

  c. 10.3.6 (Identifiers) doesn't list the type of any these attributes,
    nor does it give the required uses for them that it says
    implementors must follow. I realize this is transparent to a lot of
    the code, and only one of these is required to support, but it would
    still be helpful to know what type they're supposed to be (if there
    is a certain expected type). Later in the spec they're explained in
    a little more detail, but not enough to make the strong language in
    this section about correct implemention make sense.

    [Anne] I don't think there is a specified type for these.
    You specify the type using the XML Datatype="" attribute.
    One user might specify key-info, for example, using a
    SubjectKeyInfo from PKIX, while another might use a
    ds:KeyInfo structure.

  d. A.6 (Element <AttributeValue>) says that an AttributeValue's type is
    implied by the function using it, but that's changed now to state
    the type explicitly (same for next 2 sections)...actually, this
    change is missing in most of the section A examples.

    [Anne] Agreed.

  e. A.11 (Matching elements) says that the AD/AS used in a Target match
    must return a bag, and then has some other language that borders on
    describing an API. This is the section we talked about. I think it
    should be made clear that if a function expects a single String (eg),
    then getting a bag is an error. Also, this section (and the section
    later describing bags) should clarify that _any_ type is allowed in
    a bag, not just those defined as base types in the spec. If you'd
    like, I can work on alternate language.

    [Anne] Yes, please propose alternate language.

  f. B.9 (Status codes) is still missing some of the codes that we
    discussed (like problems choosing the root policy). Maybe a few more
    could be added. Maybe I should writeup a few other codes, and include
    some proposal for the format of the values to accompany various
    Status codes?

    [Anne] Yes, please write up the proposed new status codes and
    the format for their values.  To all: I think we MUST specify
    the format for the information provided with every status
    code we define.  Otherwise, we will have non-interoperable
    formats being used.

  g. D (Acknowledgments) ... this is a small issue, but since the list of
    voting memebers is basically also the contributer list, shouldn't
    this section name people who weren't on the TC but helped shape the
    standard? This is the way other specs look.

    [Anne] We put everyone who has been a member of the TC during
    the period of the development of this spec into
    "Contributors".  The Acknowledgments section will include
    only those who were voting members as of the date when we
    vote to make this document a "Committee Spec".

  h. Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of
    just AD? Before it made sense, since all ADs were the same, but I
    would think that since there's now a special AD for Subjects, that's
    what you would want to extend.

    [Simon] if we extend subj-attr-desig <-
    subject-attr-desig-where we will inherit subject-category
    attribute. Having subject-category in subject-attr-desig is
    confusing.

  i. There is still no discussion anywhere about treating the Request as a
    notional doc and going outside the PDP to get attribute values. The
    same text is still throughout the spec suggesting just the opposite,
    and the picture at the beginning looks the same. I know you're thinking
    about how to change this, but if this is really supposed to be supported,
    then the spec _must_ change dramatically to make this clear. One or
    two paragraphs added somewhere will not cut it.

    [Anne] Some of the "one or two paragraphs added somewhere"
    are in a new section proposed in PH09: "7.4.2 Attributes"
    that includes subsections on Attribute Retrieval and Missing
    Attributes.  The rest is already in the document in Section
    7.7 Use profile for XACML request.

    If more text is needed to make these sections clear, please
    propose it.

    SEE ALSO: AA45, AA46

  j. Related to that, there needs to be some clear examples of how to use an
    AD/AS to make this happen. I don't think that AS's should be used for
    this functionality (just because it's too hard to support), but that's
    a separate issue.

    [Anne] Isn't that an implementation issue?  The spec should
    just specify the desired behavior, not how it is achieved.

  k. There should probably be some language added to discuss how Policy[Set] Ids
    should be treated. At the very least, and example or some hints about
    typical use would make things better, since right now this is entirely
    up to the implementor, and as such is guarenteed to be a point where
    interoperability of policies fails.

  l. There is still no text about how to do resolution in an Apply, and how this
    can be short-circuited, etc. Are you working on this change? The
    current spec doesn't make it clear that you should be able to do this,
    so I think this needs to be added in clear examples & specification,
    otherwise not all implementors will get this right.

    [Anne] I think this is in 7.7 Use profile for XACML request.
    If not, could you be more specific about what is needed?

AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request
  e-mail sent 16 Oct 2002 14:32:00 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00195.html

  STATUS: not yet considered.
  SEE ALSO: SP01i

  TEXT LOCATION: 3.1 Data-flow model, Figure 1 - Data-flow diagram
  TEXT CHANGE: Replace diagram with:

  access requester --2. access request----> PEP --13. obligations--> obligations
                                            | ^                      service
                                            | |
                                   3. request 12. response
                                            | |
                                            | |
                                            V |
  PDP <--4. request notification---- context handler <---8. resource--> resource
                                                            content
      ---5. attribute queries------>            
   ^  <--10. attributes------------             
   |  --11. response context-------->
   |                                       |  ^    ^
   |                                       |  |    |--9. environment--> environment
   |                                       |  |          attributes
   |                                       |  |
   |                            6. attribute  7. attributes
   |                                 queries  |
  1. policy                                |  |
   |                                       |  |
   |                                       V  |
  PAP                                      PIP

  TEXT LOCATION: 3.1 Data-flow model, Steps 1-12
  TEXT CHANGE: Replace text for steps as follows:

    1. PAPs write policies and make them available to the PDP.
    2. The access requester sends a request for access to the PEP.
    3. The PEP sends the request for access to the context handler in
       its native request format, optionally including additional
       attributes of the subjects, resource and action.  The
       context handler translates the information in the native
       request into a form consistent with an XACML Request Context
       (see Section 7.7 Use profile for XACML request).
    4. The PEP notifies the PDP that a request is available for
       evaluation.
    5. Based on its initial policy (see Section 7.1 Initial
       policy), the PDP issues attribute queries to the context
       handler based on the attributes required to evaluate the
       initial policy and those policies referenced from it.
       Attribute queries are expressed in the form of
       AttributeDesignators or AttributeSelectors.
    6. The context handler may issue attribute queries to a PIP in
       order to resolve attributes not present in the native
       request.
    7. The PIP returns the requested attributes to the context
       handler.
    8. The context handler may optionally obtain information from
       the resource itself.
    9. The context handler may optionally obtain information from
       the environment.
    10. The context handler makes the requested attributes available
        to the PDP "as if" the requested attributes were located in
        a Request Context.  The PDP evaluates the policy.
    11. The PDP returns the response context (including its
        decision) to the context handler.
    12. The context handler translates the response context to the
        native response format of the PEP.  The context handler
        returns the response to the PEP.
    13. The PEP fulfills the obligations
    14. (Not shown) if access is permitted, then the PEP permits
        access to the resource; otherwise, it denies access.

  RATIONALE: Make diagram and steps consistent with respect to
  "notional" Request Context and how/when attributes are obtained.

AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request
  e-mail sent 16 Oct 2002 14:36:47 -0400 (EDT)
  http://lists.oasis-open.org/archives/xacml/200210/msg00196.html

  STATUS: not yet considered.

  TEXT LOCATION: 3.2 XACML context, last paragraph.  p. 17, line
  560.

  TEXT CHANGE: Append: "See Section 7.7 Use profile for XACML
  request for more information about how the XACML request context
  is handled."


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


Powered by eList eXpress LLC