[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated Change Requests
This is an updated list of Change Requests reflecting those still open after the 17 Oct 2002 meeting. Please read and comment on the list!!!! 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 4 Author: Anne Anderson Version: 1.1, 02/10/17 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests4.txt This file contains all non-editorial Change Requests not reflected in the v0.18c.doc version of the XACML Specification and still open after the 17 Oct 2002 TC conference call. See http://lists.oasis-open.org/archives/xacml/200210/msg00214.html for the changes previously approved to v0.18c.doc. Please review these and discuss on the list so that we are ready to quickly approve or reject on Monday, 21 Oct 2002. LEGEND ====== NQ=no quorum; official vote required Q=quorum SUMMARY ======= 0076: [Anne] AA02: New section in Appendix A on Structured datatypes STATUS: OPEN. Revised text sent to list 17 Oct 2002. 0086: [Hal] HL03: Question about Anonymous Access Subject STATUS: REJECTED (10/17 Q). Submit specific proposals if changes needed. 0092: [Polar] PH09: New section 7.4.2 Attributes STATUS: OPEN. 7.4.2.2 revised. 0098: [Anne] AA11: Clarify "MatchId" functions STATUS: DISCUSSED 10/17. STILL OPEN. 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. 0121: [Anne] AA32: clarify use of "dn" STATUS: not yet considered. 0132: [Anne] AA43: use "xs:" or "xsi:"? STATUS: not yet considered. 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. 0141: [Simon] SG[??]: data type uri's STATUS: not yet considered. DETAILS ======= 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: OPEN. 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: [Polar] I don't really like all of this. 1) I don't mind this as long as the DataType is specified in the Attribute in the Context, not as a "ds:KeyInfo" but as "xs:string". 2) This is fine. 3) This is fine as well. > 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. Anne, I'm starting to understand what your getting at, but I'm really puzzled why we need this functionality in simple Attribute Designators. How does this work? Do you have a specific example? This seems like new functionality to me. Before we had attribute identifiers that simply indexed out of the particular Subject, Action or Resource section. Do we now have to understand a attribute identifier syntax that indexes into the datatype? How can that be general and simple enough given the complexity of XPath on this issue? Also, between 4-5, I don't know what a "community of XACML users" is. I think it would be better to state just that XACML may be extended with alternate datatypes and the functions that operate on them. However, that is covered by Appendix A.13.14 Extension functions and primitive types. You just may want to say that the contents of the attribute may be an XML structure. I think I would feel more comfortable that if you are going to extend XACML, you should go the whole way in extending XACML by also creating "selector" functions for the structured type that select primitive types out of the structured datatype, such as: <Apply FunctionId="ext:get-public-key"> <Apply FunctionId="ext:keyInfo-one-and-only"> <SubectAttributeDesignatorWhere AttributeId="urn:....:key-info"> <SubjectMatch MatchId="function:string-equals"> <SubjectAttributeDesignator AttributeId="urn:...subject-category" DataType="xs:QName" /> <AttributeValue DataType="xsQName">urn:....:access-subject</AttributeValue> </SubjectMatch> </SubjectAttributeDesignatorWhere> </Apply> </Apply> where ext:keyInfo-one-and-only takes a bag of ds:KeyInfo and returns a ds:KeyInfo if and only if there is only one element in the bag, indeterminate otherwise. 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. 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 http://lists.oasis-open.org/archives/xacml/200210/msg00207.html (revised 7.4.2.2) STATUS: OPEN. 7.4.2.2 revised. TEXT LOCATION: Following Section 7.4.1 "Hierarchi[c]al resources", p. 70, after line 2911, and following the approved sections "7.4.2 Attributes" and "7.4.2.1 Attribute Retrieval" shown in DISCUSSION section below. TEXT CHANGE: Add following new section: 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. DISCUSSION: On 17 Oct 2002, we approved the following sections. Polar was asked to revise the "Missing Attributes" section that followed, and that is what is shown above. 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. 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. 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. 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" 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. 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 <Target> element MAY be declared..." and ending with "either as an intersection or as a union." 4) Section 5.5 Element <Target>, p. 46, following line 1908, just before the schema fragment and after the sentence ending with "...<Target> element and the corresponding section of the <xacml-context:Request> element." 5) Section 5.17 Element <Policy>, p. 52, lines 2170-2172, replacing "The <Target> element MAY be declared by the creator of the <Policy> element, or it MAY be computed from the <Target> elements of the referenced <Rule> elements either as an intersection or as a union." b. In section 5, when the <Function> tag is explained in Apply, it should have a pointer to the higher-order bag section so people understand what it's there for [Anne] To be more specific, in Section 5.21 Element <Apply>, explanation of <Function> [Optional], p. 54, line 2260, following "The name of a function that is applied to the elements of a bag.", append: "See Section A.13.11 Higher-order bag functions." c. 10.3.6 (Identifiers) doesn't list the type of any these attributes, nor does it give the required uses for them that it says implementors must follow. I realize this is transparent to a lot of the code, and only one of these is required to support, but it would still be helpful to know what type they're supposed to be (if there is a certain expected type). Later in the spec they're explained in a little more detail, but not enough to make the strong language in this section about correct implemention make sense. [Anne] I don't think there is a specified type for these. You specify the type using the XML Datatype="" attribute. One user might specify key-info, for example, using a SubjectKeyInfo from PKIX, while another might use a ds:KeyInfo structure. d. A.6 (Element <AttributeValue>) says that an AttributeValue's type is implied by the function using it, but that's changed now to state the type explicitly (same for next 2 sections)...actually, this change is missing in most of the section A examples. [Anne] Agreed. e. A.11 (Matching elements) says that the AD/AS used in a Target match must return a bag, and then has some other language that borders on describing an API. This is the section we talked about. I think it should be made clear that if a function expects a single String (eg), then getting a bag is an error. Also, this section (and the section later describing bags) should clarify that _any_ type is allowed in a bag, not just those defined as base types in the spec. If you'd like, I can work on alternate language. [Anne] Yes, please propose alternate language. f. B.9 (Status codes) is still missing some of the codes that we discussed (like problems choosing the root policy). Maybe a few more could be added. Maybe I should writeup a few other codes, and include some proposal for the format of the values to accompany various Status codes? [Anne] Yes, please write up the proposed new status codes and the format for their values. To all: I think we MUST specify the format for the information provided with every status code we define. Otherwise, we will have non-interoperable formats being used. g. D (Acknowledgments) ... this is a small issue, but since the list of voting memebers is basically also the contributer list, shouldn't this section name people who weren't on the TC but helped shape the standard? This is the way other specs look. [Anne] We put everyone who has been a member of the TC during the period of the development of this spec into "Contributors". The Acknowledgments section will include only those who were voting members as of the date when we vote to make this document a "Committee Spec". h. Should SubjectAttributeDesignatorWhere extend SubjectAD now instead of just AD? Before it made sense, since all ADs were the same, but I would think that since there's now a special AD for Subjects, that's what you would want to extend. [Simon] if we extend subj-attr-desig <- subject-attr-desig-where we will inherit subject-category attribute. Having subject-category in subject-attr-desig is confusing. i. There is still no discussion anywhere about treating the Request as a notional doc and going outside the PDP to get attribute values. The same text is still throughout the spec suggesting just the opposite, and the picture at the beginning looks the same. I know you're thinking about how to change this, but if this is really supposed to be supported, then the spec _must_ change dramatically to make this clear. One or two paragraphs added somewhere will not cut it. [Anne] Some of the "one or two paragraphs added somewhere" are in a new section proposed in PH09: "7.4.2 Attributes" that includes subsections on Attribute Retrieval and Missing Attributes. The rest is already in the document in Section 7.7 Use profile for XACML request. If more text is needed to make these sections clear, please propose it. SEE ALSO: AA45, AA46 j. Related to that, there needs to be some clear examples of how to use an AD/AS to make this happen. I don't think that AS's should be used for this functionality (just because it's too hard to support), but that's a separate issue. [Anne] Isn't that an implementation issue? The spec should just specify the desired behavior, not how it is achieved. k. There should probably be some language added to discuss how Policy[Set] Ids should be treated. At the very least, and example or some hints about typical use would make things better, since right now this is entirely up to the implementor, and as such is guarenteed to be a point where interoperability of policies fails. l. There is still no text about how to do resolution in an Apply, and how this can be short-circuited, etc. Are you working on this change? The current spec doesn't make it clear that you should be able to do this, so I think this needs to be added in clear examples & specification, otherwise not all implementors will get this right. [Anne] I think this is in 7.7 Use profile for XACML request. If not, could you be more specific about what is needed? 0135: [Anne] AA45: make data-flow diagram consistent with 7.7 Use profile for XACML request e-mail sent 16 Oct 2002 14:32:00 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00195.html STATUS: not yet considered. SEE ALSO: SP01i TEXT LOCATION: 3.1 Data-flow model, Figure 1 - Data-flow diagram TEXT CHANGE: Replace diagram with: access requester --2. access request----> PEP --13. obligations--> obligations | ^ service | | 3. request 12. response | | | | V | PDP <--4. request notification---- context handler <---8. resource--> resource content ---5. attribute queries------> ^ <--10. attributes------------ | --11. response context--------> | | ^ ^ | | | |--9. environment--> environment | | | attributes | | | | 6. attribute 7. attributes | queries | 1. policy | | | | | | V | PAP PIP TEXT LOCATION: 3.1 Data-flow model, Steps 1-12 TEXT CHANGE: Replace text for steps as follows: 1. PAPs write policies and make them available to the PDP. 2. The access requester sends a request for access to the PEP. 3. The PEP sends the request for access to the context handler in its native request format, optionally including additional attributes of the subjects, resource and action. The context handler translates the information in the native request into a form consistent with an XACML Request Context (see Section 7.7 Use profile for XACML request). 4. The PEP notifies the PDP that a request is available for evaluation. 5. Based on its initial policy (see Section 7.1 Initial policy), the PDP issues attribute queries to the context handler based on the attributes required to evaluate the initial policy and those policies referenced from it. Attribute queries are expressed in the form of AttributeDesignators or AttributeSelectors. 6. The context handler may issue attribute queries to a PIP in order to resolve attributes not present in the native request. 7. The PIP returns the requested attributes to the context handler. 8. The context handler may optionally obtain information from the resource itself. 9. The context handler may optionally obtain information from the environment. 10. The context handler makes the requested attributes available to the PDP "as if" the requested attributes were located in a Request Context. The PDP evaluates the policy. 11. The PDP returns the response context (including its decision) to the context handler. 12. The context handler translates the response context to the native response format of the PEP. The context handler returns the response to the PEP. 13. The PEP fulfills the obligations 14. (Not shown) if access is permitted, then the PEP permits access to the resource; otherwise, it denies access. DISCUSSION: Make diagram and steps consistent with respect to "notional" Request Context and how/when attributes are obtained. 0136: [Anne] AA46: Make 3.2 XACML context consistent with 7.7 Use profile for XACML request e-mail sent 16 Oct 2002 14:36:47 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00196.html STATUS: not yet considered. TEXT LOCATION: 3.2 XACML context, last paragraph. p. 17, line 560. TEXT CHANGE: Append: "See Section 7.7 Use profile for XACML request for more information about how the XACML request context is handled." 0137: [Steve Hanna] SteveHanna02: xs:decimal string representation e-mail sent 16 Oct 2002 14:45:39 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00198.html STATUS: not yet considered. Section A.3 Representations says: For integers and decimals, XACML SHALL use the conversions described in IBM Standard Decimal Arithmetic document at the following URL: http://www2.hursley.ibm.com/decimal/decarith.html This document combines the various standards set forth by IEEE and ANSI for string representation of numeric values. The IBM document defines a numeric string syntax that allows scientific notation, NaNs, and infinities. The XML schema document that defines the permissible contents of the xs:decimal data type does not allow any of these. I suggest that a note be added after the above passage, saying: Note that although the IBM document allows exponents, NaNs, and infinities the XML Schema specification does not allow these in an xs:integer and xs:decimal value. Therefore, they MUST NOT be used in such values. 0138: [Steve Hanna] SteveHanna03: Use of decimal math should be justified e-mail sent 16 Oct 2002 14:45:44 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00199.html STATUS: not yet considered. It is unusual to specify the use of decimal math in a specification like XACML, especially requiring strict conformance to a detailed specification of decimal math behavior. Many platforms do not support decimal math. Binary math is much more common. I can see why you might want to use decimal math for this specification. Maybe you're likely to be doing a lot of financial calculations. Still, I think it's a bit odd that you require support for exponents, NaNs, and the like in the implementation but don't provide any way for a user to access these features. A simpler approach would have been to leave the arithmetic loosely specified, like XQuery has done. At the least, I think you should add a few sentences to the end of section A.12 Arithmetic evaluation saying Decimal arithmetic is used in order to provide results that closely match those expected by the average user. 0139: [Steve Hanna] SteveHanna04: handling of divide-by-zero mail sent 16 Oct 2002 14:45:48 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00188.html STATUS: not yet considered. Section A.12 Arithmetic evaluation says that trap-enablers SHALL all be set to 0. I believe that this means that a division by zero will produce a result of positive or negative infinity and proceed along happily. That seems surprising and contradicts sections 6.11 and B.9, which imply that a division by zero will produce an indeterminate result. I suggest that you change section A.12 to say that all trap-enablers SHALL be set to 0 except division-by-zero, which SHALL be set to 1. Then you can change the description of the integer-divide and decimal-divide functions in section A.13.2 to say that they SHALL produce a result of indeterminate with a processing-error status if the divisor is 0. 0140: [Michiharu] MK01: DataType and Namespace e-mail sent 17 Oct 2002 18:47:58 +0900 http://lists.oasis-open.org/archives/xacml/200210/msg00202.html STATUS: not yet considered. We have agreed to specify DataType attribute in both policy and context. The schema 16j says that DataType attribute is xs:anyURI. I think that the DataType is written as QName such as "xs:string" and "xs:boolean" like MatchId attribute. So I request to change DataType attribute from xs:anyURI to xs:QName. Besides, we should add the following namespace prefix and its namespace URI in the spec. Prefix Namespace URI xacml-function urn:oasis:names:tc:xacml:1.0:function xacml-datatype urn:oasis:names:tc:xacml:1.0:datatype *) datatype prefix is used for xacml-datatype:x500Name and xacml-datatype:rfc822Name. In fact, prefix itself matters only in the specification document. Policy writers can choose another prefix as they like. I think text that refers to ds: prefix (XML Signature namespace) and saml: prefix no longer exist in the spec. So line 289-290, 303-305 should be deleted. 0141: [Simon] SG[??]: data type uri's e-mail sent 17 Oct 2002 09:50:15 -0700 http://lists.oasis-open.org/archives/xacml/200210/msg00208.html STATUS: not yet considered. XML-schema datatype namespace: http://www.w3.org/2001/XMLSchema-datatypes Xml data types: http://www.w3.org/2001/XMLSchema-datatypes#string http://www.w3.org/2001/XMLSchema-datatypes#boolean http://www.w3.org/2001/XMLSchema-datatypes#integer http://www.w3.org/2001/XMLSchema-datatypes#decimal http://www.w3.org/2001/XMLSchema-datatypes#date http://www.w3.org/2001/XMLSchema-datatypes#dateTime http://www.w3.org/2001/XMLSchema-datatypes#anyURI http://www.w3.org/2001/XMLSchema-datatypes#hexBinary http://www.w3.org/2001/XMLSchema-datatypes#base64Binary Xquery operators datatype namespace: http://www.w3.org/TR/xquery-operators Xquery data types: http://www.w3.org/TR/xquery-operators#dayTimeDuration http://www.w3.org/TR/xquery-operators#yearMonthDuration Xacml datatype namespace: urn:oasis:names:tc:xacml:1.0:datatype Xacml data types: urn:oasis:names:tc:xacml:1.0:datatype:x500Name urn:oasis:names:tc:xacml:1.0:datatype:rfc822Name Changes: A2. Primitive types. replace datatype list with the above list. B4. Data types replace data-type identifiers with the above list
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC