[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated Change Requests
The attachment contains the Change Requests against v17.doc after today's subcommittee call. The text of the requests includes the specific language recommended. 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 2 Author: Anne Anderson Version: 1.4, 02/09/30 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests2.txt This version contains all Change Requests not reflected in v17.0 of the specification (i.e. received after the TC meeting on 26 Sept 2002. For earlier Change Requests (all disposed of by 26 Sept 2002) see the following e-mail in the archive: http://lists.oasis-open.org/archives/xacml/200209/msg00185.html or reference the mail titled "[xacml] Updated Change Request list", from Anne Anderson, 26 Sep 2002. Contains all e-mail up to and including archive msg msg00203.html ACTION ITEMS ============ None LEGEND ====== NQ=no quorum; official vote required Q=quorum SUMMARY ======= 0064. [Michiharu] <AttributeSelector> Text change request STATUS: APPROVED (Q 9/26) New text APPROVED (NQ 9/30) 0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13 STATUS: APPROVED (NQ 9/30) with addition of footnote text. 0066. [Simon] change request: namespaces in xpath expressions STATUS: APPROVED (NQ 9/30). Both proposals 1. and 2. approved. 0067. [Simon] change request: resource content STATUS: APPROVED (NQ 9/30). Proposal 1 only. 0068. [Simon] change request: subject-attribute-designator and subjectcategory STATUS: Discussed 9/30. No resolution. Anne in favor. 0069. [Simon] change request: xacml context attributes and data types STATUS: Discussed 9/30. See [9/30] below. Feedback requested. 0070. [Michiharu] resource:scope attribute missing STATUS: APPROVED (NQ 9/30) 0071. [Simon] Appendix B needs text describing syntax of x500Name,rfc822Name STATUS: APPROVED (NQ 9/30) DETAILS ======= 0064. [Michiharu] <AttributeSelector> Text change request http://lists.oasis-open.org/archives/xacml/200209/msg00179.html STATUS: APPROVED (Q 9/26) New text APPROVED (NQ 9/30) AttributeSelector, Page 49 <AttributeSelector> [required] MAY be used to identify one or more values in the <Subject> element of <xacml-context:Request> element. It MUST contain a legal xpath expression over the <Subject> element of the <xacml-context:Request> element. ==> <AttributeSelector> [optional] Attribute selector using XPath expression. It MUST contain a legal xpath expression over the <xacml-context:Request> element. This operator returns a bag of string data or a single primitive value. In case of XPath 1.0, an evaluation value of the XPath expression is either a node set, string value, numeric value, and boolean value. When node set is returned, each node may consist of children nodes (structured node). Then each node is converted into a string data by applying a string function defined in XPath 1.0 specification. Then this operator returns a bag of string values. When either string, numeric or boolean value is returned, this operator returns a single primitive value of xs:string, xs:decimal, and xs:boolean type, respectively. When this element is specified, the policy MUST define the version of the XPath specification using <XPathVersion> element. When an xpath expression has one or more namespace prefix, they are resolved using XPath namespace and prefix information specified in the <XPathNamespace> element below this operator. If no such element is specified, then an <XPathNamespace> element in <PolicyDefaults> element in the parent <Policy> (or <PolicySet>) element is used. [Polar] <AttributeSelector> AttributeSelector using an XPATH expression. The AttributeSelector's "RequestContextPath" XML attribute shall contain a legal XPATH expression over the <xacml-context:Request> element. The selector element evaluates to a bag of a single primitive value that is implied by the type system, i.e. the function application in which the selector appears. In case of using XPATH 1.0, the value of the XPATH expression is either a node-set, string value, numeric value, or boolean value. If the XPATH 1.0 expression evaluates to a node-set, each node may consist of a string, numeric, boolean value, or a child node (ie. structured node). In this case, each node is logically converted to string data by applying the "string" function defined in XPATH 1.0 specification resulting a sequence of string data. In the single string, numeric, or boolean value case, the value is converted to string data by applying the string function defined in XPATH 1.0 specification resulting in a sequence of one string data element. In XPATH 2.0, the result of the XPATH expression is always a sequence of nodes. In this case, each node is logically converted to a string using the aforementioned string function resulting in a sequence of string data. The resulting sequence of string data is converted to a bag of primitive values that is implied by the type system. [Polar, quoting Michiharu] > The sentence you provide is basically fine. > > [1] > in XPATH 1.0 specification resulting in a sequence of one > string data element. > ==> > in XPATH 1.0 specification resulting in a bag of one string > data element. Actually, I used "sequence" to unify both the XPATH 1.0 and 2.0 descriptions. Then logically convert the "sequence of string data" to a bag of primitive values. > > [2] > Since XPath 2.0 returns either a sequence or the error > value, we should say that "the result of the XPATH > expression is a sequence of items (item is an atomic value > or a node) or the error value. When the error value is > returned, the PDP SHOULD return Indeterminate." OKay. [Michiharu] OK. In case of XPath 2.0, "xf:string accessor" is better than "aforementioned string function". [New Text approved 9/30/02] <AttributeSelector> AttributeSelector using an XPATH expression. The AttributeSelector's "RequestContextPath" XML attribute shall contain a legal XPATH expression over the <xacml-context:Request> element. The selector element evaluates to a bag of a single primitive value that is implied by the type system, i.e. the function application in which the selector appears. In the case of using XPATH 1.0, the value of the XPATH expression is either a node-set, string value, numeric value, or boolean value. If the XPATH 1.0 expression evaluates to a node-set, each node may consist of a string, numeric, boolean value, or a child node (ie. structured node). In this case, each node is logically converted to string data by applying the "string" function defined in the XPATH 1.0 specification, resulting a sequence of string data. In the single string, numeric, or boolean value case, the value is converted to string data by applying the "string" function defined in the XPATH 1.0 specification, resulting in a sequence of one string data element. In XPATH 2.0, the result of the XPATH expression is a sequence of items (where an item is an atomic value or a node) or the error value. When the error value is returned, the PDP SHOULD return "Indeterminate". Otherwise, each node is logically converted to a string using the xf:string accessor function, resulting in a sequence of string data. The resulting sequence of string data is converted to a bag of primitive values that is implied by the type system. 0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13 http://lists.oasis-open.org/archives/xacml/200209/msg00186.html STATUS: APPROVED (NQ 9/30) with addition of footnote text. The descriptions for the functions x500Name-equal and x500Name-match in XACML_Functions.doc v13 are mixed up. In particular, the "x500Name-match" description is actually the "x500Name-equal" description. Here are the correct descriptions: o x500Name-equal This function shall take two arguments of "xacml:x500Name" and shall return an "xs:boolean". It shall return true if and only if each Relative Distinguished Name (RDN) in the two arguments matches. Two RDNs match if and only if the result of the following operations is true.[*] First, normalize the two arguments according to IETF RFC 2253 "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names". Second, if any RDN contains multiple attributeTypeAndValue pairs, re-order the Attribute ValuePairs in that RDN in ascending order when compared as octet strings (described in ITU-T Rec. X.690 (1997 E) Section 11.6 "Set-of components"). Finally, compare RDNs using the rules in IETF RFC 3280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) PRofile", Section 4.2.1.4 "Issuer". [*] ITU-T Rec. X.520 contains rules for matching X500 names, but these are very complex and require knowledge of the syntax of various AttributeTypes. IETF RFC 3280 contains simplified matching rules that the XACML x500Name-equal function uses. o x500Name-match This function shall take two arguments of "xacml:x500Name" and shall return an "xs:boolean". It shall return true if and only the first argument matches some terminal sequence of RDNs from the second argument when compared using x500Name-equal. 0066. [Simon] change request: namespaces in xpath expressions http://lists.oasis-open.org/archives/xacml/200209/msg00190.html STATUS: APPROVED (NQ 9/30). Both proposals 1. and 2. approved. There are several instances in the policy schema where we pass xpath expressions as arguments. 1. In the case of <xacml:AttributeSelector> element RequestContextPath attribute contains xpath expression that selects xacml attribute value from the context. 2. When xpath functions are used in the target, the value to match again is xpath expression. 3. When xpath functions are used in conditions they take xpath expressions as arguments. All examples are from section 4.2 For the attribute-selector we use XPathNamespace element that maps namespace uri to namespace prefix (essentially duplicating standard xml namespace declaration) AttributeSelector: <AttributeSelector RequestContextPath= "//ctx:RequestContext/md:record/md:patient/md:policyNumber"> <XPathNamespace NamespaceURI="urn:names:tc:xacml:1.0:context" Prefix="ctx"/> <XPathNamespace NamespaceURI="http://www.medico.com/schemas/record.xsd" Prefix="md"/> </AttributeSelector> For other uses of xpath functions we do not have special provisions for namespace mapping. Here is how xpath expression is used in the target to match request: <ResourceMatch matchId="function:xpath-match"> <ResourceAttributeDesignator AttributeId= "urn:oasis:names:tc:xacml:1.0:resource:xpath"/> <AttributeValue>/md:record</AttributeValue> </ResourceMatch> In this case we rely on standard xml namespace declaration for the md prefix. To summarise: we use two methods to deal with the same problem: one is standard and one is not. Proposal: 1. Use standard xml namespace declarations mechanism in both cases and drop <XPathNamespace> element. 2. Change RequestContextType attribute of AttributeSelector to xs:string (it is currently xs:anyURI). [Michiharu] I understand your intention but I am not sure whether or not using standard XML namespace (your first proposal) is really good for our case. My opinion is that standard XML namespace (you mean xmlns:md ="http://www.... record.xsd", right?) should primarily mean the namespace for element name of the policy itself. In other words, XACML policy may include other namespace (currently seems not but actually we had when SAML schema fragment was used in our policy). I think xmlns should be used for that case. Since we need to determine the namespace for the value of the policy (not element name nor attribute name), it seems reasonable to use application-specific namespace designator (XPathNamespace) currently we have. How do you think? [Simon] You are correct, xmlns decl is used for elements and we have data. Our first problem is that we do not cover all cases with XPathNamespace element. Also, declaring XPathNamespace in the PolicyDefaults is equivalent in my opinion to declare namespace prefix on the Policy itself. So I'd like to use xmlns decl, although it's usage is applied to data. 0067. [Simon] change request: resource content http://lists.oasis-open.org/archives/xacml/200209/msg00191.html STATUS: APPROVED (NQ 9/30). Proposal 1 only. <xacml-context:Resource> element has <xacml-context:ResourceContent> child. If resource content is relevant in access decision it is placed as a child of <ResourceContent> element. Currently, the only way to access <ResourceContent> and it's children elements is with <xacml:AttributeSelector>, support for which is optional. There is no way to access this data with <xacml:ResourceAttributeDesignator>. Proposal 1: Introduce resource attribute identifier: "urn:oasis:names:tc:xacml:1.0:resource:resource-content" that will address <ResourceContent> element. In this case, both <ResourceContent> and identifier refer to the same entity. No schema change required. Proposal 2: Drop <ResourceContent> element and introduce resource identifier as above. The xpath expressions in the <xacml:AttributeSelector> will be taken over this resource attribute: <AttributeSelector RequestContextPath= "//ctx:Request/ctx:Resource/ ctx:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:resource:resource-content']/*"/> In both cases (1) and (2) we can access content with resource-attribute-designator: <ResourceAttributeDesignator AttributeId="urn:oasis:names:xacml:1.0:resource:resource-content"/> [Michiharu] I am ok with your first proposal but I am not clear on the second one. The intention of having a ResourceContent element in XACML Request Context is that it must allow any arbitrary XML fragment below ResourceContent element. That's why the schema allows any structure. If you remove the ResourceContent and place the arbitrary XML fragment below Attribute element instead, you will need another changes on schema, for example to allow any elements below Attribute element or to introduce a new elements like ResourceContent. [Simon] Ok, than we can declare an attribute identifier that will point to the content (alt 1). 0068. [Simon] change request: subject-attribute-designator and subjectcategory http://lists.oasis-open.org/archives/xacml/200209/msg00192.html STATUS: Discussed 9/30. No resolution. Anne in favor. xacml request context supports multiple <xacml-context:Subject> elements. Each <xacml-context:Subject> element is tagged with the subject-category, such as: access-subject, codesource, etc. Subject category name is unique, ie there is no two <xacml-context:Subject> elements in the request context with the same value of subject-category attribute. <xacml:Subject> element in the policy allows us to specify multiple subject matches at the same time: sm1 'and' sm2 'and' sm3 etc. Syntactically, context subject attribute is selected with <xacml:SubjectAttributeDesignator> element that names attribute-id and issuer. Very often all subject attributes must be selected from the same subject block. Proposal: Extend <xacml:SubjectAttributeDesignator> with optional SubjectCategory attribute: <xs:complexType name="SubjectAttributeDesignatorType"> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> <xs:attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new attribute </xs:complexType> [Polar] I thought the purpose of the SubjectAttributeDesignatorWhere was to get all matches from the same subject, of which subject-category was one of the attributes you match on. I think we worked this out quite well, and cuts down on the machinery needed to just select mere attributes from a subject. [9/30 discussion] Polar's objection does not apply to Simon's case, since SubjectAttributeDesignatorWhere can not be used in a Target. Anne is in favor of Simon's proposal, but the group feels more input is needed. 0069. [Simon] change request: xacml context attributes and data types http://lists.oasis-open.org/archives/xacml/200209/msg00193.html STATUS: Discussed 9/30. See [9/30] below. Feedback requested. Currently <xacml-context:Attribute> element allows DataType attribute. Rationale for keeping DataType attribute in the <xacml-context:Attribute> element was that it can sometimes be helpful, such as specifiying subject-id format, like subject-id="cn=simon", data-type="x500-name" But this information is redundant, because subject-id attribute will be passed to the specific function that expects arguments of certain type. For example, if subject-id is passed to the x500Name-equal function it expects it's arguments to be in x500 name format. So data type does not add value here. Another problem is that we can not access DataType attribute with AttributeDesignator. Proposal: remove DataType attribute from the <xacml-context:Attribute>. [Anne] But, as discussed on yesterday's call, a <Subject> may have more than one subject-id attribute. For example, one may give the rfc822Name under which the subject authenticated, and another may give the x500Name. The datatype is required to allow the AttributeDesignator to select the instance of the attribute that has the correct datatype for the function in which the designator occurs. [Polar] I agree with removing the dataType attribute from the xacml-context:Attribute. However, the implications are this: If you have an Attribute of "subject-id" and its value is: <AttributeValue>CN=Simon Godik, O=OverXeer, OU=Research</AttributeValue> What does the designator: <SubjectMatch MatchId="function:rfc822Name-equal"> <SubjectAttributeDesignator AttributeId="subject-id"/> <AttributeValue>simon@godik.com</AttributeValue> </SubjectMatch> evaluate to? Does it evaluate to "indeterminate" because the formal type of rfc822Name-equal is xacml:rfc822Name -> xacml:rfc822Name -> Bool and the attribute value is an invalid representation of an rfc822Name. Or does it evaluate to "false"? The question in the context of its application, the <SubjectAttributeDesignator Attribute="subject-id"> shall return a bag of "rfc822Name", which means that every "subject-id" attribute must have a parseable rfc822Name representation as a value. So, does the designator return "indeterminate" because not *all* values under "subject-id" are valid string representations of rfc822Name? Or does it return a bag of rfc822Names of *only* the values under "subject-id" that do have valid string representations of rfc822Names? In the example above for the latter case, this designator would return an empty bag. [Polar, responding to Anne] Right, if the dataType attribute exists, if you are looking for attributes of a particular datatype, of which our XACML strong type system will infer, you can pick them out of the context by the dataType attribute. It can be optional, however, as I pointed out in my last email, you have to decide on what to do with the designator if the AttributeValue isn't a valid parseable representation of the data type named in the dataType attribute. [Bill] i suggest that this has to evaluate to FALSE. INDETERMINATE implies that the value is out of scope of the data set. while it may be argued that this is true at the philosophical level, i don't think it is consistent with how we are handling similar issues--what happens if a PEP requests to 'toad the wet sprocket' (resource unknown, action unknown)? this is consistent with my current assumptions that these values will be evaluated as [right-to-left] string comparisons. if that isn't the case, then i would like to hear the reasoning for requiring the logic necessary to differentiate between the two at evaluation time (explicit vs. implicit run-time type validation) [Simon, responding to Anne] If this is the case we should extend attribute designator to specify data type of the attribute to be selected. [9/30] In the meeting on 9/30, the following issues were outlined: 1. Need to be able to select attributes based on datatype. Example: Policy writer wants to indicate "This policy applies to all requests containing a <Subject> that has an x500Name of "cn=Anne, o=Sun, c=US". The policy Target using the 16i schema would contain: <Subjects> <Subject> <SubjectMatch MatchId="function:x500Name-equal"> <SubjectAttributeDesignator AttributeId="subject:subject-category"/> <AttributeValue>cn=Anne, o=Sun, c=US</AttributeValue> </SubjectMatch> </Subject> </Subjects> But, assume a given <Subject> has authenticated with both an rfc822Name and an x500Name. Then the Request will look as follows: <Subject> <Attribute AttributeId="subject:subject-category" DataType="x500Name"> <AttributeValue>cn=Anne, o=Sun, c=US</AttributeValue> </Attribute> <Attribute AttributeId="subject:subject-category" DataType="rfc822Name"> <AttributeValue>anne@Sun.COM</AttributeValue> </Attribute> </Subject> The policy should be applicable to this Request (I think), but the SubjectAttributeDesignator will match both Attributes in the Request, and one of them will be of type "rfc822Name". Not only will the result be a bag (which can't be passed to x500Name-equal), but there will be a conversion error in attempting to convert the rfc822Name to an x500Name. 2. Where are values converted to internal representations that are typed? Does this occur when the - Context AttributeValue is parsed? - AttributeDesignator is parsed? - SubjectMatch MatchId function is evaluated? We need feedback from people who are doing actual implementations on this. 3. We agreed that, if a function is passed a value that is the wrong type, that the result is "Indeterminate", NOT "False". So we need a way for the policy writer to select only the values that are (at least are intended to be) of the right type. 4. We all agreed that the PDP can not rely on the PEP or the PAP to specify correct datatypes for values. But a datatype specification could be used to indicate intent. 0070. [Michiharu] resource:scope attribute missing STATUS: APPROVED (NQ 9/30) The <prefix>:resource:scope attribute and its values, as described in 7.2 Hierarchical resources, is not included in Appendix B or in the Conformance Section. These should be included. [Appendix B: add to list:] This identifier indicates the scope of the resource, as described in Section 7.2 Hierarchical resources. urn:oasis:names:tc:xacml:1.0:resource:scope The allowed value for this attribute is of type xs:string, and is either "Immediate", "Children", or "Descendants". [Conformance Section, Attributes, add to list] urn:oasis:names:tc:xacml:1.0:resource:scope O 0071. [Simon] Appendix B needs text describing syntax of x500Name,rfc822Name STATUS: APPROVED (NQ 9/30) [Section B, DataTypes, add after] urn:oasis:names:tc:xacml:1.0:datatype:x500Name An x500Name contains an ITU-T Rec. X.520 Distinguished Name. The valid syntax for such a name is described in IETF RFC 2253 "Lightweight Directory Access Protocol(v3): UTF-8 String Representation of Distinguished Names". urn:oasis:names:tc:xacml:1.0:datatype:rfc822Name An rfc822Name contains an "e-mail name". The valid syntax for such a name is described in IETF RFC 2821, Section 4.1.2 Command Argument Syntax, under the term "Mailbox".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC