xacml — archive

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

For use in our meeting tomorrow. I have stripped out a lot of old "DISCUSSION", and tried to identify better exactly what RESOLUTION we might be voting on. 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.14, 02/10/30 (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. Includes e-mail up through http://lists.oasis-open.org/archives/xacml/200210/msg00306.html See http://lists.oasis-open.org/archives/xacml/200210/msg00214.html for the changes previously approved to v0.18c.doc. ACTION ITEMS ============ 0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor. ACTION ITEM: [Seth Proctor] Write up details for missing-attribute. 0147: [Seth Proctor] Bug in pseudocode for Only One Applicable. ACTION ITEM: [Polar] Reword. SUMMARY OF ITEMS STILL NOT COMPLETELY RESOLVED ============================================== LEGEND ====== NQ=no quorum; official vote required Q=quorum NEED OFFICIAL VOTE ONLY ======================= 0076: [Anne] AA02: New section in Appendix A on Structured datatypes STATUS: NEED FINAL VOTE (NQ 10/21). See RESOLUTION. 0092: [Polar] PH09: New section 7.4.2 Attributes STATUS: 7.4.2 APPROVED (NQ 10/17). NEED FINAL VOTE. See RESOLUTION. 0098: [Anne] AA11: Clarify "MatchId" functions STATUS: ACCEPTED (NQ 10/28). See RESOLUTION. 0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define? STATUS: REJECTED (NQ 10/28). Use URI for everything. SEE ALSO: CR#0140,0141 0134a: [Seth Proctor] Policy Target computed before arriving at PDP STATUS: REJECTED (NQ 10/28). No change. 0140: [Michiharu] MK01: DataType and Namespace STATUS: REJECTED (NQ 10/28). Use URI for everything. SEE ALSO: CR#0101,0132,0141 0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor. STATUS: status:ok APPROVED (NQ 10/28). See RESOLUTION STATUS: status:syntax-error APPROVED (NQ 10/28). See RESOLUTION. STATUS: status:processing-error APPROVED (NQ 10/28). See RESOLUTION. 0144: [Polar] harmful to interoperability STATUS: APPROVED (NQ 10/28). See RESOLUTION. 0145: [Seth Proctor] Multi-valued attributes in Request. STATUS: APPROVED (NQ 10/28) Change to maxOccurs=1. 0147: [Seth Proctor] Bug in pseudocode for Only One Applicable. STATUS: APPROVED (NQ 10/28). Polar will reword. STILL NEED REVIEW AND ACTION ============================ 0092: [Polar] PH09: New section 7.4.2 Attributes STATUS: 7.4.2.1: two proposals. #2 not yet considered. See RESOLUTION. STATUS: 7.4.2.2: new version not yet considered. See RESOLUTION. 0134c: [Seth Proctor] Need Datatypes for each defined AttributeId STATUS: Need vote on Simon's proposal. See RESOLUTION. 0141: [Simon] SG[??]: data type uri's STATUS: Need decision on URL vs. URN (10/28). See RESOLUTION. 0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor. STATUS: Vote on RESOLUTION needed (10/28). 0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor. STATUS: status:missing-attribute (10/28). Waiting on Seth to provide details. 0146: [Polar] CR 144: function "present" needs to be fixed. STATUS: Need vote on new RESOLUTION (NQ 10/28). Resolve ISSUES. 0148a: [Yassir Elley] Example two rules not applicable to request STATUS: Vote on RESOLUTION in http://lists.oasis-open.org/archives/xacml/200210/msg00301.html 0148b: [Yassir Elley] Include target-namespace in Request Context? STATUS: Vote on RESOLUTION in http://lists.oasis-open.org/archives/xacml/200210/msg00301.html 0148c: [Yassir Elley] Syntax of RequestContextPath not consistent STATUS: Vote on RESOLUTION in http://lists.oasis-open.org/archives/xacml/200210/msg00301.html 0148d: [Yassir Elley] Move "disjunctive sequence" up to higher element description STATUS: Vote on RESOLUTION in http://lists.oasis-open.org/archives/xacml/200210/msg00301.html 0149: [Seth Proctor] Environment attributes STATUS: Vote needed on RESOLUTION (10/28). 0152: [Tim Moses] Trivial Matter STATUS: Not yet considered. 0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy STATUS: Not yet considered. 0154: [Seth Proctor] Problem in SubjectQualifier/SubjectAttributeDesignatorWhere STATUS: Not yet considered. 0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere 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: NEED FINAL VOTE (NQ 10/21). See RESOLUTION. RESOLUTION: 10/21 meeting reached tentative resolution, but it involves enough of a change that members need to see the RESOLUTION SPECIFIC TEXT before voting. RESOLUTION SPECIFIC TEXT: TEXT LOCATION: Section A, following "A.2 Primitive types" (p. 86, between lines 3345 and 3346 in my copy of 0.18c) 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>. Structured data types MAY be structured XML data or MAY use other encodings, such as DER-encoded ASN.1. 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-defined functions,such as regexp-string-match or hexBinary-equal, described below. In this case, the structured data, including its tags and attributes, SHALL use the DataType corresponding to the function to be used, both in the Policy AttributeDesignators and Selectors and in the Request Attribute. 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 an XML 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 an XML 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. See Section 8. XACML extensibility points for further ways in which structured data types may be handled. TEXT LOCATION: 8. XACML extensibility points TEXT CHANGE: Add following new section: 8.3 Structured data types Section "A.3 Structured types" describes normative ways of dealing with structured data types. XACML extensibility points may be used to deal with such types in two additional ways. 1) For a given structured data type, a new attribute identifier MAY be defined for various leaf sub-elements of the structured data type. The structured data is presented to the PDP in the Request Context as a sequence of <Attribute>s that use the new identifiers. Each such <Attribute> MAY be compared using the XACML-defined functions. This method requires support by the PEP or Context Handler for flattening the structured data type into the sequence of individual <Attribute>s using the new attribute identifiers. Using this method, the structured data type itself never appears in an <AttributeValue> element. 2) A new function MAY be defined for comparing a value of the structured datatype against some other value. This method requires support by the PDP for the new function. ================================================================== 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 (Q 10/17): submit specific proposals if explicit "anonymous" support needed. ORIGINAL CHANGE REQUEST: 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) DISCUSSION: [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) http://lists.oasis-open.org/archives/xacml/200210/msg00291.html (new comment) STATUS: 7.4.2 APPROVED (NQ 10/17). NEED FINAL VOTE. See RESOLUTION. STATUS: 7.4.2.1: two proposals. #2 not yet considered. See RESOLUTION. STATUS: 7.4.2.2: new version not yet considered. See RESOLUTION. RESOLUTION: 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 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. [RESOLUTION 7.4.2.1 #1]: 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. [RESOLUTION 7.4.2.1 #2]: 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. A bag containing one value is treated as semantically equivalent to a single value of the specified bag type. 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. DISCUSSION: [Seth, explaining RESOLUTION 7.4.2.1 #2] Given the original text quoted above, an AD/AS will always return a bag, which is always an error to most of the standard functions, unless a bag with only one element is considered to be the same as a single instance of just the element inside the bag. The text change clarifies this. ================================================================== 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: ACCEPTED (NQ 10/28). See RESOLUTION. RESOLUTION: 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 determining 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: Summarized as: a) Using functions other than the standard XACML *-equal functions will make indexing Targets difficult, inefficient, or impossible for some systems. b) Using functions other than those implying a hierarchy of target matches (*-equal or *-match) functions will make indexing Targets difficult, inefficient, or impossible on some systems. c) Not allowing arbitrary boolean functions will not allow use of Target to perform more efficient evaluations on some systems. d) PAPs in some cases will know the structure of the repository and indexing system, so can allow only functions that can be indexed. If a Policy's Target uses a function that is not supported by the indexing scheme of the repository used by the PDP, then that Policy's Target will need to be evaluated against every Request. ================================================================== 0100: [Steve Hanna] SteveHanna01: integer-mod takes two arguments personal communication to Anne Anderson on 14 Oct 2002 STATUS: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: 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: REJECTED (NQ 10/28). Use URI for everything. SEE ALSO: CR#0140,0141 ORIGINAL CHANGE REQUEST: Use QName for DataType, URI for everything else. Changes required: 1) Define new namespace for XACML datatype in B.1: urn:oasis:names:tc:xacml:1.0:datatype 2) In schemas, define DataType attribute type as a QName. 3) Statement like: We recommend use of the following QName xmlns prefixes. [To make policies easier to read] xsi: <XML Schema Instance namespace> xs: <XML Schema namespace> ds: <XML Digital Signature namespace> ?: urn:oasis:names:tc:xacml:1.0:datatype ?: urn:oasis:names:tc:xacml:1.0:context (used by XPath expression) DISCUSSION: 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. [10/24/02 con call] [Anne] Should we also define namespaces for attribute categories, status codes, subject-categories? [Simon] No. Use QNames for datatypes, since xsi:string, etc. are commonly used. [Tim] Aren't QNames are used for names taken from schemas? [Simon] No. It is just a syntactic structure with no semantics behind it. Used for value of an attribute. It is an XML datatype. [Hal] A QName is a macro-expansion facility. Used in lots of schemas and specifications. [Tim] WSS uses QName for encoding type. Just an identifier. [Polar] Type needs to be either a QName or a URI, can't be both. [Satoshi Hada] So the tentative resolution says that we should write a condition by using URI rather than QName to specify function identifiers. Please correct me if I'm wrong. [See http://lists.oasis-open.org/archives/xacml/200210/msg00278.html for two examples] [Simon, responding to Satoshi Hada] That is correct [Anne, asking general questions about QNames] 1. If an xml attribute is defined as Type="xs:QName", then do XML parsers like SAX and DOM do the resolution of those names? Example: Assume AttributeDesignatorType is defined as follows: <xs:complexType name="AttributeDesignatorType"> <xs:attribute name="AttributeId" type="xs:QName" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> </xs:complexType> Then, if my Policy says <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy" xmlns:sun-attrs="urn:sun:names:attribute-ids" ... <SubjectAttributeDesignator AttributeId="sun-attrs:attr1" .../> And a Request says <Request xmlns="urn:oasis:names:tc:xacml:1.0:context" xmlns:sun-stuff="urn:sun:names:attribute-ids" ... <Subject> <Attribute AttributeId="sun-stuff:attr1"> ... Will the tools themselves resolve these, or do I have to expand the names and then perform a string match myself? Simon> By looking at the sax api it does not seem that Simon> anything is done with attribute values of qname type. Simon> My guess is that an application is responsible for Simon> expanding qname. Problem is that expanded name is a Simon> pair: (URI, local_name) and there is no standard that Simon> says how this 2 elements should be combined to form one Simon> value. Some suggest URI+local_name, others Simon> URIlocal_name, and so on. Simon> My preference would be not to use qnames for attribute Simon> values at all, and use URI's instead. Anne> But then what do we do about DataType values such as Anne> xsi:string that are already defined as QNames? 2. Does anyone have a reference from W3C on whether QNames MAY be used as "aliases" for any URI or whether they are ONLY for use in referring to URI's that represent schemas? I.e. are the uses of QNames for use in identifiers as in #1 and in our current schemas even allowed (or recommended)? 3. Is there a way to define aliases for shortcut names other than QNames? I.e. can I define an alias to be equal to some initial prefix of a long URI, and then have that expanded by XML parsing tools? ================================================================== 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: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: 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: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: 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 attribute value 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: APPROVED (Q 10/24). See RESOLUTION. SEE ALSO: CR#0101,0140,0141 RESOLUTION: Use xsi:string, etc. for XML Schema-defined datatypes in examples. Use xs:any, etc. in schema definitions. ORIGINAL CHANGE REQUEST: 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. DISCUSSION: [Tim] Example: p. 64 <Decision> is restriction on xs:string. xsi only used in examples. ================================================================== 0134a: [Seth Proctor] Policy Target computed before arriving at PDP e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: REJECTED (NQ 10/28). No change. RESOLUTION: Current version is clear. Offending text changed between time request was made and time it was considered. ORIGINAL CHANGE REQUEST: 3.3.2.1 (PolicyTarget) still makes it unclear that Policy Target is computed before arriving at the PDP. ================================================================= 0134b: [Seth Proctor] Add pointer to higher-order bag function to Apply e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: 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." DISCUSSION: 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 =================================================================== 0134c: [Seth Proctor] Need Datatypes for each defined AttributeId e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html ACTION ITEM: [Simon] Propose types for each XACMl-defined attribute-id [DONE] STATUS: Need vote on Simon's proposal. See RESOLUTION. SEE ALSO: CR#0150 RESOLUTION: Each "standard attribute" should have a "standard datatype", since we proposed them for interoperability in the first place. See http://lists.oasis-open.org/archives/xacml/200210/msg00290.html for attachment containing XACML_identifiers.doc, which is Simon's proposed list. ORIGINAL CHANGE REQUEST: 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. DISCUSSION: [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. [0141]. data type uri's. Is DataType attribute QName or URI? I've been advocating URI up to now (even on today's schema call) but I've changed my mind to QName. QName evaluates into expanded name which is a pair: (URI, local_name). Expanded name MUST be used in all operations involving DataType attribute of the xacml:AttributeDesignator, xacml:AttributeSelector, xacml:AttributeValue, and xacml-context:Attribute. Eg: <Attribute AttributeId="..." DataType="xsi:string"/> Expanded name: http://www.w3c.org/2001/XMLSchema , string If expanded name is used, we do not have to specify how to form URI out of this pair. For those who care: I was advocationg URI for the DataType because I thought that expanded qname must be somehow concatenated into one value. URI is already one value. But many times we have to invent this URI by using the same concatenation. If we compare expanded names as pairs we do not have this problem. ================================================================= 0134d: [Seth Proctor] Fix examples in Section A to include DataType e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: APPROVED (Q 10/24). Fix all examples in A to include DataType. ORIGINAL CHANGE REQUEST: 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. =================================================================== 0134e: [Seth Proctor] Bag input to single param function error; bags of any type e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: 1) APPROVED (Q 10/24). See RESOLUTION. STATUS: 2) REJECTED (Q 10/24). See RESOLUTION. RESOLUTION: 1) APPROVED: Any type allowed in a bag (i.e. user-defined types as well as XACML-defined types). Wording in A.11 and A.13.9 should be changed to reflect this. 2) REJECTED: Already specified. A.14.1 Equality predicates, example: boolean-equal: "This function SHALL take two arguments of xs:boolean". A.14.2 Arithmetic functions Starts with "All of the following functions SHALL take two elements of the specified type, integer or decimal." A.14.3 String conversion functions example: string-normalize-space: "This function SHALL take one argument of type 'xsi:string'..." etc. ORIGINAL CHANGE REQUEST: 1) 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. I think it should be made clear that if a function expects a single String (eg), then getting a bag is an error. 2) 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. ================================================================= 0134f: [Seth Proctor] Missing status codes e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: CLOSED (10/30). Seth says new codes no longer needed. SEE ALSO: CR#0143, which proposes formats. ORIGINAL CHANGE REQUEST: 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? ================================================================= 0134g: [Seth Proctor] Acknowledgments/Contributions e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: Include Seth, Pierangela, Ernesto, etc. on front page "Contributors" (everyone who made substantial contributions during development of sepcification). Appendix D will include only voting members at the time of approval for Committee Spec. ORIGINAL CHANGE REQUEST: 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. ================================================================= 0134h: [Seth Proctor] Should SubjectADWhere extend SubjectAD? e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: REJECTED (Q 10/24). See Simon's comment. ORIGINAL CHANGE REQUEST: 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. DISCUSSION: [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. ================================================================= 0134i: [Seth Proctor] Treating Request as notional document e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: REJECTED (Q 10/24). Provide specific wording if still needed. SEE ALSO: CR#0135, CR#0136 ORIGINAL CHANGE REQUEST: 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. DISCUSSION: [Anne] Some of the "one or two paragraphs added somewhere" are in a new section proposed in CR#092: "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. ================================================================= 0134j: [Seth Proctor] Examples for using AD/AS with "notional" Request e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: REJECTED (Q 10/24). Provide specific wording if still needed. ORIGINAL CHANGE REQUEST: There needs to be some clear examples of how to use an AD/AS to make [treating Request as notional document] 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. DISCUSSION: [Anne] Isn't that an implementation issue? The spec should just specify the desired behavior, not how it is achieved. ================================================================= 0134k: [Seth Proctor] Describe how Policy[Set]Ids should be treated e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: REJECTED (Q 10/24). Out of scope. See RESOLUTION. RESOLUTION: Out of scope. Id MUST be a URI, but we don't force URN or URL. Anne is thinking of writing another specification for an extension or wrapper for an XACML policy that specified via URLs where to find things like: policy ids, executable code for functions, attributes, PAP's, AA's. Basically a schema for mapping various IDs in various contexts to URLs. ORIGINAL CHANGE REQUEST: 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. ================================================================= 0134l: [Seth Proctor] How to do resolution in an Apply e-mail sent 16 Oct 2002 11:16:30 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00192.html STATUS: REJECTED (Q 10/24). Already specified. See RESOLUTION. RESOLUTION: Already clearly laid out in A.13.5 for logical functions. Bag functions refer to these. Laid out in first paragraph of A.13.2 for Arithmetic functions (if any argument is missing, then expression is "indeterminate". Laid out at beginning of description of each other type of function. ORIGINAL CHANGE REQUEST: There is still no text about how to do resolution in an Apply, and how this can be short-circuited, etc. 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. ================================================================== 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: (Q 10/24). See RESOLUTION SEE ALSO: CR#0134i RESOLUTION: Don't touch diagram. However, 8 should say "Context Handler supplies information about the Request Context to the PDP." ORIGINAL CHANGE REQUEST: 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: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: 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: xsi:decimal string representation e-mail sent 16 Oct 2002 14:45:39 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00198.html STATUS: REJECTED (Q 10/24). Stated in schema definition. ORIGINAL CHANGE REQUEST: 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: APPROVED (Q 10/24): Replace "decimal" with "double". ORIGINAL CHANGE REQUEST: 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: APPROVED (Q 10/24). See RESOLUTION. RESOLUTION: 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. ORIGINAL CHANGE REQUEST: 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. ================================================================== 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: REJECTED (NQ 10/28). Use URI for everything. SEE ALSO: CR#0101,0132,0141 ORIGINAL CHANGE REQUEST: 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. DISCUSSION: [Satoshi Hada] I found an inconsistent use of the "DataType" attribute. ---------------------------------------------------- <Attribute DataType="xs:string"....> In this case, it seems to me that the attribute type is xs:QName. ---------------------------------------------------- <Attribute DataType="urn:oasis:names:tc:xacml:1.0.datatype:x500name"...> In this case, it seems to me that the attribute type is xs:anyURI. ---------------------------------------------------- As Kudo-san is requesting, I'd request to change the type from xs:anyURI to xs:QName. ================================================================== 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: Need decision on URL vs. URN (10/28). See RESOLUTION. SEE ALSO: CR#0101,0132,0140 RESOLUTION: We like the list of data types and agree they should not be QNames, but are unresolved as to whether we use URL or URN for datatypes. If URL, then we need a way to specify the two xacml-defined DataTypes as URLs. RESOLUTION SPECIFIC TEXT: 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 ================================================================== 0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor. e-mail sent 17 Oct 2002 16:43:04 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00216.html ACTION ITEM: [Anne] Write up RESOLUTION with details spelled out. [DONE] STATUS: Vote on RESOLUTION needed (10/28). SEE ALSO: CR#0146 RESOLUTION: Overview: Create a new XML attribute on Designators and Selectors to indicate "Must be present". This new attribute is optional, and may be used in either Target or Condition. Behavior of indeterminate results in Target where AND or especially OR is being done (e.g. in multiple subjects where only one needs to match) needs to be spelled out, but it should follow behavior of current "and" and "or" functions. RESOLUTION SPECIFIC TEXT (aligned with CR#0146): 1. In policy schema: Change <xs:complexType name="AttributeSelectorType"> <xs:attribute name="RequestContextPath" type="xs:string" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> </xs:complexType> To: <xs:complexType name="AttributeSelectorType"> <xs:attribute name="RequestContextPath" type="xs:string" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:attribute name="MustBePresent" type="xs:boolean" use="optional" default="false"/> </xs:complexType> 2. In policy schema, Change <xs:complexType name="AttributeDesignatorType"> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> </xs:complexType> To: <xs:complexType name="AttributeDesignatorType"> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> <xs:attribute name="MustBePresent" type="xs:boolean" use="optional" default="false"/> </xs:complexType> 3. Section 5.23 Complex type AttributeDesignatorType, append following to the very end of this section (after Issuer [Optional] description): MustBePresent [Optional] The MustBePresent attribute governs whether the AttributeDesignator element returns an empty bag or indeterminate in the case of finding no value for the named attribute in the request context. [Insert text from CR#0146 here] The default value for the MustBePresent attribute is false. 4. Section 5.29 Element <AttributeSelector>, append following to the very end of this section (after DataType [Required] description): The MustBePresent attribute governs whether the AttributeSelector element returns an empty bag or indeterminate in the case of finding no value for the named attribute in the request context. [Insert text from CR#0146 here] The default value for the MustBePresent attribute is false. ORIGINAL CHANGE REQUEST: TEXT LOCATION: Section A.11, Paragraph 3, lines3459-3461: 'If the <AttributeDesignator> or <AttributeSelector> element evaluates to an empty bag, then the result of the expression SHALL be "False".' It seems to me that an empty bag only happens if you can't resolve a value for the attribute in question...could this actually mean something else? The only thing I could think of is an Attribute in the Request that matched but had no AttributeValues in it (this strikes me as a wierd case, but since it's allowed, this is possible). If this is the case being described, then this should be explained so it's clear. If this is not the case, then isn't an empty bag really an Indterminate case? There isn't much discussion elsewhere about what exactly AD/AS objects are expected to return, so maybe more text in section 5 would help clarify this situation. I'm also a little uneasy about the language because it borders on defining programming interfaces, but I don't want to propose alternate language until I understand what's really being described here. What does this sentence mean? DISCUSSION: Summarized as: Some people think returning false when a match compares to a missing attribute is a security problem. Other people think returning indeterminate when a match compares to a missing attribute is an efficiency and scalability problem, making it hard to index on targets. See archives for details. We compromised by allowing the policy writer to control the behavior: introduce an optional XML attribute MustBePresent="<xs:boolean>" (with default false) in all elements derived from AttributeDesignator and AttributeSelector, including the new elements in CR#0146. Agreed text for resolution of CR#0146 and this one should be aligned. RESOLUTION above does this. ================================================================== 0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor. e-mail sent 17 Oct 2002 16:56:44 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00217.html ACTION ITEM: [Seth Proctor] Write up details for missing-attribute. STATUS: status:ok APPROVED (NQ 10/28). See RESOLUTION STATUS: status:missing-attribute (10/28). Waiting on Seth to provide details. STATUS: status:syntax-error APPROVED (NQ 10/28). See RESOLUTION. STATUS: status:processing-error APPROVED (NQ 10/28). See RESOLUTION. RESOLUTION: Accept proposed text for all status codes except for "missing-attribute". That one needs: o syntax for a sequence of <xacml-context:Attribute> [Note <StatusDetail> contains sequence of 0-unbounded elements. The element could be of type <xacml-context:Attribute>] o way to specify whether each missing attribute is for Subject, Resource, Action, or Environment, o if missing attribute is for a subject, and if there are multiple Subjects, a way to specify for which subject the attribute is missing. [Anne: perhaps the format is just <xacml-context:Request>...] RESOLUTION SPECIFIC TEXT: TEXT LOCATION: Following last sentence of Section "6.15 Element <StatusDetail>", p. 68, line 2820. TEXT CHANGE: Append following: Inclusion of a <StatusDetail> element is always optional. However, if a PDP returns one of the following XACML-defined <StatusCode> values AND returns a <StatusDetail> element, then the format of the <StatusDetail> element MUST be as follows: urn:oasis:names:tc:xacml:1.0:status:ok The PDP MUST return no <StatusDetail> element in conjunction with this status value. urn:oasis:names:tc:xacml:1.0:status:missing-attribute sequence of <Attribute> A PDP MAY choose not to return any <StatusDetail> information or MAY choose to return a <StatusDetail> message containing one or more <xacml-context:Attribute> elements. If AttributeValues are included in an Attribute, then the PDP is specifying one or more acceptable values for that Attribute. If no AttributeValues are included, then PDP is simply naming attributes that it failed to resolve during its evaluation. The list of Attributes may be partial or complete. There is no guarantee by the PDP that supplying the missing values or attributes will be sufficient to satisfy the policy. urn:oasis:names:tc:xacml:1.0:status:syntax-error A PDP MUST return no <StatusDetail> element in conjunction with this status value. A syntax error is either a problem with the policy being used or with the Request document submitted. The PDP MAY return a <StatusMessage> describing the problem. urn:oasis:names:tc:xacml:1.0:status:processing-error A PDP MUST return no <StatusDetail> element in conjunction with this status value. This status code indicates an internal problem in the PDP. For security reasons, the PDP MAY choose to return no further information to the PEP. In the case of a divide-by-zero error or other computational error, the PDP MAY return a <StatusMessage> describing the nature of the error. DISCUSSION: When status data is returned from the PDP, it may be as result of any number of things, four of which are defined in the specification. For these standard cases, the PEP (or some other entity) will need to be able to handle any extra data that is returned in the status. But the format of status data associated with the four standard status codes is not defined, which is a problem. Here, therefore, is a very simple proposal for what the formats should like. There are undoubtedly more complex solutions, but this seems like the most straightforward approach, and will let different implementions act in similar ways. ================================================================== 0144: [Polar] harmful to interoperability e-mail sent 21 Oct 2002 08:50:03 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00239.html STATUS: APPROVED (NQ 10/28). See RESOLUTION. RESOLUTION: Don't talk about harmful anything. Section 2.3 Combining Algorithms, last paragraph Change the entire paragraph to: As one of the XACML extensibility points, XACML may be extended with alternate rule and policy combining algorithms. In section 2.3 "Combining Algorithms", the last paragraph says, ORIGINAL CHANGE REQUEST: "Users of the standard may, if necessary, defined their own combining algorithms. However this approach is harmful to interoperability..." How is this harmful to interoperability? Don't you mean "portability" of policies from one XACML evaluation engine, e.g. a PDP, to another? Also, saying that "users should specify how the combined result is to be derived from separate evaluation of the individual <Rule> or <Policy> statements", is not needed. It's like telling somebody that they *should* document their code. Although it is a notably good practice and should be encouraged, it is kind of insulting to XACML spec readers that would or already do so. I would be in favor of a statement that is more focused on the standard and not its "user" in this regard. I think what we are after here, is just a statement that rule and policy combining algorithms are an XACML extensibility point. I request to change the entire paragraph to: As one of the XACML extensibility points, XACML may be extended with alternate rule and policy combining algorithms. ================================================================== 0145: [Seth Proctor] Multi-valued attributes in Request. e-mail sent 22 Oct 2002 07:48:21 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00243.html STATUS: APPROVED (NQ 10/28) Change to maxOccurs=1. ORIGINAL CHANGE REQUEST: I'm looking for a clarification on the use of multiple AttribueValue entries in an Attribute type in the Request. If I have an Attribute with multiple AttributeValue entries, am I supposed to treat each of these as being (effectively) separate Attributes with the same values for their meta-data? This seems like the logical approach, but nothing in the spec defines the right behavior. Following from this, is it an error if the Subject Category (for instance) Attribute has multiple AttributeValue entries, since the spec says that there must be one and only one value for this attribute? DISCUSSION: [Polar] We have multiple <AttributeValue> in attributes? You mean in the Request Context? That really shouldn't be. Being that the request context is a "notational" structure, there really insn't any need for "economy", such as it is with XML, on these things. Also, since the <Attribute> has the DataType attribute, and has the <AttributeValue> element which must conform to the DataType, I really see no reason to have such things. Why complicate matters? The request context is "notational" and using the language of XML schema should just say that each attribute shall have an attribute id, a datatype, and a value for that datatype, and may have and issuer and issue instant. I suggest we clear this up by changing the schema to make the attribute value occurance to minOccurs=1 maxOccurs=1. ================================================================== 0146: [Polar] CR 144: function "present" needs to be fixed. e-mail sent 22 Oct 2002 12:25:52 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00247.html http://lists.oasis-open.org/archives/xacml/200210/msg00293.html (DRAFT) ACTION ITEM: [Polar] write up resolution for specification. [DRAFT DONE] STATUS: Need vote on new RESOLUTION (NQ 10/28). Resolve ISSUES. SEE ALSO: CR#0142 RESOLUTION: Make new XML elements in schema. Remove them from Appendix A, put them in text description. New proposal removes all the -must-be-present functions, since new XML attribute on attribute designator can do that. SPECIFIC RESOLUTION: [Polar] (PARTIAL DRAFT; approved amendments from Anne incorpor