[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Committee Specification vote/Updated Change Requests
The current list of Voting Members from the XACML TC Web Page, along with current indications of whether people plan to attend are: Voting Members ======================================= Y Ken Yagen, Crosslogix Y Daniel Engovatov, Crosslogix Hal Lockhart, Entegrity Y Carlisle Adams, Entrust Y Tim Moses, Entrust Y Don Flinn, Hitachi Y Konstantin Beznosov, Hitachi Y Michiharu Kudoh, IBM Steve Anderson, OpenNetwork Simon Godik, Overxeer Y Bill Parducci, Overxeer Y Polar Humenn, Self Suresh Damodaran, Sterling Commerce Y Anne Anderson, Sun Microsystems N/A Piras Vilandai Thiyatarajan, Sun Microsystems Y Gerald Brose, Xtradyne Piras resigned, so he should not be counted. Simon and Hal probably just have not had a chance to respond yet - I can't imagine they would not be on this call :-) But, even without Simon and Hal, we have 11 out of 15 members who have positively indicated that they WILL be present. So unless we get some unexpected NO votes, I think we could vote for Committee Specification on 7 November as long as we can resolve the remaining issues in time for Simon and Tim to issue the "Final Draft" by close of business on Wednesday. Attached is a new Change Requests list, containing only the unresolved Change Requests. A couple of these we probably don't have to resolve before public review. But I want everyone to be aware of what remains. In particular, could people respond to the two proposed resolutions to "0162: [Polar] [Schema/Text Change] Subjects", since that is the immediate sticking point. 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 5 Author: Anne Anderson Version: 1.2, 02/11/05 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests5.txt This file contains all Change Requests not fully resolved as of 5 November 2002. See http://lists.oasis-open.org/archives/xacml/200210/msg00214.html and http://lists.oasis-open.org/archives/xacml/200211/msg00029.html for previous Change Requests against v0.18c.doc that have been resolved. Includes e-mail up through http://lists.oasis-open.org/archives/xacml/200211/msg00067.html ============================================================= CHANGE REQUESTS 1.SUMMARY ========= 1.1 ACTION ITEMS ================ 0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes ACTION ITEM: [Polar] Update RESOLUTION text based on resolution to CR#0146 1.2 UNRESOLVED ============== Note: 92, 156, 154, and 162 are inter-twined. 0092: [Polar] [Text Change] PH09: New section 7.4.2 Attributes STATUS: UNRESOLVED. Waiting for CR#0146(11/4) See RESOLUTION. 0146: [Polar] CR 144: function "present" needs to be fixed. STATUS: UNRESOLVED (11/4). Need semantics in QualifiedSubjectAttributeDesignator. 0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere STATUS: UNRESOLVED. See partial RESOLUTION and OPEN ISSUE (NQ 11/4) 0156: [Seth Proctor] ObligationType STATUS: UNRESOLVED 0157: [Steve Hanna] Glitch in moving from decimal to double STATUS: UNRESOLVED 0162: [Polar] [Schema/Text Change] Subjects STATUS: UNRESOLVED. 1.3 RESOLVED IN SUBCOMMITTEE, BUT NEED QUORUM VOTE ================================================== 0134c: [Seth Proctor] Need Datatypes for each defined AttributeId STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). See RESOLUTION. 0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). Use xs:string" in both places. 0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See RESOLUTION. 0158: [Simon] [Schema Change] Redefine <AttributeValueType> STATUS: NEEDS QUORUM. APPROVED (NQ 11/4) 0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST. 0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST. 0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn" STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST. 1.4 RESOLVED ============ None ========================================================================= 2. DETAILS ========================================================================= 0092: [Polar] [Text Change] 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 ACTION ITEM: [Polar] Update RESOLUTION text based on resolution to CR#0146 STATUS: UNRESOLVED. Waiting for CR#0146(11/4) See RESOLUTION. SEE ALSO: CR#0146 RESOLUTION: This draft resolution was accepted in general (Q 10/31), but it needs to be updated based on the resolution to CR#0146: - Impact of MustBePresent XML attribute - Impact of missing attributes in a given <Subject> block in evaluating QualifiedSubjectAttributeDesignator. TEXT LOCATION: Section 7.9 "Attributes" (v0.18e.doc) TEXT CHANGE: Replace current 7.9 with following: [I have updated following with section#'s from v0.18e.doc. Tim has already incorporated much of this. -Anne] 7.9 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 context attribute specifies an AttributeId and a DataType. Each attribute desigator specifies an AttributeId and DataType. Attribute designators SHALL match attributes by using string equality on both the AttributeId and DataType values. Each attribute selector specifies a DataType and an XPath expression. Attribute selectors SHALL match attributes by using the XPath expression and string equality on the DataType values. 7.9.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. 7.9.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.10 "Authorization decision". However, the PDP MAY choose not to issue such information due to security concerns. DISCUSSION: [Seth] Given the original text quoted above, an AD/AS will always return a bag, which is always an error to most of the standard functions, unless a bag with only one element is considered to be the same as a single instance of just the element inside the bag. The text change clarifies this. Long discussion questioning rejection of resolution#2. Simon clarified intent of the TC as follows: 1) Must wrap an AttributeDesignator with *-one-and-only function to convert a bag into a single value, or else must use AnyOf higher-order function. 2) Yes, the TC considered the "simplicity" of "implicit" type conversion, but felt type consistency was more important. There may be a performance overhead, but implementations must deal with this. 3) if new type is defined every type-* function must be defined as well Polar provided following example of use "anyOf": <Apply FunctionId="function:AnyOf"> <Function FunctionId="function:string-equal"> <AttributeValue Datatype="....#string">Hello World</AttributeValue> <AttributeDesignator ....../> </Apply> This structure explictly states that if indeed the AttributeDesignator returns more than one value, it is your *explicit intent* that the boolean is true for any of the returned values. [Polar, responding to Daniel] > In this particular example, *-is-in can be used as well. The any-of must take a function that has the type: (a -> a -> Boolean) The type of *-is-in is ( a -> [a] -> Boolean), where a is a primitive type, such as the type of function:string-is-in is: (String -> [String] -> Boolean). An application of string-is-in would be: <Apply FunctionId="function:string-is-in"> <AttributeValue DataType="....#string">Hello World<AttributeValue> <AttributeDesignator ....../> </Apply> [Polar, responding to Simon] > functions that do not take attribute bags as arguments do not > care about empty bags. Untrue. An or function, for instance, is supposed to go through a list of inputs until it finds a true value. If one of those inputs fails to find any values, and the MustBePresent attribute is false, then an empty bag is returned. This is done precisely so that the function may skip over that input and continue on (whereas it might choose to do something different in an error case). Functions that do not take attribute bags as arguments may still need to recognize the special case of an empty bag. [Seth, responding to Polar] Yes, I understand how anyOf is used, but it means that you can't nest Apply blocks that have functions that expect single values. Ie, in the example you give > <Apply FunctionId="function:AnyOf"> > <Function FunctionId="function:string-equal"> > <AttributeValue Datatype="....#string">Hello World</AttributeValue> > <AttributeDesignator ....../> > </Apply> I know that there was one match to the value "Hello World" but I don't get back that value, I get a boolean value instead. If I have an add function that is inside of a floor function (for instance), I can't use anyOf to somehow make sure that bags with only one value get handled correctly by the functions, since I want to need to have the add function return a number, not a boolean. The comment in the change request was that anyOf can somehow be used to solve this, and my point is that it cannot. [Polar, responding to Seth] For the capability you allude to below you use the map function; <Apply FunctionId="function:map"> <Function FunctionId="function:double-floor"> <AttributeDesignator DataType="....#double" ....../> </Apply> =================================================================== 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 STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). See RESOLUTION. SEE ALSO: CR#0150 RESOLUTION: Each "standard attribute" should have a "standard datatype", since we proposed them for interoperability in the first place. See http://lists.oasis-open.org/archives/xacml/200210/msg00290.html for attachment containing XACML_identifiers.doc, which is Simon's proposed list. Simon has revised this to reflect all e-mail comments received, and sent the revised version to Tim for inclusion in v0.18f.doc CHANGE REQUEST: 10.3.6 (Identifiers) doesn't list the type of any these attributes, nor does it give the required uses for them that it says implementors must follow. I realize this is transparent to a lot of the code, and only one of these is required to support, but it would still be helpful to know what type they're supposed to be (if there is a certain expected type). Later in the spec they're explained in a little more detail, but not enough to make the strong language in this section about correct implemention make sense. DISCUSSION: [Anne] Comments on Simon's proposed DataTypes: - subject-category:codebase: this should be anyURI (it is usually a URL) - subject-category:requesting-machine o we should have two requesting machine categories: requesting-machine-ip-address requesting-machine-dns-name o then both can be xsi:string - subject:subject-id: we can't say the "default is xsi:string" since DataType is required. - subject:subject-category: should be anyURI (see list in B.2 - they are all URNs) - subject:subject-id-qualifier: SAML says type not specified. I suggest we let DataType specify the type or else say anyURI - subject:authentication-method: SAML uses anyURI, I suggest same - resource:resource-id: description says "This identifier indicates the entire URI of the resource." I believe this should say "This identifier indicates the name of the resource." I think we need to let DataType determine the type (it might be a string, it might be a URL, it might be a URN, etc.) - action:actionNamespace: should be anyURI to fit with SAML's use ================================================================== 0146: [Polar] CR 144: function "present" needs to be fixed. e-mail sent 22 Oct 2002 12:25:52 -0400 (EDT) http://lists.oasis-open.org/archives/xacml/200210/msg00247.html http://lists.oasis-open.org/archives/xacml/200211/msg00032.html STATUS: UNRESOLVED (11/4). Need semantics in QualifiedSubjectAttributeDesignator. SEE ALSO: CR#0092,CR#0154 RESOLUTION: Make new XML elements in schema. Remove them from Appendix A, put them in text description. New proposal removes all the -must-be-present functions, since new XML attribute on attribute designator can do that. SPECIFIC RESOLUTION: See revised text in http://lists.oasis-open.org/archives/xacml/200210/msg00313.html (MSWord) or http://lists.oasis-open.org/archives/xacml/200210/msg00314.html (pdf) CHANGE REQUEST: 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. DISCUSSION: .... (outdated discussion removed) 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 [Simon] I think that <AttributeDesignator> and <AttributeSelector> elements with mustBePresent attribute will cover all cases: [Polar, responding to Simon] 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. ================================================================= 0153: [Polar] Issuer is xs:string in Context/xs:anyURI in policy e-mail sent 29 Oct 2002 13:26:55 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200210/msg00293.html STATUS: NEEDS QUORUM. RESOLVED (NQ 11/4). Use xs:string" in both places. CHANGE REQUEST: The Issuer is an "xs:string" in the context, and "xs:anyURI" in the policy. (I am looking at 16j) ================================================================= 0154: [Seth Proctor] [Schema/Text Change] SubjectQualifier/SubjectAttributeDesignatorWhere e-mail sent 30 Oct 2002 15:22:32 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200210/msg00305.html STATUS: UNRESOLVED. See partial RESOLUTION and OPEN ISSUE (NQ 11/4) SEE ALSO: CR#0092, CR#0146, CR#0152 OPEN ISSUE: 1) How to deal with missing attributes when evaluating a QualifiedSubjectAttributeDesignator. If MustBePresent="true" on SubjectAttributeDesignator inside the new <SubjectQualifier> element, does this mean that every single <Subject> MUST contain an instance of that Attribute or else the QualifiedSubjectAttributeDesignator returns Indeterminate? This is the same issue being addressed in CR#0092. 2) If multiple <Subject> blocks match the QualifiedSubjectAttributeDesignator, then how does Policy know which returned attributes go with which <Subject>? RESOLUTION: On 11/4, we agreed on the following changes to address the original Change Request. 1) Replace all existing policy schema references to "SubjectAttributeDesignator" with "CategorizedSubjectAttributeDesignator" 2) After doing 1), add the following fragment to the policy schema: <xs:element name="SubjectAttributeDesignator" type="xacml:AttributeDesignatorType"/> 3) After doing 2), replace following policy schema fragment: <xs:element name="SubjectAttributeDesignatorWhere" type="xacml:SubjectAttributeDesignatorWhereType"/> <xs:complexType name="SubjectAttributeDesignatorWhereType"> <xs:complexContent> <xs:extension base="xacml:AttributeDesignatorType"> <xs:sequence> <xs:element ref="xacml:SubjectMatch" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> with <xs:element name="QualifiedSubjectAttributeDesignator" type="xacml:QualifiedSubjectAttributeDesignatorType"/> <xs:complexType name="QualifiedSubjectAttributeDesignatorType"> <xs:complexContent> <xs:extension base="xacml:AttributeDesignatorType"> <xs:sequence> <xs:element ref="xacml:SubjectQualifier" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="SubjectQualifier type="xacml:SubjectQualifierType"/> <xs:complexType name="SubjectQualifierType"> <xs:sequence> <xs:choice> <xs:element ref="xacml:SubjectAttributeDesignator"/> <xs:element ref="xacml:AttributeSelector"/> <xs:choice> <xs:element ref="xacml:AttributeValue"/> </xs:sequence> <xs:attribute name="MatchId" type="xs:QName" use="required"/> </xs:complexType> CHANGE REQUEST: I think there's a problem with the schema involving the SubjectAttributeDesignatorWhere (or the proposed name SubjectQualifier, which I like more). It used to extend SubjectAttributeDesignatorType, but with the addition of the category element, it now only extends AttributeDesignatorType. It still contains, however, a list of SubjectMatchType, which in turn use SubjectAttributeDesignatorType as their designator. Shouldn't the match elements also extend AttributeDesignatorType and not SubjectAttributeDesignatorType in the SubjectQualifier? I think this needs a new match type that uses AttributeDesignator but is specified in the spec to look in the subject section of the request for all attributes. DISCUSSION: [Polar] In writing the stuff for the subjects, I've encountered a problem for the QualifiedSubjectAttributeDesignator. I think Seth was onto something in 0154 and 0155, but perhaps missed it a bit. The SubjectAttributeDesignator takes AttributeId, DataType, MustBePresent, and SubjectCategory. It restricts the lookup of the named subject attributes to the <Subject> matching the SubjectCategory. The QualifiedSubjectAttributeDesignator performs no such category restriction. It just takes AttributeId, DataType, MustBePresent, plus a bunch of <SubjectMatch>. The <SubjectMatch>s are supposed to be restricted to one subject. The only problem is that each SubjectMatch has an SubjectAttributeDesignator in it, which *ALREADY* restricts the look up to a particular subject matching the subject category. So, as a result, a QualifiedSubjectAttributeDesignator must have SubjectMatches all with the SAME subject category, or it wont retrieve anything. Also, having one SubjectMatch restricts it already to one Subject just by virtue of the category, which I think is not the case we want. [Polar] I suggest that we change the current SubjectAttributeDesignatorType to CategorizedSubjectAttributeDesignatorType and have CategorizedSubjectAttributeDesignator and keep the SubjectAttributeDesignator a simple instantiation of AttributeDesignatorType as it was before we added the SubjectCategory attribute. [Seth, responding to Polar] Is the intent to add a new AD type to those allowed in an Apply, and therefore also create a new MatchType? This might be overkill, though it could be useful. ================================================================= 0155: [Seth Proctor] Name for match element inSubjectQualifier/SubjectAttributeDesignatorWhere e-mail sent 30 Oct 2002 15:28:10 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200210/msg00306.html STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See RESOLUTION. SEE ALSO: CR#0154 RESOLUTION: See #0154. The name of the sequence of elements inside the QualifiedSubjectAttributeDesignator/SubjectAttributeDesignatorWhere is changed from SubjectMatch to SubjectQualifier. CHANGE REQUEST: This is a followup to my last email on Match types in the SubjectQualifier ([xacml] Problem in SubjectQualifier/SubjectAttributeDesignatorWhere). If I'm right, and that structure needs to change, I would like to request that it not have the same name as the other match objects (ie, it should not be called something that looks like SubjectMatchType). While it is similar in structure to the other match types, the "match" elements used in the qualifer are symantically an entirely different thing, and should therefore be logically separated by using a different name, and should not be covered by the same explanitory text in the spec. ============================================================================= 0156: [Seth Proctor] ObligationType e-mail sent 31 Oct 2002 10:15:16 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200210/msg00312.html STATUS: UNRESOLVED CHANGE REQUEST: The ObligationType used to have a choice between an AttributeAssignment or an AttributeDesignator, but now you can only have the AA. As such, the xs:choice should probably be changed to xs:sequence, just to stay consistent with schema language. ================================================================= 0157: [Steve Hanna] Glitch in moving from decimal to double e-mail sent 31 Oct 2002 13:08:08 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200210/msg00315.html STATUS: UNRESOLVED CHANGE REQUEST: I see that v18e reflects the TC's decision to move from xsi:decimal to xsi:double. I'm pleased with this decision, but I noticed a problem: The document cited as defining the arithmetic functions ([IBMSDA]) does not exist. Or at least the URL given in the document (http://www2.hursley.ibm.com/double/decarith.html) does not work. I suspect that this is the result of a global search and replace operation, changing decimal to double. I suggest that this reference be replaced with IEEE 754, which defines binary floating point arithmetic and is cited by XML Schema for that purpose. ================================================================= 0158: [Simon] [Schema Change] Redefine <AttributeValueType> raised during Subcommittee call on 11/4/02 STATUS: NEEDS QUORUM. APPROVED (NQ 11/4) RESOLUTION: 1) In the context schema, replace following: <xs:element name="AttributeValue" type="xs:anyType"/> with: <xs:element name="AttributeValue" type="xacml-context:AttributeValueType"/> <xs:complexType name="AttributeValueType"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> 2) In the policy schema, replace following: <xs:complexType name="AttributeValueType"> <xs:complexContent> <xs:extension base="xs:anyType"> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> with: <xs:complexType name="AttributeValueType"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> CHANGE REQUEST: Define <AttributeValueType> in both the policy and the context schemas in the same way that context:ResourceContent is now specified. RATIONALE: Validating parsers are happier with this way of specifying an "any" type> ================================================================= 0159: [Anne] [Text Change] Appendix B: Describe XACML attributes better e-mail sent 01 Nov 2002 11:56:332 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200211/msg00000.html STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST. CHANGE REQUEST: 1. B.5 Subject attributes: Change initial paragraph from: "These identifiers indicate attributes of a subject. At most one of each of these attributes is associated with each subject. Each attribute associated with authentication relates to the same authentication event. To: "These identifiers indicate attributes of a subject. When used, they SHALL appear within a <Subject> element of the Request Context. They SHALL be accessed via a SubjectAttributeDesignator, a QualifiedSubjectAttributeDesignator, or an AttributeSelector pointing into a <Subject> element of the Request Context. At most one of each of these attributes is associated with each subject. Each attribute associated with authentication included within a single <Subject> element relates to the same authentication event. 2. B.6 Resource attributes: Add introductory sentence saying: "These identifiers indicate attributes of the resource being accessed. When used, they SHALL appear within the <Resource> element of the Request Context. They SHALL be accessed via a ResourceAttributeDesignator or an AttributeSelector pointing into the <Resource> element of the Request Context." 3. B.7 Action attributes: Add introductory sentence saying: "These indentifiers indicate attributes of the resource being accessed. When used, they SHALL appear within the <Action> element of the Request Context. They SHALL be accessed via a ActionAttributeDesignator or an AttributeSelector pointing into the <Action> element of the Request Context." 4. B.8 Environment attributes: Add introductory sentence saying: "These identifiers indicate attributes of the environment within which the request is to be evaluated. When used, they SHALL appear within the <Resource> element of the Request Context. They SHALL be accessed via an EnvironmentAttributeDesignator or an AttributeSelector pointing into the <Environment> element of the Request Context." RATIONALE: the way in which these attributes are to be used is not explicitly stated anywhere. While the names imply a usage, it would be more clear to implementors if the usage were more explicit. ================================================================= 0160: [Anne] [Text Change] Appendix B: Describe XACML attributes better e-mail sent 01 Nov 2002 12:45:10 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200211/msg00001.html STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST. CHANGE REQUEST: (Example revised per Polar e-mail and 11/4 discussion) In Section A.3 Structured types, item 1., paragraph starting with "1, change second sentence from: "This requires the structured data, including its tags and attributes, to be identified and treated as an instance of the data-type xsi:string." To: "This requires the structured data <AttributeValue> to be given the DataType="xsi:string". For example, a structured data type that is actually a ds:KeyInfo/KeyName would appear in the Context as: <AttributeValue DataType="DataType="http://www.w3.org/2001/XMLSchema-instance#string"><ds:KeyName>jhibbert-key</ds:KeyName></AttributeValue> RATIONALE: Way#1 could be read as implying that the structured data type is automatically cast or converted to the type required by the function that references it. We should be very clear that this does NOT occur. DISCUSSION: [Anne, responding to Polar] > Now, if you do not regard the data as a string, and you actually give > it a data type, i.e. extension to standard XACML, I wonder what happens > for the following problem. > > Does the data within the attribute value have to be completely contained? > > For example, if you have <ds:KeyName>jhibberi-key</ds:KeyName> where is > the "ds:" name space defined? (In the begining of the context? of which it > cannot be guarranteed to be there) Or in the attribute value? The ds: name space must be defined in the beginning of the context if "ds:" is used in an XML fragment. If it is not defined there, then there will be an error parsing the XML context. ================================================================= 0161: [Anne][Schema Change] editorial: "FulfillOn", not "FulfilOn" e-mail sent 01 Nov 2002 12:52:45 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200211/msg00002.html STATUS: NEEDS QUORUM. APPROVED (NQ 11/4). See CHANGE REQUEST. CHANGE REQUEST: In policy schema, <xs:complexType name="ObligationType">, change <xs:attribute name="FulfilOn" to <xs:attribute name="FulfillOn" RATIONALE: Spec uses "FulfillOn", and we decided in a TC meeting to use that spelling. Schema just has not been brought into agreement yet. ================================================================== 0162: [Polar] [Schema/Text Change] Subjects e-mail sent 04 Nov 2002 16:43:06 -0500 (EST) http://lists.oasis-open.org/archives/xacml/200211/msg00032.html http://lists.oasis-open.org/archives/xacml/200211/msg00037.html (schema) STATUS: UNRESOLVED. CHANGE REQUEST: Using QualifiedSubjectAttributeDesignators where there are multiple <Subject> elements, particularly where multiple <Subject> elements have the same subject-category means you may get back multiple attribute values without knowing which <Subject> element they came from. RESOLUTION#1: Make the subjects (i.e. lists of attributes) unique to the category, and use the present SubjectAttributeDesignator (with the SubjectCategory part) and get rid of the SubjectAttributeDesignatorWhere. That's simple and I think everybody can get their brains wrapped around that. RESOLUTION#2: See http://lists.oasis-open.org/archives/xacml/200211/msg00066.html which contains revised Section 5. General description of proposed resolution: Eliminate the SubjectCategory from the SubjectAttributeDesignator and add the SubjectQualifiers to the SubjectAttributeDesignator. A SubjectQualifier extends a AttributeDesignator with the following attributes "MatchId" and a "AttributeValue" element. This approach allows you to qualify the SubjectMatch in the target to any category or any other attribute. The only thing that remains a problem for targeting is the MustBePresent, as before. Next extend QualifiedSubjectAttributeDesignator SubjectAttributeDesignator with a "FromSubjects" attribute of which its default value is "single-subject", as opposed to "multiple-subjects". Only QualifiedSubjectAttributeDesignators are allowed to be Expressions. If the FromSubjects attribute is set to single-subject and multiple subjects match, the expression raises an indeterminate. QualifiedSubjectAttributeIsPresent extends SubjecAttributeDesignator with a "MustBeSingleSubject" attribute. If MustBeSingleSubject is set to "true" and the qualifiers select zero or more than one subject, then the answer is false. Otherwise, it returns the true if the attribute is within that selected subject. A true result with MustBeSingleSubject set to true means that the attribute is present and a QualfiedSubjectATtributeDesignator with FromSubjects=single-subject will not raise an indeterminate. DISCUSSION: [Anne] In a <Target>, we currently allow one or more SubjectMatch elements, each of which contains a MatchId, a SubjectAttributeDesignator/AttributeSelector and an AttributeValue. Under your proposal, I think "Example" [deleted, since it was actually not valid] below is a valid <Target>, meaning: there must be at least one <Subject> element in the Request where all of the following are true: by first SubjectMatch: the xxx AttributeId has a value of "ghi" the yyy AttributeId has a value of "abc" the zzz AttributeId has a value of "def" by second SubjectMatch: the aaa AttributeId has a value of "qrs" the bbb AttributeId has a value of "jkl" the ccc Attributeid has a value of "mno" What do we gain over having multiple <SubjectMatch> elements, each with a single AttributeDesignator and value to be matched? [Polar, responding to Anne] I think the answer to your question, is that Multiple Subject matches must match any subject and they are not related to each other. That is one SubjectMatch has nothing to do with the subjects matched in another. The SubjectMatch with a SubjectAttributeDesignator matches on a restricted set of subjects. [Polar, responding to Simon] > I'm trying to understand your proposal. what you do is: > attr-desig-type(attrid, data-type, issuer, must-be-present) > subject-qualifier(match-id, attr-value) > subj-attr-desig-type(0...many subj-qualifier) > qualified-subj-attr-desig(from-subjects) Yes. (I think) > then qualified-subj-attr-desig is used in the subject-match in the target > and in the apply element. > > it looks like subj-attr-desig-type is not used by itself. Correct. It's only used for extenstion to QualifiedSubjectAttributeDesignator and QualfiiedSubjectAttributeDesignatorIsPresent. > subject expression in the target is now quite complicated. You still had to match on a subject category attribute. That is no different on matching on any other named attribute, really. The only thing, is now that you may have more qualifying it in an AND, of which I don't think is that bad. (i.e match me all subjects that have weight = 100 with subject-category = access-subject, and role = doctor. Indexing can still prevail. [Polar, responding to Anne] > But all matches within a single <Target><Subject> must pertain to > one Request <Subject>. If you want to specify subject matches > that are not related to that <Subject>, then you use another > <Subject> element in your <Target>. Right, I forgot that. Anyway, that suffers from the same misleading problem, doesn't it? It means the "subjects" for which the subject matches apply. [Polar, responding to Simon] > We have an open issue with subject designators that we want > to solve asap. There is a proposal from Polar, but I think > it is too complicated for quick adoption. > > My proposal: > a) Quick solution to vote on thrs: Keep current > subject-attribute-designator element with subject-category > attribute and use it in the target and apply > elements. Drop subject-attr-desig-where. I think it will > cover 95% of all cases. I wouldn't mind this, except for having multiple subjects for a category! It just balls everything up. I cannot tell which subject my attributes are comming from. That really bothers me. I think we have screwed this whole thing up with multiple subjects requirement and not understanding the ramifications of the queries on them. In my latest proposal, I've added complex attributes to the elements to pop up indeterminates in the case where you get multiple subjects matched. I don't really like that solution. But I made the analogous IsPresent operator use another attribute so that it returns false if the Qualifiers select more than one subject. This also complicates the SubjectMatch in that it has to throw an indeterminate when the designator qualifies multiple subjects. Yuck! I hate it. > b) Work out alternative proposal and delay voting until it is > resolved I think a better more workable solution would be to make the subjects (i.e. lists of attributes) unique to the category, and use the present SubjectAttributeDesignator (with the SubjectCategory part) and get rid of the SubjectAttributeDesignatorWhere. That's simple and I think everybody can get their brains wrapped around that. I think this approach will solve 95% of the simple cases as well. And let's wait to 1.1 or 2.0 to get multiple subjects down. It's already bad enough with multiple subject categories. Geeezzz! [Simon, for RESOLUTION#1] +1 I would support [Polar's "better more workable solution above] [Anne, for RESOLUTION#1] > I think a better more workable solution would be to make the subjects > (i.e. lists of attributes) unique to the category, and use the present > SubjectAttributeDesignator (with the SubjectCategory part) and get rid of > the SubjectAttributeDesignatorWhere. That's simple and I think everybody > can get their brains wrapped around that. I can live with this. What we lose is the ability to associate attribute values with the identities and authentication methods under which those attributes were issued. We can continue to try to improve this for 1.1 or 2.0. I really think we are going to need some serious thought to solve the problems raised by SADWhere, and I would rather have a good solution than a complex, understudied, possibly unworkable one. [Carlisle, for RESOLUTION#1] This is my vote as well: something workable in most cases for 1.0; something fancier for 1.1 / 2.0.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC