xacml — archive

[Anne Anderson <anne.anderson@sun.com>]

This list is unfortunately not complete. I did not have time to include all the change requests submitted. -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.4, 02/10/14 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests3.txt This version contains all Change Requests not reflected in the v0.18c.doc version of the XACML Specification. This file reflects all unresolved e-mail between archive msg00.html and msg msg00203.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 HL02: Policy Indexing STATUS: not yet considered. AA03: typo: 2.10.Actions performed in conjunction with enforcement STATUS: editorial. PH01: Clarifications changes on 18c STATUS: not yet considered 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: not yet considered. AA05: editorial: PolicyCombiningAlgId reference STATUS: editorial. AA06: clarify computed <Target>s 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: RE: [xacml] AA02: New section in Appendix A on Structured datatypes > 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 Line 309 Non-mormative --> Non-normative Line 2474 Distingwished --> Distinguished HL02: Policy Indexing e-mail sent 11 Oct 2002 12:10:39 -0400 STATUS: not yet considered. 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) STATUS: editorial. 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) 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) 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) 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. AA04: 5.1 PolicySetId explanation clarification e-mail sent 11 Oct 2002 15:56:51 -0400 (EDT) STATUS: not yet considered. 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 "The party assigning the identifier MUST minimize the potential of some other party re-using the same identifier within the scope of the PDPs that may use or reference that identifier." Rationale: "How unique does it have to be, Anne?" "As unique as necessary, Joe." [Tim] Anne - I was definitely uncomfortable with the original wording. But, even your improvement leaves unnecessary room for misunderstanding. Why not clearly state that it is the PAP's responsibility to ensure that no two policies visible to a PDP have the same identifier? So, instead of "minimize the potential", why not say "eliminate the possibility"? In practice, PDPs SHALL only accept policies from PAPs that agree to conform to a disjoint identifier assignment scheme and PAPs MUST adhere to their declared scheme. Yes/No? [Anne] This is fine with me. AA05: editorial: PolicyCombiningAlgId reference e-mail sent 11 Oct 2002 16:01:00 -0400 (EDT) STATUS: editorial. 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." Rationale: word processor mis-reference. AA06: clarify computed <Target>s e-mail sent 11 Oct 2002 16:36:51 -0400 (EDT) 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.