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: Thoughts on XACML Policy Model...


Title: Thoughts on XACML Policy Model...

Hi all,

I have taken a look at RFC 3060.  The model presented there seems interesting and reasonable, and - in a number of ways - is quite compatible with the model assumed/implicit in the policy language proposal I submitted a while back.  There are, however, at least three differences that should be considered.

 - Firstly, the 3060 model, like the XACL work, explicitly includes "action" within the policy, whereas the proposal I submitted (based on the X.509 work) does not.  I explained in my submission why I think it's more attractive to leave "action" out of the policy, but another interesting consideration is that by leaving "actions" as separate classes, along with "subjects", the policy language syntax can be used both in an access-based policy environment and in a capability-based policy environment.  Having this flexibility in the language syntax seems attractive to me.

 - Secondly, the 3060 model defines PolicyCondition as an abstract class and leaves it up to VendorPolicyCondition to define concrete instances, specified in the RFC only as OID / OCTET STRING pairs.  In the X.509-based submission, "PolicyCondition" (there called a "PrivilegePolicyPredicate") is taken one level further, so that various flavours of conditions are defined, such as "equality", "greaterOrEqual", "subsetOf", and so on.  This extra level of definition is useful because it allows us to think about the inputs to a Condition.  In particular, something like "equality" takes two operands ("THIS must be equal to THAT"), one of which is found within the set of information related to the actual request, and the other of which may be explicitly hard-coded in the policy or may also be found within the request information.  The model is therefore more detailed in terms of its interaction with the environment, which makes for clearer understanding and a higher probability of interoperability success.

 - Thirdly, the 3060 model has no concept of "sequence" (or "order") of conditions (an order on actions can be specified, but this is entirely different).  In X.509, an ordered set of conditions was introduced to allow for the cases in which a policy might want to state that "AAA must be true and THEN BBB must be true" before a method can be invoked.  For example, "the purchase order can be sent if it was signed by a purchase officer and then by the VP".  This is the concept of a counter-signature (as opposed to a co-signature) being explicitly stipulated in policy.  Other examples could be described as well.


I think that the first two differences above are not insurmountable in any way.  RFC 3060 could fairly easily be extended to accommodate these extra features in the X.509-based model.  Sequence is a bit trickier:  I don't readily see a way to extend the 3060 model to incorporate this concept.  Thus, if XACML decides to include this in its model, some slightly bigger changes would be required to 3060 (I've sketched it out and it is not too complicated, but it is a change from 3060, rather than a simple extension to it).  I personally think that order is an important concept to keep, but the group may wish for expediency to leave it out of XACML 1.0 and go with the simpler extended-3060 model instead.

Comments?

Carlisle.



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


Powered by eList eXpress LLC