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


Title: Thoughts on XACML Policy Model...
Simon - I like your suggestion concerning the best way to express "sequence".  Perhaps, we could generalize it a little.  There is at least one other common mechanism for capturing sequence.  I refer, of course, to "digital signature": if one signature is within the scope of another signature, then the first signature must have been applied before the second one.  If we were to allow your policy statement: "AAA.timestamp < BBB.timestamp" to be tested by examining the scopes of integrity seals, such as digital signatures, then we would be able to enforce sequence with a digital signature infrastructure, as well as with the (at present, much less common) timestamp infrastructure.
 
We may be close to concluding that the RFC 3060 model, with modest extensions, is suitable for our needs.
 
Best regards.  Tim.
 
-----Original Message-----
From: Simon Y. Blackwell [mailto:sblackwell@psoom.com]
Sent: Friday, August 03, 2001 6:51 PM
To: 'Carlisle Adams'; 'xacml@lists.oasis-open.org'
Subject: RE: Thoughts on XACML Policy Model...

See embedded comments....
-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Friday, August 03, 2001 2:55 PM
To: 'xacml@lists.oasis-open.org'
Subject: 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. 

>> RIGHT ON!! 

 - 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. 

IMHO, that 3060 descended into OCTET was strange. It dictates implementation instead of model and I think it should be disregarded.

   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. 

>> IMHO the best way to handle this is to compel the policy definers to have time stamps associated with the objects they reference. This way one can just compare time stamps and there is no "pollution" of the language with procedure , e.g. AAA = true and BBB = true and AAA.timestamp < BBB.timestamp then. Note if objects, subject, and actions are all externalized, this should not be a problem.


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