Re: [xacml] AA02: Revised: A.x Structured Datatypes

[Polar Humenn <polar@syr.edu>]

On Fri, 18 Oct 2002, Anne Anderson wrote:

> On 17 October, Polar Humenn writes: Re: [xacml] AA02: Revised: A.x Structured Datatypes
>  > >     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".
>
> As it says, "This requires the structured data, including its
> tags and attributes, to be identified and treated as an instance
> of DataType <xs:string>."

It says "to be identified and treated as an instance of data type
xs:string." That's an aweful lot different that saying that the structured
data in the attribute value in the request context SHALL have the
"DataType" XML attribute with a value of "xs:string".

That's about the only normative thing here I think we should say, should
one be worried about structured data types in <Attribute>s.

>  > >     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.
>
>  > 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.
>
> Just as we defined specific attributes for the components of a
> SAML SubjectStatement -- subject-id, subject-id-qualifier,
> key-info, authentication-time, authentication-method,
> authn-locality:ip-address, authn-locality:dns-name -- another
> industry consortium etc. ("community of users") could define
> specific attributes for the components of some other structured
> data type of interest to them.

I don't see why we have to say anything about a "community of XACML
users". Either the specification is extended or not. This implies that
there is some agreement process going on. If so, what is it?

>  > 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?
>
> No, I was very clear that it is the PEP or the context handler
> that would have to understand how to do this indexing/mapping,
> just as they have to do the work of translating a SAML
> SubjectStatement into our individual attributes.

Then this is an extension to the PEP to PDP interface that is needed to be
known by the PEP as well as the policy writer. So, I don't think we really
need to say anything about how XACML is extended in this case.

>  > Also, between 4-5, I don't know what a "community of XACML users" is.
>
> An industry consortium, some standards body, etc.  Any group of
> users that want to agree on some attributes for interoperability
> between themselves about values of use within their community.
>
>  > 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.
>
> But I'm trying to explain how this extensibility can be applied
> in the specific case of addressing a structured data type.  I can
> point to A.13.14 for more information, but A.13.14 by itself will
> not be an obvious solution to people trying to deal with a
> structured XML data type that XACML has not already defined
> individual attribute ids for.

Well, that's fine, maybe in a companion document, or some other
non-normative chapter about "Ways to extend XACML".

>  > You just may want to say that the contents of the attribute may be an XML
>  > structure.
>
> That is case 2), 3), or 5).  In this case, 4), the PDP will never
> see the XML structure because the PEP or the context handler will
> have broken it down before it appears in the Request Context.

But that is totally up to the Policy writer knowing the capabilities of
the PEP and PDP and visa versa. There is really no need to specify this in
a normative chapter.

>  > 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.
>
> But we have XPath for that.  I don't want to define yet another
> "selector" mechanism.

I'm not saying to define another selector mechanism. You are! :)
If we have XPATH for that, then why do we need this functionality?

Second, of all, I just offered this as an example. I wasn't planning on
having anything like this in the specificaiton. It is an extension.

> Cases 2) and 3) cover using XPath for
> that.  I have described 4) and 5) for people who don't want to
> use XPath (for the same reasons we don't just use XPath for XACML
> SubjectStatement elements).

Again, it requires an extension to the PEP and PDP interface, of which I
don't know why you would say anthing about it at all. If the PEP decides
to break down a structed XML type into a bunch of <Attribute>s, what does
it matter as far as the specification goes? The PDP still has to have the
PEP manual in hand to get the job done correctly.

-Polar


 >
> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>