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] Re: Report on new tests

On Mon, Mar 03, 2003 at 10:30:11AM -0500, Anne Anderson wrote:
> IIIC001 works with Sun's XACML Implementation.  IIIC002 and
> IIIC003 fail with the message:
>   Incorrect Response:
>   <Response>
>   <Result>
>   <Decision>Indeterminate</Decision>
>   <Status>
>   <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:processing-error"/>
>   <StatusMessage>Couldn't find any resources to work on.</StatusMessage>
>   </Status>
>   </Result>
>   </Response>

Right. This is the correct behavior for our code. While we offer a plugin
API for writing modules that know how to lookup hierarchical resources, we
don't provide any default implementations (see next paragraph), so when our
stock implementation is given a scope of Children or Descendants, we don't
resolve any resources to use. Our code does handle resource scoping correctly
in all other respects, however, so it would be relatively easy to write a
module that passed this test (and I will do so soon once I get a little
free time). We simply don't offer any default ways to resolve hierarchies.

The logical followup question is "why don't you offer any default modules to
get hierarchical resource identifiers?" The answer is simple. While the spec
makes it clear how hierarchical resources are supposed to be handled in the
abstract, there are no concrete rules for how to handle particular types of
resource hierarchies (eg filesystems, XML documents, LDAP services, etc).
Because of this, we decided it was better to provide no implementations then
implementations that weren't written against any specification and might not
do what people wanted. In order for there to be good interopearbility here,
I think there needs to be standard language describing how to handle some of
the more common kinds of hierachies, and it needs to cover the tricky cases
like what happens when a parent node can't resolve some descendant nodes, etc.

In the case of this test, the request (naming an anyURI resource) clearly
isn't meant to be taking advantage of any standard hierarchical scheme. It
would be nice, however, if there were some standard schemes defined in a
future version of the spec, and if these were used in the conformance tests,
though again that's just my opinon.


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