[xacml] Minutes of 12/02/02 comments subcommittee call

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, but we should not expect a response.

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.

Withdrawing our specification leaves XrML as the only
alternative.  This is not beneficial to the community.

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: 
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692