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


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

 > >     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.

 > 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.

 > 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.

 > 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.

 > 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.  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).

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



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


Powered by eList eXpress LLC