[Includes some corrections to previously published minutes] PRESENT: Tim, Polar, Simon, Carlisle, Anne, Hal. ACTION ITEMS: ============= [These do not include general "update the schema, spec, conformance tests" actions] 32a. [All] Read wording of Section 3.1.1 motivating "rule" in draft document attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/maillist.html , posted 11/29/02. Unless there are objections, this will be used as the resolution to comment 32a. 44. [Simon Godik] compare 5.30 with 5.27-29 and propose consistent wording. 12/02/02 no progress, but will be done shortly. 52a-d: [All, especially Michiharu] provide opinions on root of XACML XPath expressions. 57. [Simon Godik] Update specification draft to change <Target> element order to be <AttributeValue> followed by <AttributeDesignator> or <AttributeSelector>. Turn change bars on and post result to xacml-editors list. Include SubjectCategory Context XML attribute in same update. COMMENT RESOLUTIONS =================== [see
http://lists.oasis-open.org/archives/xacml/200212/msg00001.html for the comment numbers and full text] 32a. The description of a rule seems to be inadequately motivated. RESOLUTION: Tim has reworded 3.3.1 in the draft version posted to the xacml-editors list on 11/29/02. Unless there is disagreement, this will be used as the resolution. 33. Subject: map function RESOLUTION: keep "map" as is (un-typed) 39, 40. Subject: subject-category as attribute, rather than <Attribute> RESOLUTION: SubjectCategory will be an XML attribute of the <Subject> element in the Request Context. There will no longer be a urn:...:subject-category XACML attribute. SubjectCategory will be optional, with default value "urn:...:access-subject" 43. Subject: A comment on Section 7.3 RESOLUTION: Change 7.3 Target Evaluation to say The target value SHALL be "Match" if the subject, resource and action elements specified in the target result in "true". The target value SHALL be "No-match" if one of the subject, resource, or action elements specified in the target results in "false". The target value SHALL be "Indeterminate" if any of the subject, resource, or action elements results in "Indeterminate." See Section 7.9.2 Attribute Retrieval and the specifications of match functions for more description of "Indeterminate" results. Remove If any attribute value referenced in the condition cannot be obtained, then the condition SHALL evaluate to "Indeterminate". from the end of Section 7.4. 48. Subject: Resource types RESOLUTION: reword A.12 Matching elements yet again as in the attachment to message
http://lists.oasis-open.org/archives/xacml-comment/200211/maillist.html#00087 . This re-wording is consistent with the resolution to #57, in that the AttributeValue is described as the first element and argument to the MatchId function, and the AttributeDesignator or AttributeSelector is the second. 52. Subject: 5.31 Element <AttributeSelector> This comment was not resolved, and discussion is requested from TC members, especially Michiharu and any other XPath experts. The following points were made: -It is reasonable to use "context node" in response to 52a. Does XPath expression start with the <Subject>, <Resource>, <Action>, or <Environment> element, or with <Request>, or, in the case of <Target> elements, with the path following <Subject>, <Resource>, or <Action>? -An XACML parser should not need to know semantics of the XPath expression, and it should be passed off to an external library. This requires that the expression start with the root of the document. -But, if the implementation is to handle "notional" Request, the XACML implementation will HAVE to parse these. -Request element is always implied. XPath expression in Target implies Subject, Resource, or Action. XPath expression in Condition implies only Request. Implementations can pre-pend Request/[Subject Resource Action] depending on whether the expression appears in a Target or in a Condition if they want to make use of an XPath library. -But what if the XPath expression is an absolute expression? Or if it uses .. to back up and go down a different path? 57. Subject: Making MatchId and FunctionId arg order the same RESOLUTION: Target element order will be: AttributeValue, then AttributeDesignator or AttributeSelector. 58. Subject: syntactic errors in XACML schemas RESOLUTION: these are duplicates of #41 and #42. RESPONSE: Use "mixed" in schema; use -01 in import statement. 59a. Subject: XACML questions ... Why is there no <EnvironmentMatch>, similar to <SubjectMatch>, <ResourceMatch>, and <ActionMatch>? RESOLUTION: Not needed, since not useful for indexing. No use case. 59b-e: Depend on #52. 60. Subject: A002 RESOLUTION: Clarify Figure 1 and its explanation and Section 7.9. ACTIONS: Change Figure 1, 8. to Target, Attributes, Resource and 9. to Decision. Change description of 8. CH invokes the PDP and passes the Target. The PDP requests the required attributes from the Context Handler. 9. The PDP returns its decision. In 7.9 Attribute are specified in the request context, regardless of whether they appeared in the original request, and are referred to in the policy ... 7.9.2 change: from "The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values." to: The "signature" of the interface between the PDP and the Context Handler module has two inputs: an AttributeDescriptor or AttributeSelector, and a Boolean "MustBePresent" value. The output from the Context Handler to the PDP is either a bag of values or "Indeterminate" (in the case where an empty bag resulted, but "MustBePresent" is true). The Context Handler is responsible for retrieving the referenced attribute value regardless of whether the attribute was supplied in the original Request context or whether the attribute is available elsewhere in the system. 61. Subject: no rules or policies RESOLUTION: reword of both sections as follows and remove the tables. 7.6 Policy Evaluation The value of a policy SHALL be determined only by its contents against the request context. A policy's value SHALL be determined by the evaluation of the policy's target and the evaluation of its rules according to the specified rule combining algorithm. The policy's target is evaluated to determine the applicability of the policy. If the target evaluates to "Match" then the value of the policy SHALL be determined by evaluation of the policy's rules according to the specified combining algorithm. If the target evaluates to "No-Match", then the value of the policy shall be "NotApplicable". If evaluation of the target raises an "Indeterminate" the value of the policy SHALL be "Indeterminate". 7.6 Policy Set Evaluation The value of a policy set SHALL be determined by its contents against the access decision request. A policy set's value is determined by the evaluation of the policy set's target and the evaluation of its policies and policy sets according to the specified policy combining algorithm. The policy set's target is evaluated to determine the applicability of the policy set. If the target evaluates to "Match" then value of the policy set SHALL be determined by evaluation of the policy's policies and policy sets according to the specified policy combining algorithm. If the target evaluates to "No-Match", then the value of the policy set shall be "Not-Applicable". If evaluation of the target raises an "Indeterminate" the value of the policy set SHALL be "Indeterminate". 62. Subject: Two different URIs for access-subject RESOLUTION: Use "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" rather than ...:subject:subject-category:..." 63. Subject: Environment attributes RESOLUTION: In B.8, use 'When supplied as part of the request, they SHALL appear within the <Environment> element of the request context.' In 10.3.5, use "If values for these attributes are not provided in the request, then values for these attributes MUST be provided by the PDP." RESPONSE TO CONTENTGUARD IP CLAIMS POSTING ========================================== There was some discussion of the notice from ContentGuard that XACML implementation MAY infringe on specific patents that they cite. There is no official "reply" that XACML makes. ContentGuard's notice is a general statement is not against any specific feature. Attesting implementations must say they either do not infringe, or that they have obtained necessary licenses. Carlisle publicly request clarification of which features might infringe. Carlisle will draft a complaint to the OASIS board about delay in submitting IP claims, when rules say "earliest possible time". This will be discussed and voted on 12/05/02. Time line: 12/05 Carlisle gone, Hal will chair. 12/08 Public comment period ends. 12/09 Final cleanup 12/12 Final vote. "3 attestations" requirement at risk, but we can still vote to make the updated spec an official "Committee Specification". Then we will just need to wait for 3 attestations before submitting to OASIS. Hal will be on the road that day, but will call in. Vote will be between 10 and 10:15. Anne Anderson -- 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