OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] [schema] updated list of schema issues


Attached is my updated list of schema issues for the call today.
Since there are quite a few, I suggest Tim and others propose a
prioritization to be discussed at the start of the call.

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.13, 02/07/19 (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.

    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: 

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"?

    OPEN:


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC