Public Comment

[comment-form@oasis-open.org]

Comment from: rgrzywinski@yahoo.com

I've been reading through the XACML specification you have worked on and I have some questions / issues that I would appreciate feedback on.  (I have not used this comment system before so I apologize in advance if there are formatting issues.)

*  Initial note:  I know that XACML is not a protocol specification.  The reasons for this note will be evident as you read on.

o  Attributes 

   Assumptions:  the PEP is separate (linked via network) from the PDP (and potentially any context handler)

   Question:  It is -implied- throughout the specification that the attributes required for a decision request are passed from the PEP to the PDP in the <Request>.  Since it is not possible for the PEP to know a priori what attributes are required, nor is it feasible to include every possible attribute, (as some may be expensive to compute or too large to send) what is the current thinking for the retrieval of these attributes?  

   Possible solution 1:  Figure 1 shows an attribute query from the context handler to the PIP.  It is possible for a PIP to exist on the same machine as the PEP and an out-of-band query is perfomed from the context handler to retrieve any required attributes.  This would imply that the communication is outside of the realm of the XACML spec.  The addition of a statement (perhaps in one of the examples) indicating that it may be necessary to retrieve other attributes from the PEP that are not present in the <Request>, may resolve this issue.  This additional statement appears to be in scope given sections 2.5 and 2.7.

   Possible solution 2:  A second request / response is added to the existing communication that would query for the required attributes.  This is an in-band solution and would increase the scope of the current specification which is likely not desired.

   Use case:  Policy associated with a decision request includes a QoS component from the PEP (such as the load average of the machine on which the PEP resides).  The QoS attribues are too expensive to compute (and whose computation may actually affect the QoS) and send with each <Request>.

   Use case:  A PEP is located within an MTA (mail transport agent).  Some policy decisions are made on Bayesian filter results of the email message.  These results are too expensive to compute for each email and the email contents are too large to send with each decision request.  These attributes should be requested from the PEP IFF a condition requires them.
 
o  Obligation scope

   Part 1:

     Background:  The specification states that obligations will be carried out on the PEP and that if "the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource" (section 6.10).

     Assumption:  The PDP logs all authorization decisions for auditing.
                  QoS policy decisions are made based on -actual- results of authorization decisions.

     Question:  How does the PEP inform the PDP of the -actual- decision?

     Possible solution 1:  An out-of-band response is sent from the PEP to the PDP.  This would imply that the communication is outside of the realm of the XACML spec.  This approach reduces the affinity of the actual decision from the initial decision request causing potential auditing problems as a second communication channel needs to be authenticated and maintained.
 
     Possible solution 2:  A follow-up response is made from the PEP to the PDP.  This is an in-band solution and would increase the scope of the current specification.  Addressing this issue in the specification as a "protocol issue" may clear up any ambiguities.

   Part 2:

     Lines:  1768 - 1770, 2731 - 2733, 2756 - 2757, 2859 - 2862
     "It MAY include a set of obligations that MUST be fulfilled by the PEP.  If the PEP does not understand an obligation, then it MUST act as if the PDP had denied access to the requested resource."

     Question:  Has there been consideration to change the language from "does not understand" to "does not understand or cannot fulfill"?  If not, what is the recommended action for an obligation that is understood yet is unable to be fulfilled.

     Possible Solution:  Expand the definition of "understood" to include compliance meaning that an obligation is "understood" IFF it can be interpreted and has all necessary attributes (the traditional meaning of "understood") -and- fulfilled.

     Follow up 1:  lines 3060 - 3062 use the "fulfill" terminology.

     Follow up 2:  the mixing of the terms "understood" and "fulfill" in multiple contexts leads to much ambiguity.

   Part 3:

     Background:  The specification states that the obligations will be fulfilled on the PEP.  (I should point out that the specification does not say that the obligations cannot be carried out elsewhere, but I will assume that obligations are only fulfilled on the PEP.)

     Assumption:  It is assumed that the implication from Part 2 (above) is that the PEP must both understand and successfully fulfill the obligations in order for access to be allowed.
                  It is implied that the obligation is fulfilled at the time of the response in order for the PEP to potentially deny authorization.

     Question 1:  Can components, other than the PEP, fulfill obligations?  And if not, has any consideration been given to extending obligations to other components?

     Use case:  The PEP for a web service is located on a web server.  An obligation requires that a record from a data store (which is located on a separate machine) is deleted.  The PDP dispatches the obligations to a central "obligation service" which then dispatches the obligation to the data store.

     Follow up:  The use case outlined above is technologically possible given figure 1 of the specification.  The concern is that it is not feasible for one primary reason:  a PEP, located in a DMZ, cannot be trusted to initiate such requests back out of the DMZ.  The PDP would be a better choice.

     Question 2:  Has there been any consideration to delayed obligations and their effect on the ability for a PEP to deny an access based on their result?

     Use case:  The obligation is to delete a record after a period of 30 days.  (This was derived from the P3P specification.)

   Part 4:

     Lines:  2076 - 2077 compared with 1768 (for example)
     "The <Obligations> element SHALL contain a set of obligations that MUST be fulfilled by the PDP in conjunction with the authorization decision."

     Question:  This appears to be in conflict with the other normative sections of the specification.  There are no other references to the PDP fulfilling the obligations and appears to be in conflict with 5.35.  Is this a typo?  It is possible that I'm overreading this but the phrase "by the PDP" appears to be in reference to "MUST be fulfilled".



Thank you for your time.