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] Follow up on TC call


..couple more things..

> Who said you have to create "extension" functions that take function 
> as an argument? You don't have to do that to be conformant or 
> compliant with the specification.

That's the quickest way to make XACML into yet another useless standard.
Fact one - many implementation will extend funcitons used.
Fact two - if they are not exactly the same model as standard functions
interoperability will be severely complicated.

I guess people never learn - there are thousand of dead languages out
there, with all the cool and "solid" features.  Those are used that are
practical, and for which libraries are available.

> Since it is outside of the specification, you can make it do anything
> you want. Your customer will have to have your manual, not XACML, in her
> hand to know what that function does, no matter what.

I guess that was the argument for not standartizing C++ ABI..  
Really helped in having a lot of interoperable libraries.



>> This approach has an added flexibility that the operations can be
>> specified in context as attribute values.

>Just the thing that is doable, but is frightening because now you cannot
>do assurance analysis on your policy when it looks up a function name as
>an attribute value. That is because you may not know what the semantics
>of the function named in the attribute, or even if it is supported by
> your XACML processor.

Wrong.  If you define it as a data type with appropriate restrictions: for
example "type:functions-that-take-two-integers-and-return-a-boolean" than
this assurance is done by your type checking system - otherwise you need to
"magically" know that the operation specified is apropriate.
This approach is safer - and more flexible.

> 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.
Once extensions may be not the SAME as standard functions - they eventually
will be non compatible.

Daniel;


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


Powered by eList eXpress LLC