OASIS eXtensible Access Control Markup Language (XACML) TC

Attached are my notes in the form of an annotated XACML schema issues list. I will remove CLOSED items after this mailing (I keep them in a separate file, in case we need to refer to them). 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: XACML schema issues Author: Anne Anderson Version: 1.14, 02/07/22 (yy/mm/dd) Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.SchemaIssues.txt 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. CLOSED: Look at Tim's new Target schema. Specified set of matching rules. Match is between an AttributeDesignator (into relevant area of the context) and an Attribute[Value]. Create an alternate choice in MatchType for "universal matches". 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. CLOSED: Add a policy assertion or policyset assertion reference to the schema. 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. Options: a) Handle matching outside of the Request/Response b) Require Request context to include a unique ID that is also included in the Response c) SAML response includes elements needed; handled by SAML response constructor. CLOSED: SAML wrapper (or other wrapper) can package Request with Response or supply unique IDs as needed. CLOSED: Only one resource per XACML request. If that resource is hierarchical, then the portion of the hierarchy for which a request is made is specified through a "Scope" attribute. CLOSED: One action per XACML request. No xs:list allowed. OPEN: Anne to specify semantics for multiple subjects in a request. 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". CLOSED: Yes. Environment it is. 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. [Tim] What about a federated chain of identities? NameQualifier seems a half-hearted attempt to handle this. CLOSED: XACML NameQualifier corresponds to SAML NameQualifier. 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. CLOSED: Use ResourceDesignator. 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. CLOSED: xs:string it is. Format is more than DataType: it disambiguates the ResourceId. 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. CLOSED: Not needed. Redundant, since specified in the Request. 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> CLOSED: use Michiharu's schema (already included in 15i). processContents="lax" means, if have schema then validate it; if don't have schema, then don't worry about it. 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? CLOSED: maxOccurs=1. 34. [Michiharu] XPath Subset http://lists.oasis-open.org/archives/xacml/200207/msg00066.html OPEN: Complexity, especially when namespace must be specified. For simple XPATH, context schema must be flattened. How to limit XPATH if using a general-purpose library. Check in policy authoring tool. Context can use any XPATH expression, but policy is limited. Could XPATH evaluation be done on the requester side, with just the extracted elements be handed to the PDP? Should context be designed without any attributes, in order to make XPATH simpler (just element /)? 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. CLOSED: Remove Advice from XACML. Simon will propose an Error element schema by 7/25/02. 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:orderedOr 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: Anne to respecify the OR semantics such that only TRUE or FALSE is returned. Daniel will also propose a solution. 37. [Michiharu] Use of XPath with namespaces. http://lists.oasis-open.org/archives/xacml/200207/msg00056.html Namespace URI functions and Global Name functions. Another option: namespace prefix in the XPATH expression, but this needs some assumptions on the target document. OPEN: 38. [Daniel] Split non-null-set-intersection function http://lists.oasis-open.org/archives/xacml/200207/msg00076.html [1)] [Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00077.html Split non-null-set-intersection into intersection(list, list) - returning xs:list and non_null(list), returning boolean. OPEN: 39. [Daniel] Add floor(decimal) http://lists.oasis-open.org/archives/xacml/200207/msg00076.html [2)] [Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00077.html In addition to round(decimal), floor(decimal) is probably necessary [Tim] "function:integer" was intended to serve as floor(decimal). OPEN: 40. [Anne] Change XACML "Request" to "Query"? http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [1.] [Tim] http://lists.oasis-open.org/archives/xacml/200207/msg00079.html [Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html Eve Maler suggests we change the name of "Request" to "Query" to conform to SAML usage. OPEN: 41. [Anne] Is a "notional" XML document for Request a good idea? http://lists.oasis-open.org/archives/xacml/200207/msg00078.html [2.] [Daniel] http://lists.oasis-open.org/archives/xacml/200207/msg00080.html OPEN: 42. [Anne] ConditionType and ConditionIdType http://lists.oasis-open.org/archives/xacml/200207/msg00081.html What should we use for ConditionIdType when the ConditionType is an Attribute or AttributeDesignator? Should we define a new ConditionIdType that is "function:boolean-attribute-value"? Tim proposes "function:true" as wrapper for an Attribute or AttributeDesignator. This conflicts with use of "function:true" to ALWAYS return TRUE for "any" matches in Target. OPEN: