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?


Polar Humenn wrote:
> Any output is acceptable.

not to me. i want to know if something went wrong.

> I would admit that may be logical, but say that the offending piece is in
> buried deep a poriton of the policy decsription that may not be evaluated according to
> some models, and may be evaluated according to other models, against the
> same inputs? Then what will you say the "conforming" result MUST be?

one of TWO outcomes.

let me try explaining it this way: 

IF a policy is deemed to be relevant to the decision, and that policy cannot be digested for *whatever* reason at the time of decision, the result is INDETERMINATE/[notOKstatus].

now, in a pre-compiled scenario any policy that is not digestible will be rejected upon attempting to enter the system and will therefore NEVER be considered in the scope of the decision because it "doesn't exist" at the time of decision; the policy doesn't affect the decision and conformance is demonstrated by the rejection.

therefore, if there was a use case/conformance test whereby there is a malformed policy, those systems that attempt to call upon this policy in real time must return INDETERMINATE and those that reject upon entrance into the system will act as if it never existed since, by definition, it was never entered into the system to be considered.

conformance can therefore be tested by submitting a malformed policy to each system and having one of *two* acceptable outcomes: (1) policy is rejected upon attempted entry to system; (2) subsequent requests within scope of said policy are responded to with a decision of INDETERMINATE/[notOKstatus].

this addresses my 'something is wrong' issue by either having the policy compilation process complain (which, one would think would be rather obvious to the operator) or having the decision reflect that something went haywire when the system tried to make a decision.

maybe i am not grasping the nuances, but this seems like it would work.

b




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


Powered by eList eXpress LLC