[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Minutes of 28 Oct 02 SC Meeting; also Updated Change Requests
I have removed all completely resolved items from the Summary list. I have divided the Summary list into two parts: - CRs that have been resolved by a non-quorum meeting but are awaiting a quorum vote to confirm. - CRs that still need action and resolution. For most of these we have a TENTATIVE RESOLUTION that simply needs to be written up by the person assigned the action item, then the proposal needs a final vote. 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.13, 02/10/28 (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/msg00286.html See http://lists.oasis-open.org/archives/xacml/200210/msg00214.html for the changes previously approved to v0.18c.doc. This document also serves as the minutes for the SC meeting on 28 Oct 2002: Present: Simon Godik, Hal Lockhart, Tim Moses, Polar Humenn, Anne Anderson (scribe) ACTION ITEMS ============ 0134c: Need Datatypes for each defined AttributeId ACTION ITEM: [Simon] Propose types for each XACMl-defined attribute-id 0134f: Missing status codes ACTION ITEM: [Seth] supply list of additional codes. 0141: data type uri's ACTION ITEM: [All] Weigh in with opinions. 0142: bags and targets. Forwarded message from Seth Proctor. ACTION ITEM: [Anne] Write up TENTATIVE RESOLUTION with details spelled out. 0143: 6.15 status detail formats ACTION ITEM: [Seth Proctor] Write up details for Tentative Resolution. 0148a: Example two rules not applicable to request ACTION ITEM: [Simon] Review and revise as needed. 0148b: Include target-namespace in Request Context? ACTION ITEM: [Simon] Review and revise as needed. 0148c: Syntax of RequestContextPath not consistent ACTION ITEM: [Simon] Review and revise as needed. 0148d: Move "disjunctive sequence" up to higher element description ACTION ITEM: [Simon] Review and revise as needed. 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 TENTATIVE RESOLUTION. 0092: [Polar] PH09: New section 7.4.2 Attributes STATUS: Tentative approval (NQ 10/17). 7.4.2.2 revised. Needs final vote. 0098: [Anne] AA11: Clarify "MatchId" functions STATUS: CLOSED (NQ 10/28): allow any boolean function that takes two arguments. 0101: [Satoshi Hada] SatoshiHada01: How many namespaces does XACML define? STATUS: CLOSED (NQ 10/28). Use URI for everything. TENTATIVE RESOLUTION rejected. 0134a: [Seth Proctor] Policy Target computed before arriving at PDP STATUS: CLOSED (NQ 10/28). Current version is OK. 0140: [Michiharu] MK01: DataType and Namespace STATUS: CLOSED (NQ 10/28). Use URI for everything. SEE ALSO: CR#0101,0132,0141 0144: [Polar] harmful to interoperability STATUS: APPROVED (NQ 10/28). Reword as suggested. Don't talk about harmful anything. 0145: [Seth Proctor] Multi-valued attributes in Request. STATUS: APPROVED (NQ 10/28) Change to maxOccurs=1. 0146: [Polar] CR 144: function "present" needs to be fixed. STATUS: APPROVED (NQ 10/28). See RESOLUTION. 0147: [Seth Proctor] Bug in pseudocode for Only One Applicable. STATUS: APPROVED (NQ 10/28). Polar will reword. 0149: [Seth Proctor] Environment attributes STATUS: CLOSED (NQ 10/28). See RESOLUTION. STILL NEED REVIEW AND ACTION ============================ 0134c: [Seth Proctor] Need Datatypes for each defined AttributeId STATUS: See TENTATIVE RESOLUTION (10/24). Waiting on Simon's list. 0134f: [Seth Proctor] Missing status codes STATUS: Seth requested to supply list of additional codes. (10/24). 0141: [Simon] SG[??]: data type uri's STATUS: UNRESOLVED (10/28). See TENTATIVE RESOLUTION. 0142: [Seth Proctor] bags and targets. Forwarded message from Seth Proctor. STATUS: UNRESOLVED (10/28). See TENTATIVE RESOLUTION. 0143: [Seth Proctor] 6.15 status detail formats. Forwarded message from SethProctor. STATUS: See TENTATIVE RESOLUTION (NQ 10/28). 0148a: [Yassir Elley] Example two rules not applicable to request STATUS: (10/28) Waiting on Simon's review and/or revision. 0148b: [Yassir Elley] Include target-namespace in Request Context? STATUS: (10/28) Waiting on Simon's review and/or revision. 0148c: [Yassir Elley] Syntax of RequestContextPath not consistent STATUS: (10/28) Waiting on Simon's review and/or revision. 0148d: [Yassir Elley] Move "disjunctive sequence" up to higher element description STATUS: (10/28) Waiting on Simon's review and/or revision. 0152: [Tim Moses] Trivial Matter 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 TENTATIVE RESOLUTION. TENTATIVE RESOLUTION: 10/21 meeting reached following tentative resolution, but it involves enough of a change that members need to see the actual revised text before voting. 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. 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) STATUS: Tentative approval (NQ 10/17). 7.4.2.2 revised. Needs final vote. 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: CLOSED (NQ 10/28): allow any boolean function that takes two arguments. 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: 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] Disagreement on whether functions used in <Target> MUST be XACML standard functions, or whether they can be any function of the specified form (returns binary, takes two arguments where first is explicit attribute value and second is Designator or Selector. Also, if XACML standard functions required, which ones are permitted. Polar and Daniel support just *-equal functions in MatchId. Hal and Tim support *-equal and *-match functions in MatchId. Anne supports *-equal, *-match, *-great-than*, and *-less-than* functions in MatchId (i.e. any two-argument function that returns boolean). There appear to be three points of view with respect to use of <Target> that would determine which functions are appropriate: 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". 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]. 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: APPROVED (Q 10/24). Use proposed text. 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: CLOSED (NQ 10/28). Use URI for everything. TENTATIVE RESOLUTION rejected. SEE ALSO: CR#0140,0141 TENTATIVE RESOLUTION: Use QName for DataType, URI for everything else. [REJECTED] 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). Use proposed text. 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). Use proposed text. 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: CLOSED (Q 10/24) See RESOLUTION below 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. DISCUSSION: 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. [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: CLOSED (NQ 10/28). Current version is OK. 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). Add pointer as in Anne's comment. 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 DISCUSSION: [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." 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 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. ACTION ITEM: [Simon] Propose types for each XACMl-defined attribute-id STATUS: See TENTATIVE RESOLUTION (10/24). Waiting on Simon's list. SEE ALSO: CR#0150 TENTATIVE RESOLUTION: Each "standard attribute" should have a "standard datatype", since we proposed them for interoperability in the first place. Simon will come up with a proposal with types for each standard attribute, and we can then vote on it. 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. 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 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. STATUS: APPROVED (Q 10/24). Fix all examples in A to include DataType. 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 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. STATUS: CLOSED (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. 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 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? ACTION ITEM: [Seth] supply list of additional codes. STATUS: Seth requested to supply list of additional codes. (10/24). SEE ALSO: CR#0143, which proposes formats. 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 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. 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. 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 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. STATUS: REJECTED (Q 10/24). See Simon's comment. 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 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. STATUS: CLOSED (Q 10/24). Provide specific wording if still needed. SEE ALSO: CR#0135, CR#0136 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 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. STATUS: CLOSED (Q 10/24). Provide specific wording if still needed. 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 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. STATUS: REJECTED (Q 10/24). 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. 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 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. 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. ================================================================== 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 RESOLUTION: Don't touch diagram. However, 8 should say "Context Handler supplies information about the Request Context to the PDP." SEE ALSO: CR#0134i 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). Use proposed text. 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. 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". 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). Use proposed text. 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: CLOSED (NQ 10/28). Use URI for everything. SEE ALSO: CR#0101,0132,0141 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. [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 ACTION ITEM: [All] Weigh in with opinions. STATUS: UNRESOLVED (10/28). See TENTATIVE RESOLUTION. SEE ALSO: CR#0101,0132,0140 TENTATIVE 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. 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 TENTATIVE RESOLUTION with details spelled out. STATUS: UNRESOLVED (10/28). See TENTATIVE RESOLUTION. TENTATIVE RESOLUTION: 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. 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? [Polar] This sentence means exactly what it says. If the the selector or designator evalutates to an empty bag, then there is no match, i.e. the match "predicate" is False. The match predicate is akin to asking, "Do you have one or more of any subject ids that match "john.*". If you have none, then False, if you have at least one, then True. This is a composition of three functions: an Attribute Designator i.e. "Get me all subject ids", a match filter, i.e. "that match 'john.*', and a length predicate "length > 0". Regardless of the match filter, if you have zero elements to start with, you will end up with zero elements after you apply the match filter, and therefore, vacuously, you don't have a match. [Seth] Yes, I understand that. What I don't understand is how the bag could be empty and not have that be an Indeterminate case. This is the only question I was asking. [Polar] If I ask you whether or not you have any bills in your wallet that have a picture of Ulysses S. Grant on them. What will you tell me? [Anne, responding to Polar] On 17 October, Polar Humenn writes: > This sentence means exactly what it says. If the the selector or > designator evalutates to an empty bag, then there is no match, i.e. the > match "predicate" is False. > > The match predicate is akin to asking, "Do you have one or more of any > subject ids that match "john.*". If you have none, then False, if you have > at least one, then True. Are you saying that the result will be "False", rather than "Indeterminate", when an not-found attribute is compared to a value? If so, I think this is wrong. If we can't find an attribute value in the Request Context, for whatever reason, then the result should be "Indeterminate", because there MAY be such a value available somewhere and we simply weren't able to get it. If your application needs to know for sure that something is not available (e.g. "Is this person a convicted felon?"), then the application needs to use a positive attribute like "Is not a convicted felon", where a trusted authority makes a positive assertion that such information is missing, rather than depending on a missing "Is a convicted felon" attribute. We really need to pin this down. Daniel, I think, says that only some sort of operational error in talking to the PIP or repository would result in "Indeterminate". But we can't guarantee that an error would be detected or that the PDP wasn't querying the wrong PIP or repository. A classic security breach is to make something silently unavailable (unplug a relay, re-route a message, etc.), and use that to access systems that assume something that is not available is false. If an attribute is not present, then the PDP doesn't know what its value is, and the result should be "Indeterminate" - which means "the PDP is unable to determine the result". [Polar] A *Match does not return indeterminate, unless something is wrong operationally. The predicate is there an attribute that matches? If there is no attributes of that name, then the information isn't there. If you really want an indeterminate, you may wrap the attribute designator in an apply of "*-one-and-only". This forces an Indeterminate error if there isn't one attribute. Simiarly, you can write "*-greater-than" on the "*-length", etc. I strongly suggest that policy writers should not be relying on "Indeterminate" for evaluations. It is an error condition, not a valid access decision. Writers (or should I say their tools) should be using "present" in boolean expressions that lead to the desired effect. [Anne, responding to Polar] On 17 October, Polar Humenn writes: > This sentence means exactly what it says. If the the selector or > designator evalutates to an empty bag, then there is no match, i.e. the > match "predicate" is False. Isn't this in direct contradiction to your proposed text for "7.4.2.2 Missing Attributes": 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. [Polar, responding to Anne] No, This says if the PDP "evaluates an expression that requires at least one value to be present" Such an example would be <Apply FunctionId="string-one-and-only"> <AttributeDesignator AttributeId="urn:...:name" DataType="xs:string"/> </Apply> [Anne, responding to Polar] You can't use "present" or "*-one-and-only" or "*-length" in a <Target>. This means any policy where you really care about whether an attribute is present or not will have to use an <Any*> Target, and thus will always need to be evaluated (can't eliminate by indexing). I strongly suggest that policy writers should not be relying on absence of an attribute for evaluations. It is indeterminate, not a valid access decision. :-) Note that there are numerous places in the spec that will need to be re-written or clarified to conform with your interpretation of attribute retrieval. I think this is something that has not been clearly understood by all the TC members, but it is critical to the semantics of XACML. I can live with Polar's interpretation, although I think it is wrong and dangerous to security. If we accept his interpretation, however, we need to be very clear in spelling out how his interpretation applies to policy evaluation. That is not currently the case, as witnessed by this entire disagreement. [Daniel, responding to Anne] >We really need to pin this down. Daniel, I think, says that >only some sort of operational error in talking to the PIP or >repository would result in "Indeterminate". But we can't >guarantee that an error would be detected or that the PDP >wasn't querying the wrong PIP or repository. A classic >security breach is to make something silently unavailable >(unplug a relay, re-route a message, etc.), and use that to >access systems that assume something that is not available is >false. Not only an operational error - value out of the permissible value space for the particular data type, or inability of an underlying computational procedure to produce a result when the value is returned by an another function application also results in Indeterminate. What you are suggesting is that PDP should have some sort of an internal knowledge of what information must be available in the context and signal any discrepancy via Indeterminate result. I do not think it is a workable operational requirement, especially given that we do not specify much about the internals of our virtual context (and I do not think we should). Such intrusion detection is probably the job of the PIP service, and yes - it can pass Indeterminate value to the PDP if, for example, some SHA signature is off etc. But that is not the job of the PDP, and an empty bag is a critically useful abstraction to use. If you want to write your policy in the way, that prohibits access if something is missing - you can. Polar suggested several different approaches to this - using present, *-one-and-only will achieve the same effect. I do not remember whether we agreed or even discussed my proposal to treat designator supplied as an argument to a function requiring a single value attribute as an implicitly wrapped in *-one-and-only type transformation (but at least several examples used around do treat it that way). Explicitly stating such an assumption will probably answer your concern - it does produce Indeterminate on missing attribute, when applied to a function requiring a singleton.. [Anne, responding to Daniel] I believe it is your interpretation that suggests that the PDP has some sort of internal knowledge about what information must be available in the context. I am being very clear in saying that the PDP does NOT have that knowledge, and if it is unable to find an attribute that is referenced by an AttributeDesignator, for whatever reason, it will ALWAYS return "Indeterminate" as the result. > If you want to write your policy in the way, that prohibits > access if something is missing - you can. Polar suggested > several different approaches to this - using present, > *-one-and-only will achieve the same effect. a) I can't use those in the Target b) If I try to use an attribute whose retrieval could fail in a Target, then the Target will evaluate to NotApplicable. This will happen even if a temporary network glitch was the cause for the attribute retrieval failure, and even if the policy has a "Deny" effect and would have caused me to deny access had the attribute been available. > I do not remember whether we agreed or even discussed my > proposal to treat designator supplied as an argument to a > function requiring a single value attribute as an implicitly > wrapped in *-one-and-only type transformation (but at least > several examples used around do treat it that way). > Explicitly stating such an assumption will probably answer > your concern - it does produce Indeterminate on missing > attribute, when applied to a function requiring a > singleton.. That would answer only one concern. I agree, however, that if we accept your interpretation, we must spell this out. [Polar, responding to Anne] Requiring an attribute to be there for a match in a target, requires you to evaluate targets against your request context for your missing attributes, which precludes doing easy target indexing on the > request in the first place. The process of target indexing is actually the other way around. You have a context with attributes, then you ask "Which policyies match these attributes?". You evaluate the request context against the targets. You evaluate the conditions against the request context. That functionality can be expressed in the condition with an appropriate target that doesnn't match on your particular attribute. But like I said, you shouldn't be writing policies based on "Indeterminate". It is a bad error condition. You should write expressions in the condition that yield the desired effect for an access decision if such needed information is missing. [Daniel] We probably should discuss my suggestion. Implicit *-one-and-only type transformation when selector/Designator is used as an argument that must be of singleton type is safe, clear and answers your concerns about its use in Target. If you, indeed need one and only one argument (and any function requiring a sigleton does, by definition) anything else will yield Indeterminate (which is indeed a bad condition one should not rely upon for expressing the policy logic - it is there since errors do happen in our externalized data model and computation model and we needed a clear and deterministic mechanism of dealing with them). [Daniel, responding to Anne] In the same fashion your rule repository could break or hacked in. There are many of modes to break down, but the system stability is hardly a concern for the authorization logic, is it? Also - empty bag is NOT a failed retrieval. Failed retrieval MUST result in Indeterminate. Empty bag means that context was verified intact, working and lacking a particular named attribute value. If the presense of such attribute was required by the rule logic - it is a missing attribute, expressed as Indeterminate value, as in Polar's one-and-only example.. [Polar] Even so, this appraoch breaks the whole ease of targeting policies. This requires that you need to evaluated all your targets for every request to make sure that you do not have an interdeterimate comming up from some error condtion of not not having a particular attribute. You want to take the information given to you in the request context and select the applicable policies. Write those policies as such. If you have special requirements such that an attribute must be present with some value, that is a "complicated" evaluation and should go in the condition. Otherwise, Policy Targeting is just another "hard" evaluation, and we might as well eliminate it all together. [Daniel] Not sure what exactly is being broken - the evaluation performed is exactly the same - the only difference is the "automatic" type convertion function application for this very narrow and well defined case. Matching (member-of "blah" <designator>) and (string-equal "blah" <implicit string-one-and-only<designator> >) is the same - you can compile and make sure the type safety is satisfied just as well. It is only a syntax issue to allow easier use of designators/selector in target without opening up the syntax to a full blown <apply> tree. If you have your context precompiled and verified you index the target in just the same way - you just write it down in a little bit diferent manner.. But I do agree that everything complicated sould go into condition - but we already have our target structure. [Polar, responding to Daniel] > Not sure what exactly is being broken - the evaluation performed is exactly > the same - the only difference is the "automatic" type convertion function > application for this very narrow and well defined case. That's not what I am talking about. I am talking about taking you match statements and evaluating the request context against them. If you have 100,000 policies all of which only 3 apply to a subject-id of "john". You can take the information in the request context, i.e. subject-id of John, and find those three policies by indexing, of which now, you apply the combining algorithm against their evaluations. Now, if you didn't have a request context with a subject-id attribute? You might get other policies that apply on some other criteria, but you would be forced to throw an Indeterminate? How would you even find those policies to begin with? If you are allowed to have a single policy with a TARGET that says "if you don't have an attribute of "subject-id" throw an Indeterminate". That forces the PDP to evaluate each and every target, all 100,000 of them for each request, to make sure that the attributes are there. Remember, the combining algorithms do funky things with indeterminates, like make them disappear, in favor of Deny or Permit, up the evaluation chain. So you would indeed have to evaluate each and every target of every policy for each request, all 100,000 of them! That is not what Targeting is for. It is supposed to aid in simple indexing and finding of applicable policies. Hal wouldn't you agree? Otherwise, we might as well just get rid of target alltogether and leave everything into a condition. Targeting allows you to place simple critera for discovering the applicability of a policy, and nothing else. If an attribute is needed and it is not there, that logic should reside in the <Condition>, which MUST be evaluated once the policy/rule is considered applicable. [Daniel] >If you are allowed to have a single policy with a TARGET that >says "if you don't have an attribute of "subject-id" throw an >Indeterminate". That forces the PDP to evaluate each and every >target, all 100,000 of them for each request, to make sure >that the attributes are there. Absolutely not. The time to look up "John" in a hash map is the same whether "John" is present or not. It is O(1) for any case when it can be reduced to an equality operation and indexed in advance - is not it? [Polar] I think you mean, the time to look up subject-id "John" in the hash map is the same as looking up whether the subject-id is present or not. It's one thing to *have* a subject id with "John" and look up applicable policies. Its an entirely different thing to NOT have a bunch of ???? attributes and find out if there are any policies that want it. Let's say you have a FirstApplicable combining Algorithm on the the policy set. The first Target wants a "subject-id" match to "John". The second wants a "weight" attribute of "100lbs". If you have a request with a "subject-id" of "John" and no "weight" attribute. What happens? What happens if you have a "weight" attribute of "100lbs", but no "subject-id" attribute? What happens. I know it's a seemingly simple case, but now expand that with many policies, many targets, and also consider the recursive nature of the policy set composition. You end up having to encode the logic of the combining algorithms into your missing attribute discovery. Also, think of the Subject section which has complex logic for dealing with different subjects. That evaluation is of greater complexity of just looking up policies against attributes you already have. The Target should determine the applicability of the policy or rule, and nothing else. The complex logic goes in the condition. Indeterminate is an error condition, it should not be relied upon for policy decisions. That is an abuse of the intent. Use the right logic, and determine the proper effect. [Daniel, responding to Polar] Let me clarify a bit. The way I see the indexing working: Policy is analysed and, for example, rules requiring attribute "foo" to match are present. Rules are indexed by the value of "foo" required to match. Rules are indexed by each attribute required to match - so, yes it is expensive to have rules requiring many different attributes - but there is no way around this anyway. If a request, with an attribute "foo" comes in - rules are looked up - constant time per each attribute. It is known in advance that rules requiring "foo" are needed, so if it is not present, automatically, the whole table of rules indexed by "foo" are getting Indeterminate result in match - in constant time, that's what happens. What to do with all this rules - that's a different thing, but as long as we MAY have missing attributes in match (they are (non)received with a request), this can happen and it does scale well. So it does scale as long as it is an match that can be hashed. ================================================================== 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 Tentative Resolution. STATUS: See TENTATIVE RESOLUTION (NQ 10/28). TENTATIVE RESOLUTION: Accept proposed text for all status codes except for "missing-attribute". That one needs: o syntax for a sequence of <xacml-context:Attribute> o way to specify whether each missing attribute is for Subject, Resource, Action, or Environment, and 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>...] 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 ISSUE: Needs to specify subject/resource/action/env attribute, and, if multiple subjects, for which one. 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). Reword as suggested. Don't talk about harmful anything. In section 2.3 "Combining Algorithms", the last paragraph says, "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. 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? [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. [Bill] i agree. [Konstantin] I agree too. Multi-value attributes make the semantics of attribute comparison more difficult. ================================================================== 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 STATUS: APPROVED (NQ 10/28). See RESOLUTION. 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. ResourceAttributeDesignator now extends AttributeDesignator. Resource-attribute-is-present attribute contains same information, but it returns The function "present" as we discussed yesterday in spec 18d is vague in whether it returns "false" or raises an "indeterminate" if the attribute is not present. This needs to be cleared up, and we might address some of Simon's concerns of which he alluded to yesterday on "indeterminate" for an attribute that is not present. I don't like that, but I'm not against it. I've got another proposal to handle the cases where we need to have predicates for the presence of attribute values, for action, resources, and subjects. The basic upshot is the following: The following correspond to their *AttributeDesignator counterparts: o action-attribute-is-present o resource-attribute-is-present o subject-attribute-is-present o subject-attribute-is-present-where o environment-attribute-is-present The following correspond to the AttributeSelector element: o attribute-is-present o attribute-must-be-present So, I now suggest to replace the last bullet & paragraph (i.e. "present" of Section A.14.5 Logical Functions with the following: o action-attribute-is-present This function SHALL take two arguments. The first argument SHALL be an attribute value of type "xs:QName" as used in the "AttributeId" XML attribute of an <ActionAttributeDesignator> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <ActionAttributeDesignator> element. This expression SHALL result in "true" if the named attribute can be located in the request context. A result of "true" means that an <ActionAttributeDesignator> element for this named attribute will return a bag consisting of at least one element. If no value can be found for the attribute in the request context, then this expression SHALL result in "false". A result of "false" means that an <ActionAttributeDesignator> element for this named attribute will return an empty bag. If it cannot be determined whether the attribute is present or not present in the request context, or its value is unavailable, then the expression SHALL result in "indeterminate". o resource-attribute-is-present This function SHALL take two arguments. The first argument SHALL be an attribute value of type "xs:QName" as used in the "AttributeId" XML attribute of an <ResourceAttributeDesignator> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <ResourceAttributeDesignator> element. This expression SHALL result in "true" if the named attribute can be located in the request context. A result of "true" means that an <ResourceAttributeDesignator> element for this named attribute will return a bag consisting of at least one element. If no value can be found for the attribute in the request context, then this expression SHALL result in "false". A result of "false" means that an <ResourceAttributeDesignator> element for this named attribute will return an empty bag. If it cannot be determined whether the attribute is present or not present in the request context, or its value is unavailable, then the expression SHALL result in "indeterminate". o subject-attribute-is-present This function SHALL take two arguments. The first argument SHALL be an attribute value of type "xs:QName" as used in the "AttributeId" XML attribute of an <SubjectAttributeDesignator> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <SubjectAttributeDesignator> element. This expression SHALL result in "true" if the named attribute can be located in the request context. A result of "true" means that an <SubjectAttributeDesignator> element for this named attribute will return a bag consisting of at least one element. If no value can be found for the attribute in the request context, then this expression SHALL result in "false". A result of "false" means that an <SubjectAttributeDesignator> element for this named attribute will return an empty bag. If it cannot be determined whether the attribute is present or not present in the request context, or its value is unavailable, then the expression SHALL result in "indeterminate". o subject-attribute-is-present-where This function SHALL take three or more arguments. The first argument SHALL be an attribute value of type "xs:QName" as used in the "AttributeId" XML attribute of an <SubjectAttributeDesignatorWhere> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <SubjectAttributeDesignatorWhere> element. The third and subsequent arguments SHALL be <SubjectMatch> elements. This expression SHALL result in "true" if the named attribute named by "AttributeId" and "DataType" XML attributes can be located in the particular subject in the request context of which all the given <SubjectMatch> expressions evaluate to "true". A result of "true" means that a <SubjectAttributeDesignatorWhere> element for this named attribute and identical <SubjectMatch> elements will return a bag consisting of at least one element. If no value can be found for the attribute in the request context, then this expression SHALL result in "false". A result of "false" means that an <SubjectAttributeDesignatorWhere> element for this named attribute will return an empty bag. If it cannot be determined whether the attribute is present or not present in the request context, its value is unavailable, or any of the <SubjectMatch> elements evaluate to "indeterminate", then the expression SHALL result in "indeterminate". o evironment-attribute-is-present This function SHALL take two arguments. The first argument SHALL be an attribute value of type "xs:QName" as used in the "AttributeId" XML attribute of an <EnvironmentAttributeDesignator> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <EnvironmentAttributeDesignator> element. This expression SHALL result in "true" if the named attribute can be located in the request context. A result of "true" means that an <EnvironmentAttributeDesignator> element for this named attribute will return a bag consisting of at least one element. If no value can be found for the attribute in the request context, then this expression SHALL result in "false". A result of "false" means that an <EnvironmentAttributeDesignator> element for this named attribute will return an empty bag. If it cannot be determined whether the attribute is present or not present in the request context, or its value is unavailable, then the expression SHALL result in "indeterminate". o attribute-is-present This function SHALL take two arguments. The first argument SHALL be an argument of type "xs:string" that is an XPath expression that is used in the "RequestContextPath" XML attribute of the <AttributeSelector> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <AttributeSelector> element. This expression SHALL result in "true" if the value can be found. A result of "true" means that an <AttributeSelector> element for this named attribute SHALL return a bag consisting of at least one element. If no value can be found, then this expression SHALL result in "false". A result of "false" means that the corresponding <AttributeSelector> element SHALL return an empty bag. If it cannot be determined that a value for this XPath expression is present or not present, or the value is unavailable, then the expression SHALL result in "indeterminate". o attribute-must-be-present This function SHALL take two arguments. The first argument SHALL be an argument of type "xs:string" that is an XPATH expression that is used in the "RequestContextPath" XML attribute of the <AttributeSelector> element. The second argument SHALL be an attribute value of type "xs:QName" containing the identity of the data type as used in the "DataType" XML attribute of the <AttributeSelector> element. This expression SHALL result in "true" if the value can be found. A result of "true" means that an <AttributeSelector> element for this named attribute SHALL return a bag consisting of at least one element. If no value can be found, then this expression SHALL result in "false", which means that the corresponding <AttributeSelector> element SHALL return an empty bag, this expression SHALL result in "indeterminate". If it cannot be determined that a value for this XPath expression is present or not present, or the value is unavailable, then the expression SHALL result in "indeterminate". [Polar] Okay, I'm in trouble on this "*-is-present" stuff. In looking in the schema, I found out that I probably messed up the subject-attribute-*-present functions by not having an argument that states the value of the subject-category attribute. I also have a problem with the subject-attribute-*-present-where functions. I specify that they will take <SubjectMatch> elements as arguments in the <Apply>. However, that does NOT fit the evaluation strategy very well, as these elements return booleans, and to be consistent with the generic function application evaluation model, they should be evaluated independantly as arguments. Basically, they are evaluated without concern of being limited to the same subject. We somehow have to bring the evaluation of the equivalent of subject match into the function. So, unfortunately, because of multiple subjects, this approach complicates matters to no end for the function predicates that need to figure this out, as for subject-attribute-is-present-where I would have to specify something silly like: For each subject match we would add to the subject-attribute-is-present-where function, sets of four arguments, each of which the first is the MatchId, the second is the attribute name, the third is the data type, and the fourth is the matching value. (Yuch!) My conclusion: Since attributes are retrieved by different schema elements, it seems most logical to make their "is-present" counterparts schema elements as well, using much of the same machinery already in place. It would be easy to add these as element of the AttributeDeignator/Selector/Type complex types we ALREADY have defined: So, I think a better approach would be to add the following elements to the schema with the semantics I proposed in the previous iterations. These elements would be element instances of the <AttributeDesignatorType>: ActionAttributeIsPresent ActionAttributeMustBePresent ResourceAttributeIsPresent ResourceAttributeMustBePresent EnvironmentAttributeIsPresent EnvironmentAttributeMustBePresent These elements would be element instances of the <SubjectAttributeDesignatorType>: SubjectAttributeIsPresent SubjectAttributeMustBePresent These elements would be element instances of the <SubjectAttributeDesignatorWhereType>: These elements can be element instances of the <AttributeSelectorType>: AttributeIsPresent AttributeMustBePresent I can modify the document with Word97 and give these sections to the list if one would like? [Simon] I think that <AttributeDesignator> and <AttributeSelector> elements with mustBePresent attribute will cover all cases: <xs:complexType name="AttributeDesignatorType"> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="DataType" type="xs:QName" use="required"/> <xs:attribute name="MustBePresent" type="xs:boolean" use="required"/> <-- new attribute <xs:attribute name="Issuer" type="xs:anyURI" use="optional"/> </xs:complexType> <xs:complexType name="AttributeSelectorType"> <xs:attribute name="RequestContextPath" type="xs:string" use="required"/> <xs:attribute name="DataType" type="xs:QName" use="required"/> <xs:attribute name="MustBePresent" type="xs:boolean" use="required"/> <-- new attribute </xs:complexType> [Polar, responding to Simon] > I think that <AttributeDesignator> and <AttributeSelector> > elements with mustBePresent attribute will cover all cases: No, it won't. Thas is because I will not be able to write predicates about their presence, and only be able to get an "indeterminate" on requesting one. And also, again, in the Target, where these things appear, that attribute's semantics would complicate the idexing and retriveal of policies and rules etc etc etc. ================================================================== 0147: [Seth Proctor] Bug in pseudocode for Only One Applicable. e-mail sent 22 Oct 2002 13:56:29 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00249.html STATUS: APPROVED (NQ 10/28). Polar will reword. I think there is a bug in the pseudocode for the Only One Applicable Policy combining algorithm. The spec reads "If an error occurs while evaluating the target of a policy ... then the policy set SHALL evaluate to 'Indeterminate'." I think this is correct, but it's not expressed in the pseudocode. The code calls isApplicable() on the policy to see if the target matches, but there is no code to check if this call resulted in an error. Small issue, but I thought I'd mention it, since all the other combining algs can be implemented verbatim from the given pseudocode. ================================================================== 0148a: [Yassir Elley] Example two rules not applicable to request e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00251.html Example two specifies four separate rules, as well as a request context "to which the example rules are intended to be applicable." Unfortunately, none of the example rules are applicable to the request context that is specified. This should probably be fixed. ACTION ITEM: [Simon] Review and revise as needed. STATUS: (10/28) Waiting on Simon's review and/or revision. ================================================================== 0148b: [Yassir Elley] Include target-namespace in Request Context? e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00251.html As part of the Target, each of the rules includes a <ResourceMatch> of <ResourceAttributeDesignator AttributeId="urn:...:target-namespace" ...> Since "target-namespace" is not included as a Resource Attribute in the request context, none of the rules will ever match. Perhaps "target-namespace" should be included as a Resource Attribute in the request context. ACTION ITEM: [Simon] Review and revise as needed. STATUS: (10/28) Waiting on Simon's review and/or revision. ================================================================== 0148c: [Yassir Elley] Syntax of RequestContextPath not consistent e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00251.html Rules 1, 2, and 3 make use of an AttributeSelector as part of a Condition. The AttribueSelector has an XML attribute named RequestContextPath (RCP). The syntax of the RCP is inconsistent among the rules and should be made consistent. For example: Rule 1: RCP="//ctx:ResourceContent/md:record/" Rule 2: RCP="/ctx:Request//ctx:ResourceContent/md:record/" Rule 3: RCP="/ctx:Request/ctx:Resource/ctx:ResourceContent/md:record/" ACTION ITEM: [Simon] Review and revise as needed. STATUS: (10/28) Waiting on Simon's review and/or revision. ================================================================== 0148d: [Yassir Elley] Move "disjunctive sequence" up to higher element description e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00251.html In Section 5.6 (line 1951), it is somewhat strange that the explanatory text for <Subject> reads "A disjunctive sequence of <Subject> elements." This seems more appropriate for the <Subjects> element. This same pattern occurs with the explanatory text for <Resource> (line 2015) and <Action> (line 2078) ACTION ITEM: [Simon] Review and revise as needed. STATUS: (10/28) Waiting on Simon's review and/or revision. ================================================================== 0148e: [Yassir Elley] Editorial comments e-mail sent 22 Oct 2002 15:10:25 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00251.html STATUS: Editorial. No vote required. 1041: insert "//" (i.e. "http://www.medico.com";) 1049: insert "//" (i.e. "http://www.medico.com";) 1069: replace "[14]-[72]" with "[15]-[22]" 1085: Rule 1 states "A person may read any record for which he or she is the designated patient." In Example 4.2.4.1, however, the policy-number in the medical record is compared with the policy-number attribute of the subject. This is slightly confusing. 1107: replace "scheams" with "schemas" 1131: replace "xpath-match" with "xpath-node-match" 1184: replace "authorization decision request such, that the value" with "authorization decision request, such that the value" 1201: insert "the" before "explicit value" 1296: replace "xpath-match" with "xpath-node-match" 1346: "md:parentGuardianId" doesn't exist in example medical record. It should be added. 1541: "md:physicianId" doesn't exist in example medical record. There is however a "registrationId". These should be made consistent. 1600: replace "exampes:attributes:group" with "example:attribute:role" 1604: replace "read" with "write" 1675: replace "xpath-match" with "xpath-node-match" 1726: replace ""read"" with ""read" or "write"" 1933: remove duplicate "for the" 2225: insert ",action," after "resource" 2280: <SubjectAttributeDesignator> is missing 2333: replace "Shall" with "SHALL" 2384: replace "contains following attributes" with "contains the following attribute" 2434: insert "in" after "resulting" 2599: replace "Distingwished" with "Distinguished" 2704: replace "dn" with "DN" 3286: resource:resource-id is marked as Optional. Earlier, the spec specifies that "the <Resource> element MUST contain one and only one <Attribute> with AttributeId "urn:...:resource-id". This should probably be marked Mandatory, not Optional. 3920: replace "second" with "third" 4696: replace "CombinginAlogrithm" with "CombiningAlgorithm" ================================================================== 0149: [Seth Proctor] Environment attributes e-mail sent 23 Oct 2002 12:22:39 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00253.html STATUS: CLOSED (NQ 10/28). See RESOLUTION. RESOLUTION: If in original RequestContext from PEP, then use that. If has to be retrieved (i.e. "notional"), it is up to the implementation. The semantics are "Time that applies to the Request". It is up to the PEP to ask the right question. ORIGINAL CHANGE REQUEST: In section 10.3.5 of 18d, the spec calls out three attribute identifiers that the PDP must be able to handle specially (these are current-time, current-date, and current-dateTime). Is the idea that these would appear in an AD in a policy, and the PDP is supposed to know to resolve these values itself rather than looking in the Request? I think that's the idea, but it's not spelled out explicitly in the text. [Polar] I should believe that values for the current-time, current-date, and current-dateTime environmental attributes should be provided by the PEP, not the PDP. How can one force temporal evaluation schemes on the PDP for it to come up with values for these attributes? One has no control over the evaluation, especially if different pieces of the policy get evaluated at different times. It is completely up to an implementation. The client of the PDP, (i.e. a PEP) should be providing values for these attributes in the request context. The PDP should NOT supply them. Otherwise, you would get different answers for the same inputs given by the client (i.e. a PEP). In fairness to temporal reasoning, however, it is the onerous of the client, i.e. PEP, in accordance with XACML semantics, to give these attributes values that are considered valid with the temporal concerns of an access decision. Basic upshot: The current-time, current-date, and current-dateTime should be required to come from the request context. [Anne] Except that I believe we say explicitly that "current-time", etc. is the time at the PDP. How is the PEP supposed to know the time at the PDP? Maybe we need current-PDP-time, etc. and current-PEP-time, etc. :-) [Polar] The PEP is not supposed to know the time at the PDP. The PEP should fill those values with the time relavant to the access decision. The XACML writer expects those values to correspond with the time for which the access decision applies. [Daniel] Disagree. For time based policy having the time passed in is not always safe. If it is needed - it is easy to do, just add an attribute, but if you are going to have a build in time it has to be server side for auditing and safety. [Bill, responding to Polar] i agree. we should explicitly state this in the context description, spelling out that PEP passes *local* datetime information as azn request attributes. [Bill, responding to Daniel]...which means that policies writers will have to manually compensate for time (and date) variations. assuming that you have a PDP in the central timezone and a PEP on either coast, this presents something of a challenge. that alone negates any potential 'security' enhancement that may be provided through increased opportunity for author error. as to auditing, if all PDP transactions are timestamped by the PDP as part ot the logging process i don't see this an an impediment to centralized audits. any event can be mapped back to the point of request at the time of audit--a safer model in my mind. [Daniel] Attempt to elaborate: if we are to have a build-in standard time attribute it should be on PDP, otherwise it is hard to use it in a policy (if having a policy based on the time of decision is what you want). If you do not want to have a policy based on the time of decision, then we should probably let the implementation to decide when, where and how the relevant time is computed and placed into the context. If we see too many problems with "build-in" clock, I would agree to drop it altogether, although I think that some reference decision time clock is a useful feature (not only for decision, but also for such sanity checks, like not granting access three years in the future, or in the last century..).. [Daniel, responding to Bill] >...which means that policies writers will have to manually >compensate for time (and date) variations. assuming that you >have a PDP in the central timezone and a PEP on either coast, >this presents something of a challenge. that alone negates >any potential 'security' enhancement that may be provided >through increased opportunity for author error. Sure. There is no free lunch - if you want a "live" clock ticking somewhere, you got to be careful (and may want to use GMT time or something...) >as to auditing, if all PDP transactions are timestamped by the >PDP as part of the logging process i don't see this an an >impediment to centralized audits. any event can be mapped back >to the point of request at the time of audit--a safer model in >my mind. Unless you do want a policy tied to a live clock (and many applications do) and you want to connect the decision with the time stamp - so the auditing and ecision uses the exact same clock. I agree that it does open the can of worms - but occasionally you need'em to go fishing.. I would also agree to not include "live" clock anywhere at all. It can be done in an implementation if needed.. [Bill] i don't understand what you mean by a 'live clock'. can you explain, or give an example of a policy that needs a 'live clock'? [Mike Burati] >>which means that policies writers will have to manually >>compensate for time (and date) variations. assuming >that you >>have a PDP in the central timezone and a PEP on either coast, >>this presents something of a challenge. > > Sure. There is no free lunch - if you want a "live" clock > ticking somewhere, you got to be careful (and may want to use > GMT time or something...) Whether or not you have a PDP in a different timezone than PEP, you have to deal with dateTime values that may differ in Timezone (consider the scenario where a multinational or even just US-wide enterprise has policy admins/writers in multiple timezones even if they centralize their PDP in their IT headquarter's TZ and keep PEPs local to the systems they're protecting...). So, you likely already have to deal with converting/normalizing to a single timezone (eg, GMT) to do comparisons, even for a PDP/PEP within a single timezone, no? >as to auditing, if all PDP transactions are timestamped by the >PDP as part of the logging process i don't see this an an >impediment to centralized audits. any event can be mapped back >to the point of request at the time of audit--a safer model in >my mind. I agree - audit records created by a PDP should be timestamped using the PDP's clock, likewise for any audit records the PEP creates - use its clock. > I agree that it does open the can of worms - but occasionally > you need'em to go fishing.. > > I would also agree to not include "live" clock anywhere at > all. It can be done in an implementation if needed.. Which is a good reason to allow, but not require use of the timestamps, right? (other than for audit logs where I presume it would be required anyway). Speaking of a can of worms - for those who want to make ultimate use of timestamps in their authorization decisions: One option "if" the decision is made to stick with the PDP's clock for comparing against a policy timestamp, would be to allow use of a Kerberos-like PEP to PDP time-synchronization check where the PEP specifies that the PDP should evaluate the policy IFF the PDP's current-time is within a given (configurable) window of the PEP-current-time (normalized to GMT) included in the context (pardon the terminology - as I said, I'm a bit behind the curve on this one). Sure, it leads to lots of runtime errors if you don't synchronize your clocks (as I've seen lots of with Kerberos and DCE in the past even in small enterprises), but it does give you the "option" of having both the PEP's clock and PDP's clock contribute to the evaluation for those that can't agree which is the correct choice. [Daniel, responding to Bill] >i don't understand what you mean by a 'live clock'. can you >explain, or give an example of a policy that needs a 'live >clock'? Dumb example: if you control access to the building, that have a thousand doors, you do not want each lock to send in its own time in a request. Nor you need permission to open the door in the future on in the past. One need to enter right now, and that "now" must be determined during the evaluation.. Only then policy writer can guarantee that nobody gets in in the wrong time.. "Live" clock is something that is guaranteed to be the same in any evaluation context, independent of the request.. [Polar, responding to Daniel] > Disagree. For time based policy having the time passed in is > not always safe. Well, for time based (or time critical?) policy as you suggest, you would make sure that your PEP to PDP configuration was as "real-time" as you could make it. That would mean that the PEP would supply the time of the access decision, and your evaluation strategy of the PDP would process within your realtime constraints. > If it is needed - it is easy to do, just add an attribute, > but if you are going to have a build in time it has to be > server side for auditing and safety. For auditing and safety, your PDP could check to see if the time supplied in the request is within acceptable constraints before and/or after the decision is processed. This approach is common in authentication mechanisms, such as Kerberos. You also may want to ask about access decisions that are not of the actual current time, but at some time in the future. For example, as a pure client of a PDP, you may want to know if A has access to R five minutes from now, such that the decision governs how a request gets processed. To make sense of that, the policy must be written as if it were processing the given time as the current time. Alternatively, to address your time based policy approach, the PEP may not supply the time, but the "request context builder" would. Being that the request context is this a "notion" more than it is a concrete request structure, we can just state that the current time is supplied in the request context. However, whenever the PDP it asks for the current-time attribute, it gets it from the request context, and the request context builder can assign that attribute the current time at that moment, just as if were a "weight" attribute pulled from Daniel's database. However, I would suggest, once it is assigned it doesn't change during the evaluation! So, in implemenation the values given to the current time attributes can be as static and dynamic as you want it to be. And in the standard, having it come from the request context addresses both concerns, without much problem. Having the PDP generate current-time on the fly isn't much good if policies take a long time to evaluate and you cannot guarrantee when they are evaluated, and doesn't address being able to ask access decisions about the future or even the past. "Was John allowed in the building at 6pm yesterday?" Also, for analysis and testing to make sure that the policy is doing what you think it ought to do: Can "Employees get in the building at 7pm tonight"? [Anne, responding to Daniel] I think most "auditing" will be done by the PEP. The PEP is the entity that must enforce the access decision, and the PDP must trust the PEP to supply correct attributes and to do the enforcement. The PDP is just an "evaluation engine": given request and policy, provide decision. [Daniel, responding to Anne]..given request and policy and CONTEXT, which very well may include global parameters independent of an individual request.. Also, auditing is best done where the decision is made, not were it is used, as auditing may include information not returned to PEP (such as a reason for DENY).. [Polar, responding to Daniel] > ..given request and policy and CONTEXT, which very well may > include global parameters independent of an individual > request.. > > Also, auditing is best done where the decision is made, not > were it is used, as auditing may include information not > returned to PEP (such as a reason for DENY).. Well, "best" is only an opinion which depends upon the application, and the auditing that is required for that application. The decision, itself could have been made weeks ago. Actually when you write the policy, you've have *already* made the decision. ================================================================== 0150: [Seth Proctor] Types of pre-defined attributes e-mail sent 23 Oct 2002 12:22:39 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00253.html STATUS: CLOSED. SUPERSEDED BY 0134c. (Q 10/24). ...these go on that list I started earlier of attributes that should be defined to always be of a particular type: subject-category string or URI resource-id string or URI scope string current-time ??? current-date date current-dateTime dateTime Since each of these identifiers must be special-cased by the PDP, they must always be of a known type. There may be others that should be on this list, but most of the other identifiers are not treated in any special way by the PDP, so the type information is transparent to the PDP. ================================================================== 0151: [Seth Proctor] editorial: 10.3.6 extraneous paragraph e-mail sent 23 Oct 2002 14:38:32 -0400 http://lists.oasis-open.org/archives/xacml/200210/msg00254.html STATUS: Editorial. No vote required. In section 10.3.6, the 2nd paragraph isn't needed, since it's the same as the first two sentences of the 1st paragraph. ================================================================== 0152: [Tim Moses] Trivial Matter e-mail sent 28 Oct 2002 09:31:24 -0500 http://lists.oasis-open.org/archives/xacml/200210/msg00285.html STATUS: Not yet considered. We should call the <SubjectAttributeDesignatorWhere> element <SubjectQualifier>. If you need further convincing, read on. I recognize at least two styles for naming elements, attributes, etc.: the "descriptive" style and the "literate" style. In the "descriptive" style, the name is chosen in an attempt to reflect the semantics of the element. In the "literate" style, the name is chosen in an attempt to make the "source" "read". I contend that we have almost exclusively chosen the descriptive style. Consider the XML attribute "FunctionId". If we had been following the literate style, we would have chosen the name "Function". Then the Apply element would read ... <Apply Function ... instead of ... <Apply FunctionId ... I think either style would be acceptable (although both Polar and I have declared that we never want to read an XACML policy in its native form). But, I would like us to be consistent in our application of a single style. Therefore, I propose that we use the descriptive style of naming and that we choose <SubjectQualifier> instead of <SubjectAttributeDesignatorWhere>. It has the additional benefit of being half the size. I also considered <SubjectSelector>, but thought that was too similar to <SubjecAttributeSelector>.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC