The attached Change Requests list shows the status of all Change Requests not reflected in specification version 0.18c as of the close of our TC meeting on 17 Oct 2002. I will issue an updated list of the remaining open, non-editorial issues separately. Please review all the CRs marked "No vote required", as these were accepted without discussion. If you want to object to one, you are free to do so, but don't wait until the last minute! 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.13, 02/10/17 (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. The STATUS reflects the status following the 17 Oct TC conference call. On 10/17 we agreed to accept all "editorial" or "typo" changes, although TC members are welcome to object to any specific one prior to the final draft preparation. LEGEND ====== NQ=no quorum; official vote required Q=quorum SUMMARY ======= 0075: [Anne] AA01: Remove Table 4 - Attribute Identifiers from A.13.1 STATUS: APPROVED (10/17 Q). 0076: [Anne] AA02: New section in Appendix A on Structured datatypes STATUS: Revised text sent to list 17 Oct 2002. 0077: [Hal] HL01: Typos in 18c STATUS: Editorial. Vote not required. 0078: [Hal] HL02: Policy Indexing STATUS: APPROVED (10/17 Q). 0079: [Anne] AA03: typo: 2.10.Actions performed in conjunction with enforcement STATUS: Editorial. Vote not required. 0080: [Polar] PH01: Clarifications changes on 18c STATUS: CLOSED. Broken out into PH04-PH10, plus additions to HL02. 0081: [Polar] PH02: Review of Obligations Section 5.32 STATUS: APPROVED (10/17 Q) 0082: [Polar] PH03: Section 7.5 Authorization decision STATUS: APPROVED (10/17 Q) 0083: [Anne] AA04: 5.1 PolicySetId explanation clarification STATUS: APPROVED (10/17 Q). 0084: [Anne] AA05: editorial: PolicyCombiningAlgId reference STATUS: Editorial. Vote not required. 0085: [Anne] AA06: clarify computed <Target>s STATUS: PROVISIONALLY APPROVED (10/17 Q) with different location: 3.3.2.1 Policy target 0086: [Hal] HL03: Question about Anonymous Access Subject STATUS: REJECTED (10/17 Q). Submit specific proposals if changes needed. 0087: [Polar] PH04: 2.3 Combining algorithms, add "Only-one-applicable-policy" STATUS: APPROVED (10/17 Q). 0088: [Polar] PH05: 5.22 Element <Function>: clarify description STATUS: APPROVED (10/17 Q). 0089: [Polar] PH06: 5.23 AttributeDesignator selects collection, not set STATUS: APPROVED (10/17 Q), but using "bag" rather than "collection". 0090: [Polar] PH07: 5.29 Clarify <AttributeSelector> STATUS: APPROVED (10/17 Q), with "which is" and "XPath" changes. 0091: [Polar] PH08: 5.32 Clarify <Obligation> STATUS: APPROVED (10/17 Q). 0092: [Polar] PH09: New section 7.4.2 Attributes STATUS: APPROVED 7.4.2, 7.4.2.1 (10/17 Q) adding "or selector". 7.4.2.2 revised and OPEN. 0093: [Polar] PH10: 7.5 Clarify Authorization decision STATUS: APPROVED (10/17 Q). 0094: [Anne] AA07: point to 7.x Obligations from other places STATUS: APPROVED (10/17 Q). 0095: [Anne] AA08: specify default XPathVersion STATUS: APPROVED AS MODIFIED (10/17 Q): ELEMENT MUST BE PRESENT. 0096: [Anne] AA09: editorial: remove 10.3.1 XPathNamespace STATUS: Editorial. Vote not required. 0097: [Anne] AA10: editorial: Add reference [IBMSDA] to references STATUS: Editorial. Vote not required. 0098: [Anne] AA11: Clarify "MatchId" functions STATUS: DISCUSSED 10/17. STILL OPEN. 0099: [Anne] AA12: editorial: move B.5 Environment attributes after B.8Action attributes STATUS: Editorial. Vote not required. 0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments STATUS: Not yet considered. 0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define? STATUS: not yet considered. 0102: [Anne] AA13: Remove B.11 Identifiers used in conformance tests STATUS: not yet considered. 0103: [Anne] AA14: amended: editorial: get Piras' name right STATUS: Editorial. Vote not required. Revised to add additional location. 0104: [Anne] AA15: editorial: glossary Policy and PolicySet "componet" to "component" STATUS: Editorial. Vote not required. AA16 merged in. 0105: [Anne] AA16: editorial: Glossary Policy set "componet" to "component" STATUS: CLOSED (replaced by revised AA15) 0106: [Anne] AA17: editorial: use "Requester", not "Requestor" STATUS: Editorial. Modified based on comments. 0107: [Anne] AA18: editorial: change "implementor" to "implementer" STATUS: Editorial. Revised based on comments. 0108: [Anne] AA19: editorial: "interdeterminate" to "indeterminate" STATUS: Editorial. Vote not required. 0109: [Anne] AA20: editorial: replace "First-Appplicable" with"First-Applicable" STATUS: Editorial. Vote not required. 0110: [Anne] AA21: editorial: change "URI os the" to "URI of the" STATUS: Editorial. Vote not required. 0111: [Anne] AA22: editorial: fix reference to RFC 2821 in B.4 STATUS: Editorial. Vote not required. 0112: [Anne] AA23: editorial: change "the URLfrom which" to"the URL from which" STATUS: Editorial. Vote not required. 0113: [Anne] AA24: Add references for Haskel STATUS: Editorial. Vote not required. 0114: [Anne] AA25: editorial: A.3 add reference to [IBMSDA]" STATUS: Editorial. Vote not required. 0115: [Anne] AA26: typo: 10.3.3 "alorithm" to "algorithm" STATUS: Editorial. Vote not required. 0116: [Anne] AA27: typo: Sun Microsystems, not Sun Micrososytems STATUS: Editorial. Vote not required. 0117: [Anne] AA28: typo: change "adverary" to "adversary" STATUS: Editorial. Vote not required. 0118: [Anne] AA29: typo: 7.4.1 Hierarchial resources to Hierarchicalresources STATUS: Editorial. Vote not required. 0119: [Anne] AA30: typo: 6.11 replace "retrieveing" with "retrieving" STATUS: Editorial. Vote not required. 0120: [Anne] AA31: typo: 6.11 replace "network errrors" with"network errors" STATUS: Editorial. Vote not required. 0121: [Anne] AA32: clarify use of "dn" STATUS: not yet considered. 0122: [Anne] AA33: typo: xs:complType to xs:complexType STATUS: Editorial. Vote not required. 0123: [Anne] AA34: editorial: B.3 XACML functions see Appendix A STATUS: Editorial. Vote not required. [was 2nd AA11] 0124: [Anne] AA35: typo: 6.2 "ulitmately" to "ultimately" STATUS: Editorial. Vote not required. 0125: [Anne] AA36: typo: 6.1 replace "contextby" with "context by" STATUS: Editorial. Vote not required. 0126: [Anne] AA37: typo: 6.1 "<Subject> elements.Each" to"<Subject> elements. Each" STATUS: Editorial. Vote not required. 0127: [Anne] AA38: typo: 5.28 "<xacml-contex:" to "<xacml-context:" STATUS: Editorial. Vote not required. 0128: [Anne] AA39: typo: 5.7 "context.and" to "context and" STATUS: Editorial. Vote not required. 0129: [Anne] AA40: typo: 5.5 "conjuctive" to "conjunctive" STATUS: Editorial. Vote not required. 0130: [Anne] AA41: typo: "PolicyIdReferece" to "PolicyIdReference" STATUS: Editorial. Vote not required. 0131: [Anne] AA42: typo: change "explicitely" to "explicitly" STATUS: Editorial. Vote not required. 0132: [Anne] AA43: use "xs:" or "xsi:"? STATUS: not yet considered. 0133: [Anne] AA44: 6.10 change "resource-uri" to "resource-id" STATUS: Editorial. Vote not required. 0134: [Seth Proctor] SP01: 18c comments. Forwarded message from Seth Proctor. STATUS: Not yet considered. 0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request STATUS: not yet considered. 0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request STATUS: not yet considered. 0137: [Steve Hanna] SteveHanna02: xs:decimal string representation STATUS: not yet considered. 0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified STATUS: not yet considered. 0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero STATUS: not yet considered. 0140: [Michiharu] MK01: DataType and Namespace STATUS: not yet considered. DETAILS ======= 0075: [Anne] 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: APPROVED (10/17 Q). 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" DISCUSSION: 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. 0076: [Anne] 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 http://lists.oasis-open.org/archives/xacml/200210/msg00209.html (revised) STATUS: Revised text sent to list 17 Oct 2002. TEXT LOCATION: Section A, following "A.2 Primitive types" (p. 86, between lines 3345 and 3346 in my copy of 0.18c) REVISED TEXT CHANGE: Add following new section as follows: 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 several ways for 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 identified and treated as an instance of DataType <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. This method requires support by the PDP for the optional XPath expressions feature. 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 in "Section A.13.13 XPath-based functions". This method requires support by the PDP for the optional XPath expressions and XPath functions features. 4) For a given structured data type, a community of XACML users MAY define new attribute identifiers for each leaf sub-element of the structured data type that has a type conformant with one of the XACML-defined primitive datatypes. Using these new attribute identifiers, the PEPs or context handlers used by that community of users can flatten instances of the structured data type into a sequence of individual <Attribute>s. Each such <Attribute> can be compared using the XACML-defined functions. Using this method, the structured data type itself never appears in an <AttributeValue> element. 5) A community of XACML users MAY define a new function that can be used to compare a value of the structured datatype against some other value. This method may only be used by PDPs that support the new function. DISCUSSION: this change was originally 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 , but was never discussed. 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> .... 0077: [Hal] 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 0078: [Hal] HL02: Policy Indexing e-mail sent 11 Oct 2002 12:10:39 -0400
http://lists.oasis-open.org/archives/xacml/200210/msg00128.html STATUS: APPROVED (10/17 Q). SEE ALSO: AA06, SP01a TEXT LOCATION: Section 2.8 Policy indexing, p. 14, lines 471-545 TEXT CHANGE: [modified with Polar's text] 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: [modified with Polar's text] 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 it represents a single Policy Set with the "Only One Applicable Policy" policy combining algorithm.' DISCUSSION: 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. 0079: [Anne] 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 0080: [Polar] 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. 0081: [Polar] 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: APPROVED (10/17 Q) 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 indicate the effect for which this obligation applies." FulfillOn [required] The effect for which this obligation applies. DISCUSSION: The fulfillment of obligations is taken care of in the Chapter 7. 0082: [Polar] PH03: Section 7.5 Authorization decision e-mail sent 11 Oct 2002 14:12:05 -0400 (EDT)
http://lists.oasis-open.org/archives/xacml/200210/msg00135.html STATUS: APPROVED (10/17 Q) 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. [10/17 concall] Section 7.5 tells how the PDP arrives at its Authorization Decision, not what the PEP is supposed to do with it. We don't prohibit a PEP from sending its request to another PDP, but we don't "imply" or mandate it either. This spec merely defines the interaction between a PEP and one PDP. 0083: [Anne] 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: APPROVED (10/17 Q). TEXT LOCATION: Section 5.1 (PolicySet), explanation of PolicySetId (p. 44, lines 1845-1848 in my copy of 18c) TEXT CHANGE: [modified according to Tim's comment] 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." 0084: [Anne] 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." 0085: [Anne] 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: PROVISIONALLY APPROVED (10/17 Q) with different location: 3.3.2.1 Policy target 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 3.3.2.1 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 3.3.2.1 Target for more information about how a <Target> element may be constructed." --------------------- TEXT LOCATION: Section "3.3.2.1 Target". TEXT CHANGE: Tim to merge following text with what is already in 3.3.2.1. 3.3.2.1 Target 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. DISCUSSION: 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. [10/17 concall] This belongs in a non-normative section: 3.3.2.1 Target. We "provisionally" approved it, trusting Tim to merge the proposed text with the existing text in 3.3.2.1. Objections may be raised, however, if the merge is not correct. 0086: [Hal] 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: REJECTED (10/17 Q). Submit specific proposals if changes needed. 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. [10/17 concall] Current document does not contain any references to "anonymous". If someone thinks we need explicit text on how to deal with "anonymous" subjects, or if someone thinks we need an explicit identifier for an "anonymous" subject, then that person needs to submit a new change request with a use case, specific locations to change, and specific text to use. We may want to submit to SAML some specific values for the "authn-method" attribute, such as: "intentionally anonymous", "not authenticated", "authenticated by say so", "unknown", etc. "No subject attributes" is not equivalent to "anonymous". We agreed that it is permissible to omit all <Attribute>s from the <Subject> and it is possible to refer to such a <Subject> by using <AnySubject>. Neither of these requires any changes to the existing text or schemas. 0087: [Polar] 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: APPROVED (10/17 Q). 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. 0088: [Polar] 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: APPROVED (10/17 Q). 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 A.13.11 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." 0089: [Polar] 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: APPROVED (10/17 Q), but using "bag" rather than "collection". TEXT LOCATION: Section 5.23 Complex type AttributeDesignatorType, 2nd paragraph, first sentence, p. 55, line 2292 TEXT CHANGE: [Modified with "bag"] replace "Elements of AttributeDesignatorType type select a set of attribute values from the request context." with "Elements of AttributeDesignatorType type select a bag of attribute values from the request context." 0090: [Polar] 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: APPROVED (10/17 Q), with "which is" and "XPath" changes. TEXT LOCATION: Section 5.29 Element <AttributeSelector>, first paragraph, p. 58, lines 2410-2411 TEXT CHANGE: [With "which is" and "XPath changes] 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, which is 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." 0091: [Polar] 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: APPROVED (10/17 Q). 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." 0092: [Polar] 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: APPROVED 7.4.2, 7.4.2.1 (10/17 Q) adding "or selector". 7.4.2.2 revised and OPEN. TEXT LOCATION: Following Section 7.4.1 "Hierarchi[c]al resources", p. 70, after line 2911. TEXT CHANGE: [modified with "or selector(s)" and with Polar's revised "7.4.2.2 Missing attributes" text] 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 or selectors. Each attribute specifies an AttributeId and a DataType, and each attribute desigator specifies an AttributeId and DataType. Attribute Designators and Attribute Selectors 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 or attribute selector 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 SHALL consider an attribute as missing if it evaluates an expression that requires at least one value to be present from an attribute designator or selector. In this case, the expression evaluates to "indeterminate". The PDP may carry the missing attribute upward in its indeterminate value in accordance with the XACML evaluation strategy of the encompassing expressions, rules, policies, and policy sets. If the PDP evaluates its policy or policy set to Indeterminate with a missing attribute, the PDP MAY list the AttributeId and DataType of that attribute in the result as described in Section 7.5 "Authorization decision". However, the PDP MAY choose not to issue such information due to security concerns. 0093: [Polar] 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: APPROVED (10/17 Q). 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.' 0094: [Anne] 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: APPROVED (10/17 Q). 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." 0095: [Anne] 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: APPROVED AS MODIFIED (10/17 Q): ELEMENT MUST BE PRESENT. TEXT LOCATION: Section 5.4 Element <XPathVersion>, p. 45, lines 1896-1900 TEXT CHANGE: [With modifications from 10/17 meeting] Append: "If the policy or policy set uses any XPath expressions, then the <XPathVersion> element MUST be present." 0096: [Anne] 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. DISCUSSION: element no longer exists. 0097: [Anne] 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" ;; DISCUSSION: referenced from A.1 Introduction, but not included in 11. References. 0098: [Anne] 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: DISCUSSED 10/17. STILL OPEN. TEXT LOCATION: Section A.11 Matching elements, p. 89, lines 3446-3456. TEXT CHANGE: [Bag functions omitted per comment from Polar] 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 DISCUSSION: 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. [10/17 concall] There appear to be three points of view with respect to <Target>: 1) <Target>/<Condition> is a way to divide the evaluation into an "easy" part and a "hard" part, so that many potentially applicable policies can be easily eliminated without having to evaluate the "hard" part. The policies may be in a database, or may be explicitly included or referenced from another policy set. Target is an aid to indexing, but is not the complete way policies are indexed. [This view is reflected in this Change Request] 2) <Target> is designed to help search for the initial applicable policy in a database based on an incoming request. Any functions of the specified type (return boolean, take Designator/Selector and explicit AttributeValue as two args) that are supported by SQL and LDAP should be permitted. 3) <Target> is designed for searching an index of potential policies or rules. Only XACML standard *-equal functions should be permitted in a "MatchId". There was a Apparently, there was a vote taken on this earlier that supported 3), and Daniel was apparently strongly in favor of this. [Anne: I can not find any record of such a vote in our Change lists.] Use cases and more discussion are required to resolve this. 0099: [Anne] 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. DISCUSSION: Environment attributes follow all the Subject, Resource, and Action attributes in the Request Context. 0100: [Steve Hanna] 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. 0101: [Satoshi Hada] 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. 0102: [Anne] 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" DISCUSSION: just as for identifiers used in examples, I don't think we need to spell out the identifiers used in conformance tests. 0103: [Anne] 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" 0104: [Anne] 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" 0105: [Anne] 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) 0106: [Anne] 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" DISCUSSION: 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] 0107: [Anne] 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". DISCUSSION: Some locations in the document already use "implementer". We should be consistent. [Bill - Websters allows for both, but lists "implementer" first] 0108: [Anne] 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" 0109: [Anne] 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" 0110: [Anne] 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." 0111: [Anne] 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".' 0112: [Anne] 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" 0113: [Anne] 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/ 0114: [Anne] 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]." DISCUSSION: put the details in one place, the References section. 0115: [Anne] 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" 0116: [Anne] 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" DISCUSSION: might make people think of a certain competitor. 0117: [Anne] 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" 0118: [Anne] 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" 0119: [Anne] 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," 0120: [Anne] 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" 0121: [Anne] 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" 0122: [Anne] 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>" 0123: [Anne] 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." 0124: [Anne] 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" 0125: [Anne] 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" 0126: [Anne] 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" 0127: [Anne] 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>" 0128: [Anne] 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" 0129: [Anne] 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" 0130: [Anne] 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"/>" 0131: [Anne] 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" 0132: [Anne] 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. 0133: [Anne] 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.' 0134: [Seth Proctor] 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 &