xacml — archive

[Polar Humenn <polar@syr.edu>]

 MHonArc v2.5.0b2 -->


















xacml message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: [xacml] condition reference text (item 7)




From: Polar Humenn <polar@syr.edu>
To: Anne Anderson <Anne.Anderson@Sun.COM>
Date: Mon, 15 Mar 2004 10:50:44 -0500 (EST)







The orginal problem here, was that Condition extended ApplyType, which I
thought was a bad idea, as it simulcast a Condition as a function, rather
than contain it.

If a Condition was an element containing an expression, then it wouldn't
be a problem.

However, since we are not really maintaining backward compatibility, for
the reasons Tim and Anne state about "talking about" the condition of a
rule, I can see that the proposal can handle something of the form.


<Condition>
   <Apply FunctionId="string-equal">
        .....
   </Apply>
</Condition>

Or

<Condition>
   <VariableRef VariableId="x"/>
</Condition>

or even

<Condition>
   <AttributeValue Datatype="boolean>True</AttributeValue>
</Condition>

as long as the content is a boolean typed expression.

Admittedly, this approach adds 23 characters to each rule, but what the
hey, they only weigh 0.0003421 nanonewtons.

Is that an acceptable compromise?

Cheers,
-Polar

On Fri, 12 Mar 2004, Anne Anderson wrote:

> On 12 March, Tim Moses writes: RE: [xacml] condition reference text (item 7)
>  > Colleagues - I have just realized how much work this is going to be.  In
>  > addition to the specific changes described by Simon, all the examples are
>  > affected and the introductory material, including the class diagram are
>  > affected.  This is going to take some time.
>  >
>  > I would like to see formal acceptance of the proposal as soon as possible,
>  > because backtracking doesn't look like an appealing option.
>  >
>  > Personally, I lament the passing of <Condition>.  The part of <Rule> that
>  > complements <Target> is a significant independent concept that deserves its
>  > own name.  Anyone who has to explain XACML will have to refer to it.  With
>  > the passing of <Condition>, they'll have to talk about "the child
>  > <Expression> element of the <Rule> element" or some such.  Global replace
>  > may work for the editor, but it is not a very attractive prospect for the
>  > reader.
>  >
>  > Does anyone else feel that this idea needs a name of its own?
>
> Yes, I do.  The type of the Condition element can be shared with
> the other expressions, but giving the element that contains the
> set of predicates for a Rule its own name is a minor addition
> with major readability benefits.
>
> The counter argument might be that people won't read XACML
> policies, and the tools that generate them don't care what the
> name is.  As someone who frequently presents and explains XACML
> to customers and partners, I can attest that being able to
> present readable, short examples is essential to obtaining
> broader acceptance for XACML.  We will not have many tools until
> enough human readers have decided XACML is a good language.
>
> Anne
>
>  > All the best.  Tim.
>  >
>  >