RE: [xacml] Follow up on TC call

[Polar Humenn <polar@syr.edu>]

On Wed, 18 Sep 2002, Daniel Engovatov wrote:

> > So what? If you are going to add extensions, publish your manual and its
> > specs, and use away.
>
> That's what I want - and i want other implementations to be able to do the
> same as I am convinced that this will happen..  But we just decided to give
> everybody a gun to be able to shoot future interoperability in the foot.

I don't know what you mean by "interoperability" in this case. Do you mean
"portability", i.e. being able to transport a policy between two different
XACML implementations?

If you restrict yourself to the standard XACML functions, then one policy
is executable on both implementations. This is "portability".

If you use non-standard functions in one implementation, then in order for
the policy to work on the second implementation, the second implementation
needs to understand them, as well. This is "restricted portability".


I get the feeling that you are concerned about "similar" XACML "engines"
that you can drop extension functions into and they should work for all
XACML "engine" implementations. (Is that what you mean by
"interoperability"?).

For this capability I would think you need to define and standardize an
interface with which to do that. That is out really out of the scope of
XACML. However, I can see how that can easily be done with certain
interface tools, such as Java, JavaBeans, C++, COM, DCOM, .NET,
CORBA, etc.

Cheers,
-Polar

> Once extensions may be not the SAME as standard functions - they eventually
> will be non compatible.
>
> Daniel;
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>