xacml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
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]
| [Month Index]
| [List Home]