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