Re: [xacml] Backgrounds of properties for new combining algorithm

["Michiharu Kudoh" <KUDO@jp.ibm.com>]

I agree that the property associated with each element does not solve all
the problems in the case of a custom algorithm as you pointed out. But it
is also true that it really solves some cases without breaking the
semantics described in the spec. Since XACML provides a powerful framework
(e.g. combining algorithm), it helps vendors to implement their access
control engine who are not satisfied with the standardized algorithms. They
may not be able to join the TC to standardize their proprietary semantics.
The advantage of this approach is that if they implement the custom
algorithm, then they can reuse other wonderful language features of the
current XACML spec.

I also understand someone who is satisfied with (or weary of) the current
specification does not want new functions. But it is not true for people
who needs additional function to support their requirements in terms of the
application in their mind (or real use case). So what is the decision
criteria to incorporate new function in the current spec? We cannot add any
new functions unless it solves all the problems? I don't think so.

Most of the new work items for 1.1 is not new one but carried over to 1.1
from 0.0x era since we did not have enough time when we discussed for the
standardization of 1.0. It's the same with Simon's proposal on hierarchical
support. Some people have been requiring such function more than 1 year,
not 1-2 week thought, and they also understand the philosophy of the XACML
model. I think it is worth considering to incorporate in 1.1 spec even if
it does not solve any problems what you have in your mind. Of course final
decision needs vote. :-) However, what I think improtant is that such new
functions should not heavily affect the current available implementations.
So, what I would suggest is that, if such new function is not critical one,
it should be optional as much as possible.

Michiharu Kudo


                                                                                                                                                    
                      Seth Proctor                                                                                                                  
                      <Seth.Proctor@Sun        To:       Michiharu Kudoh/Japan/IBM@IBMJP                                                            
                      .COM>                    cc:       XACML TC <xacml@lists.oasis-open.org>                                                      
                                               Subject:  Re: [xacml] Backgrounds of properties for new combining algorithm                          
                      2003/04/25 00:31                                                                                                              
                                                                                                                                                    
                                                                                                                                                    




> 1) Placeholder for some information used in
another access control
> policylanguage

It sounds to me like you're talking about two
different cases here: using XACML as an intermediary
language and strictly translating from some other
language to XACML. I think you're stressing the
latter, but both of these issues apply.

In the case of using XACML as an intermediary
language (ie, a general bridge between two
proprietary languages) I think that it may well be
useful to have an area where you can include raw
information that can't easily be expressed in XACML.
Of course, this data must never be used by XACML, so
the where and how of this data being included isn't
as important.

In the case of translating from one language to
XACML (which is what you're talking about), you want
to include properties because you may need to use
custom combining algorithms and they in turn may
need special data. Unfortunately, adding properties
doesn't really solve the problem here, since what
you're really talking about is a policy language
that can't be cleanly mapped onto the semantics of
XACML. In that case, adding properties for combining
algorithms to use won't solve your problem, it might
just help things out a little. For the same reason
that you need to support new combining algorithms,
you might also need to express conditions
differently, or redefine rules, or add properties to
references. If there is a sematic mis-match, just
adding properties for combining algorithms won't
solve the problem.

Note that since you're talking about custom
combining algorithms, there are already ways to add
inputs if you need them (like getting attributes out
of the request or setting up some algorithm-specific
mechanism similar to attribute and policy
retrieval). Not that I'm advocated this approach,
I'm just saying that it can be done and it's not
more vague than what's already in the specification.
It doesn't seem to me, however, that adding
propoerties will solve your problem.

> 2) Placeholder for storing implementation specific
information

This one scares and confuses me, because now you're
not just talking about inputs for combining
algorithms, but all parts of a policy. You're also
talking about doing out-of-order execution on a
Condition, which won't always help if required
attributes aren't present. In general, it's going to
be hard to come up with the right order to do
function evaluations (some attributes might be
cached, others might suddenly become unavailable,
etc.). I agree with you that this use case isn't as
compelling.


seth