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: Re: [xacml] Condition and FunctionId attribute

bill parducci wrote:
>> On Sun, May 18, 2008 at 04:39:29PM +0200, Erik Rissanen wrote:
>>> Regarding #2, we could do that, but in my opinion it is not needed. 
>>> The spec
>>> is quite clear on what the condition element does already. There are 
>>> so many
>>> ways to write a nonsensical XACML policy, that I don't think we should
>>> attempt to cover them. ;-)
> On May 19, 2008, at 8:18 AM, Seth Proctor wrote:
>> I agree completely. As long as it's clear that a Condition can't be
>> evaluated unless it contains an expression that evaluates to a Boolean,
>> I think we're all set. Erik, your two proposals make sense to me..
> While I agree in principle, the condition that it be "clear" was not 
> met in this case IMO. This is why I suggested that we consider 
> annotation. If that is not the best approach then perhaps we can 
> consider another means by which to achieve this.

Personally I think it is clear. Section 5.34 in the 2.0 specification 
document states:

The <Condition> contains one <Expression> element, with the restriction 
that the
<Expression> return data-type MUST be 
Evaluation of the <Condition> element is described in Section 7.8.

It is clear from this text that it has to be a boolean. One part that is 
perhaps unclear is what should happen if it is not a boolean. My 
interpretation of this text is that the PDP should refuse to even load a 
policy which does not follow this restriction, but I am not sure if 
everybody would agree.

I still think we should not change the spec with respect to this issue.


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