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: Re: [xacml] AA02: Revised: A.x Structured Datatypes



Anne et al,

I don't really like all of this. Comments in line.

On Thu, 17 Oct 2002, Anne Anderson wrote:

> We discussed AA02 on this morning's call, and decided a fifth
> alternative was available: defining a new function to deal with a
> structured data type.  What follows is a revised version of the
> proposed text that fixes some typos, clarifies some wording, and
> defines the fifth alternative.
>
>   TEXT LOCATION: Section A, following "A.2 Primitive
>   types" (p. 86, between lines 3345 and 3346 in my copy of 0.18c)
>
>   TEXT CHANGE: Add following new section as follows:
>
>     A.3 Structured types
>
>     An XACML <AttributeValue> MAY contain an instance of a
>     structured xml data type, for example <ds:KeyInfo>.  XACML
>     1.0 supports several ways for comparing such <AttributeValue>s.
>
>     1) In some cases, such an <AttributeValue> MAY be compared
>        using one of the XACML string functions, such as
>        regexp-string-match, described below.  This requires the
>        structured data, including its tags and attributes, to be
>        identified and treated as an instance of DataType
>        <xs:string>.  In general, this method will not be adequate
>        unless the structured data type is quite simple.

I don't mind this as long as the DataType is specified in the
Attribute in the Context, not as a "ds:KeyInfo" but as "xs:string".


>     2) An <AttributeSelector> element MAY be used to select the value
>        of a leaf sub-element of the structured data type.  That value
>        MAY then be compared using one of the supported XACML
>        functions appropriate for its primitive data type.  This
>        method requires support by the PDP for the optional XPath
>        expressions feature.

This is fine.

>     3) An <AttributeSelector> element MAY be used to select the value
>        of any node in the structured type.  This node MAY then be
>        compared using one of the XPath-based functions described
>        in "Section A.13.13 XPath-based functions".  This method
>        requires support by the PDP for the optional XPath
>        expressions and XPath functions features.

This is fine as well.

>     4) For a given structured data type, a community of XACML
>        users MAY define new attribute identifiers for each leaf
>        sub-element of the structured data type that has a type
>        conformant with one of the XACML-defined primitive
>        datatypes.  Using these new attribute identifiers, the
>        PEPs or context handlers used by that community of users
>        can flatten instances of the structured data type into a
>        sequence of individual <Attribute>s.  Each such
>        <Attribute> can be compared using the XACML-defined
>        functions.  Using this method, the structured data type
>        itself never appears in an <AttributeValue> element.

Anne,

I'm starting to understand what your getting at, but I'm really puzzled
why we need this functionality in simple Attribute Designators.

How does this work? Do you have a specific example? This seems like new
functionality to me. Before we had attribute identifiers that simply
indexed out of the particular Subject, Action or Resource section.

Do we now have to understand a attribute identifier syntax that indexes
into the datatype? How can that be general and simple enough given the
complexity of XPath on this issue?

Also, between 4-5, I don't know what a "community of XACML users" is.

I think it would be better to state just that XACML may be extended with
alternate datatypes and the functions that operate on them.  However, that
is covered by Appendix A.13.14 Extension functions and primitive types.

You just may want to say that the contents of the attribute may be an XML
structure.

I think I would feel more comfortable that if you are going to extend
XACML, you should go the whole way in extending XACML by also creating
"selector" functions for the structured type that select primitive types
out of the structured datatype, such as:

<Apply FunctionId="ext:get-public-key">
   <SubectAttributeDesignatorWhere AttributeId="urn:....:key-info">
      <SubjectMatch MatchId="function:string-equals">
         <SubjectAttributeDesignator
              AttributeId="urn:...subject-category"
              DataType="xs:QName"
         />
         <AttributeValue DataType="xsQName">urn:....:access-subject</AttributeValue>
      </SubjectMatch>
   </SubjectAttributeDesignatorWhere>
</Apply>

where ext:get-public-key
takes a ds:keyInfo and returns an xs:base64Binary, which is the public key
from the <whatever> element of a ds:KeyInfo type.

Cheers,
-Polar

>     5) A community of XACML users MAY define a new function that
>        can be used to compare a value of the structured datatype
>        against some other value.  This method may only be used by
>        PDPs that support the new function.
>
> --
> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC