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] <AnyElements>


To clarify: <Target><Subjects></Subjects></Target> != <Target></Target>
right?  I do agree with such interpretation.

The question is - why allow a construct that creates an always
non-applicable rule?  Should not we just restrict <Subjects> element to
not allow such usage?

In general - my concern with <Any*> was that there is no such "things"
as Action, or Subject.  There are action or subject attributes, and they
are just designators of scope, not having any particular (including the
universal "any") value by themselves.  Their existence were complicating
the model of the context attribute data space - on which rule operation
is defined.

Daniel;

-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu] 
Sent: Thursday, January 29, 2004 10:49 AM
To: Daniel Engovatov
Cc: Bill Parducci; XACML TC
Subject: Re: [xacml] <AnyElements>


I only made a point about the <Any---> elements in an issue toward
backward compatability. However, I am informed that 2.0 is not going to
be
backward compatible, so it doesn't much matter to me.

We are all in the understanding that <Target> naorrows the scope of
applicability.  For the niave/lazy reader the <Any---> element may serve
to give a different semantic meaning as to EXTENDING the scope, not
narrowing it. I do remember having this discussion/argument early on,
i.e.
an ambiguity or misunderstanding at the very least.

I'm actually the one who inisted on the <Any---> elements early on due
the
situation that XACML code generation may yield empty sequences (which
must
have the interpreation of No-Match, as an empty disjunctive sequence),
and
there wasn't any way of representing it, because a <Target> HAD to have
a
<Subjects>, <Resources>, and <Actions> elements. Now, that they are
optional, it's okay, and is consistent with the conjunction and
disjunction of propositional statements.

In the <Target> each <Subjects>, <Resources>, <Actions> element provides
a
a RESTRICTION on the currently selected set. If there are no
restrictions
present, then nothing further is selected from the set.

The only thing I would like to call out that if an empty restriction
shows
up, such as

<Target>
   <Subjects></Subjects>
</Target>

must be consdiered a No-Match as it labels a conjunctive sequences
containing a single and empty disjunctive sequence. In convential
propositional logic, an empty disjuctive sequence is considered false.
So, this target is a non-empty conjunctive sequence containing a false,
which is itself false, and thereby evaluates to No-Match.

Alternatively, this structure says, from the current set, T, take all
such
t from T such that any subject s in t statifies any of the following
predicates. Since there are no predicates, then no elements of T can be
selected based on s in t, and therefore the result is the empty set.
This
would mean we have a "No-Match" situation.

One may say that a "person" may not write such a statement, but a
machine
may indeed. In any case, the edge cases must be logically consistent.

Cheers,
-Polar

 On Thu, 29 Jan 2004, Daniel Engovatov wrote:

>
> to the best of my knowledge, no one is actually performing evaluations
> directly against an XML document. so as i see it, unless someone can
> make the case that Any* actually creates ambiguity
>
>
> Mandatory <Any> DOES create ambiguity in one case I am working with.
>
> There is NO concept of separate Action and Resource.  What does
> <AnyAction> mean if there is NO Action?
>
> The only real reason to separate <Rule> into Condition and Target
> elements is efficiency.  Using the Target structure to impose
particular
> structure on the context (separating it into
> Subject/Action/Resource/Everything fixed subspaces/scopes) is not a
very
> good idea IMO.
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro
up.php.
>


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