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] IIC012: syntax-error or processing-error?


On Wed, 4 Dec 2002, bill parducci wrote:

>
> Polar Humenn wrote:
> > For the case when you have a single malformed policy to be evaluated
> > against a request, the answer is just simply undefined. The implementer
> > can choose. Therefore, there should not be a "CONFORMANCE" test for it.
>
> 'undefined' needs to manifest itself somehow in the decision.

Undefined is NOT a value. It merely states that a specific result is not
deducible from the inputs. It is outside the specification.


> back to the run-time vs. precompiled topic for a sec..
>
> supposing that there is a use case/conformance test that has a mis-typed
> (or otherwise malformed) policy: under the precompiled model, this
> policy will simply be thrown out upon being communicated to the system;
> under the run-time model it will generate a status code 'other than OK'
> and issue a decision of INDETERMINATE. with this in mind we can: (a)
> allow for both of these scenarios to have it owns conformance criteria;
> (b) take a stand on which evaluation mechanism is supported; (c)
> consider it out of scope and allow for unlimted of decision/status
> combinations.

You have a lot of work to do deciding which evaluation models to use, such
as indexing, the way in which you index, the way in which you evaluate
Ands and ORs. That is, you have to decide or lock down the way in which
And and ORs are evaluated. Where do you start runtime typechecking, where
do you stop? The Policy? The Rule? The And expression? Do you do the same
for syntax?  Remember <Policy/> is valid XML, so a stupid parser will pick
it up just fine.

And then you have to strictly call out the scenarios in which badly formed
policies or badly formed expressions that are not evaluated by one
interpretation of a combining algorithm against another combining
algorithm or expression evaluator.

It's not that simple.

-Polar

> i personally think that option 'a' is worth considering because option
> 'b' forces us to make an implementation decision and option 'c' is a bit
> loose for my taste.

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