Public Comment

[comment-form@oasis-open.org]

Comment from: kudo@jp.ibm.com

Here is my response at your comments.

Michiharu Kudo
------------------
> Obligation Scope
> ...
>   Part 1
> ...
>     *Follow up:  Here's the problem that I keep having to fight with:  
>     ...
>        So which is XACML?  A "language for -expressing- security 
>        policy" or a language for -communicating- security policy.  
>        Or both?

XACML is a language for -expressing- security policy for PDP. XACML 
also defines an XML-based syntax for making access request to PDP 
(e.g. "can this guy read this file?") and for receiving decision from PDP. 
XACML is NOT a language for communicating security policy.

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

The sentence "does not understand" might be a little ambiguous.
But the most important thing is that PEP must know how to enforce
the returned obligations. Once understood, PEP is responsible for 
how to fulfill the returned obligation. In this sense, if PEP does not
understand the obligation, then the access must be denied. Boldly
speaking, whether or not the returned obligation is really enforced
at PEP (or Obligations Service) is outside the scope of XACML. 
It is PEP's responsibility. TC will verify all the sentences in the 
spec along this line.

>   Part 3:
>    *Assumption: 
>         [Spec] Obligations are fulfilled on the PEP.  
>         [Rob]  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.

Obligation is fulfilled by the Obligation Service as Figure 1 shows.

>         [Rob]  It is implied that the obligation is fulfilled at the time 
>         of the response in order for the PEP to potentially deny 
>         authorization. In other words, to be able to associate meaning 
>         with the statement "If the PEP does not understand an obligation, 
>         then it MUST act as if the PDP had denied access to the requested 
>         resource" then there must be a clearly defined and consistent 
>         cause and effect in order to be deterministic.  (This all pertains to 
>         question 2 below.)

The obligation is not necessarily fulfilled at the time of the response.
Suppose "delete data in 90 days" obligation that means delete the data in 
90 days. It is impossible to fulfill this obligation at the time of the response.
This corresponds to delayed obligation you wrote in the later part.
If PEP believes that the obligations service guarantees the data deletion
in 90 days, it is also ok to "authorize" at PEP. 

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

Obligations Service should do.

>     Use case:  The PEP for a web service is located on a web server.  
>     ...
>     I should point out again that herein lies much of my confusion surrounding
>     the XACML specification.  If XACML is only defining a language for 
>     -expressing- policy then the specification should not make assertions as 
>     to where obligations are to be understood or fulfilled. 
>
>     If the committee does not feel that XACML should dictate where and 
>     when obligations should be enforced, then please make this clear in the 
>     spec as it is currently leaning away from this.

I understood your use case and the concern. I agree that the current spec
implies architectural assumption with regard to obligation. It might be 
an idea to remove Obligations Service component from Figure 1 and
writes "a returned obligation can be enforced at any component (if
implementation allows to do so) and XACML does not care".