3. [Anne] Optional <Target> in Rule (since often same as Policy)
http://lists.oasis-open.org/archives/xacml/200207/msg00011.html Options: a. Optional <Target> in Rule (already optional in 15g): semantics ::= "match" b. Define <Target> to be a choice 1. urn:oasis:...:anyTarget, or 2. <Subject>...</Subject>,<Resource>...</Resource>,... and use 1. for this case. c. Use <Subject>urn:oasis:...:any</Subject>, <Resource>urn:oasis:...:any</Resource> for this case. CLOSED: it is optional in v15. Semantics are that a Rule "inherits" the Target of the Policy that references or includes it if the Rule has no Target of its own. 16. [Anne] Target matching syntax and semantics
http://lists.oasis-open.org/archives/xacml/200207/msg00018.html [Michiharu response]
http://lists.oasis-open.org/archives/xacml/200207/msg00032.html [Michiharu new response]
http://lists.oasis-open.org/archives/xacml/200207/msg00050.html [Tim] new Target schema
http://lists.oasis-open.org/archives/xacml/200207/msg00055.html [Michiharu]
http://lists.oasis-open.org/archives/xacml/200207/msg00061.html [Daniel]
http://lists.oasis-open.org/archives/xacml/200207/msg00062.html CLOSED: In a single AttributeDesignator in a Target element, at least one returned node must match the target value. If a Target element includes more than one AttributeDesignator, then each AttributeDesignator must have at least one returned node that matches its target value. OPEN: We will study Michiharu's new response and decide on its issues on 7/22/02. OPEN: Look at Tim's new Target schema. 21. [Anne] {PolicySet Policy Rule}Designator issue
http://lists.oasis-open.org/archives/xacml/200207/msg00045.html CLOSED: Designators are not intended to tell *how* to retrieve the specified PolicySet, Policy, or Rule, merely to identify *which* is to be retrieved by Id. The PolicySetDesignator and PolicyDesignator types do need to be a CHOICE rather than a SEQUENCE. OPEN: How about Assertion by reference? 26. [Tim] Repeat Subject and Actions in the Response?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [1.] Should we repeat Subject and Actions in the Response? If there are multiple Subjects and Actions in the Request, will it always be clear which Subject was permitted which Action? [Daniel] I would think yes - repeat it. It also facilitates asynchronous protocols. [Michiharu] Both the subject and the action information in the response context are redundant for the application which holds the request context data. For simplicity, we don't need those elements in the response context. Besides, it might be useful to have some placeholder element in the response context where each application can put any information. OPEN: 27. [Tim] Call "Other" "Environment"?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [2.] Should we call "Other" "Environment"? The term "Other" doesn't convey much information to the reader. [Daniel] Agree. [Michiharu] I prefer "Environment". OPEN: 28. [Tim] Purpose of Qualifier attribute in SubjectIdType definition?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [3.] What is the purpose of the Qualifier attribute in the SubjectIdType definition? [Michiharu] I thought that NameQualifier just corresponds to SAML's NameQualifier. OPEN: 29. [Tim] Policy uses Designator; context uses "ResourceSpecifier"
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [4.] In Policy.xsd we use the term "Designator" (policy, rule, attribute). In Context.xsd we use the term "ResourceSpecifier". Is this inconsistent? [Michiharu] No preference. OPEN: 30. [Tim] ResourceSpecifier ResourceId from anyURI to string?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [5.] In ResourceSpecifier the ResourceId is of type xs:anyURI. Should this not be xs:string? Otherwise, non-xml resource instances cannot be named. [Daniel] Absolutely. I feel, that in general we XACML is too concentrated on this particular resource model. [Michiharu] xs:string is fine with me. OPEN: 31. [Tim] Scope needed in Response?
http://lists.oasis-open.org/archives/xacml/200207/msg00057.html [6.] The Scope element is in both the Request and the Response. Do we need it in the Response? Will one ever want to say the Request is permitted for children, but not for descendants, etc.? [Daniel] It should not, probably, be included in Response. Response is only for the resource mentioned in the response. If a separate response for descendants is needed, it should be provided separately - for all resources in scope. If B is descendant of A, and you make a request for A+immediate children - how would you pick the scope for Bin response? If it is B+children - you are getting information you did not ask for. It is inconsistent.. [Michiharu] Scope may not be needed in response. OPEN: 32. [Michiharu] ResourceContent schema
http://lists.oasis-open.org/archives/xacml/200207/msg00059.html I think that ResourceContent element should be the following to allow any (element, attribute, and namespace) items below it. <xs:element name="ResourceContent" type="ResourceContentType" /> <xs:complexType name="ResourceContentType"> <xs:sequence> <xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax" /> </xs:sequence> <xs:anyAttribute namespace="##any" processContents ="lax"></xs:anyAttribute> </xs:complexType> OPEN: 33. [Anne] ConditionType error?
http://lists.oasis-open.org/archives/xacml/200207/msg00064.html A ConditionType is currently defined as a restriction of a FunctionType. The ohly restriction is that DataType must be xs:boolean. 1. Shouldn't the maxOccurs="unbounded" be changed to maxOccurs="1"? How would you deal with a Condition comprised of more than one Function, Attribute, or AttributeDesignator? 2. Assuming 1, can a restriction change the "maxOccurs" of a choice? OPEN: 34. [Michiharu] XPath Subset
http://lists.oasis-open.org/archives/xacml/200207/msg00066.html OPEN: 35. [Anne] Advice present on Permit or Deny?
http://lists.oasis-open.org/archives/xacml/200207/msg00067.html Can a PDP return Advice in a Decision that is Permit or Deny? or just in a Decision that is Indeterminate? [Bill] my understanding is there is no guarantee that it will be acted upon (in contrast to an Obligation), but it's existence is valid for any Result. OPEN: 36. [Anne] attribute references and indeterminate results
http://lists.oasis-open.org/archives/xacml/200207/msg00069.html http://lists.oasis-open.org/archives/xacml/200207/msg00071.html On further reflection, I think the definition of the semantics of the function being used for OR should determine whether all attribute references must be resolved or not. Since retrieving attributes can be very expensive, I propose the following semantics for the two "standard" OR functions: urn:oasis:names:tc:XACML:0.15g:operators:or Operands may be evaluated in any order. Evaluation continues until either one operand returns TRUE, or until all operands have been evaluated. Once any operand has been evaluated TRUE, no additional operands are evaluated. If any evaluated operand returns TRUE, then the result of the function is TRUE. If all operands are evaluated, and none of them evaluates to TRUE, then, if ANY operand evaluated to INDETERMINATE, the function returns INDETERMINATE. If ALL operands evaluated to FALSE, then the function returns FALSE. urn:oasis:names:tc:XACML:0.15g:operators:or Operands must be evaluated in the order specified. As long as evaluated operands return a result of FALSE, evaluation continues. If an evaluated operand returns TRUE, then the function returns TRUE and no additional operand evaluations are done. If an evaluated operand returns INDETERMINATE, then the function returns INDETERMINATE. In this case, additional operands MAY be evaluated in order to provide information for inclusion in Advice, but such additional evaluations do not affect the result of the function. Similarly, combining algorithms must specify any requirements regarding the order in which rules/policies/sets are evaluated, whether all rules/policies/sets MUST be evaluated, and the semantics of any evaluated rule/policy/set returning INDETERMINATE. OPEN: 37. [Michiharu] Use of XPath with namespaces.
http://lists.oasis-open.org/archives/xacml/200207/msg00056.html OPEN: -- 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