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] | [List Home]

Subject: [xacml] FW: recommendations regarding xacml.3.0



From: Jan Herrmann [mailto:herrmanj@in.tum.de]
Sent: Friday, December 12, 2008 5:00 AM
To: bill@parducci.net; hal.lockhart@oracle.com; 'Seth Proctor'
Subject: recommendations regarding xacml.3.0


Dear  Hal, Bill, Seth,


I hope you are the right persons to address this mail to.

What  is the current work status of  XACML 3.0? As we have quite a few suggestions for improvement, it would be very interesting to know if it is still possible to introduce new ideas.


Within the Open Geospatial Consortium (OGC) we are using XACML or GeoXACML (a spatial extension adding a spatial geometry data type and some spatial functions) respectively to provide flexible, interoperable access control in OGC based Web Services infrastructures.


Currently we are working on a profile of GeoXACML for OGC Web Services to enhance interoperability when using (Geo)XACML in OGC Web Service environments.

In this profile we will describe little extensions/concretisations in order to enhance interoperability if you use (Geo)XACML in Web Service environments. Additionally our research resulted in some suggestions to improve XACML and some related profiles (e.g. multiple resource profile of xacml 2.0).


In short our main recommendations for XACML 3.0 are:


  • When using the ResourceContent to represent web service specific information (i.e. the ws-request or -response) the current AttributeSelector definition is not sufficient (and by the way not exactly defined in the xacml 2.0 spec – c.p page 66 and 78/7). What we need is an XMLAttributeSelector that returns arbitrary node sets as specified by the xpath expression within the selector (e.g. a sub tree of the ws response representing the geometry of a building). I suppose that at the moment the AttributeSelector mechanism is only intended to select text nodes (even if this is not specified unambiguously in the spec – c.p page 66 and 78/79) To return only text nodes is not sufficient in our use case and is an unnecessary restriction.

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