Re: [xacml-comment] A002

[John Merrells <merrells@jiffysoftware.com>]

Thanks for the detailed explanation Anne. This is much clearer to me now.
I'll try to describe below why I was unable to glean this meaning from the
specification.

Anne Anderson - Sun Microsystems wrote:

>In our model, the Context Handler is the functional component that handles
>any translation between the PEP's request format and an internal representation
>consistent with a Request Context, fetches attributes from the Request Context
>(or from an internal representation consistent with a Request Context)
>and from repositories, and handles any translation of the Response into the
>PEP's expected format.
>
This was clear to me. Figure 1 and its description show this well.

>The "signature" of the interface between the PDP and the Context Handler
>module has two inputs: an AttributeDescriptor or AttributeSelector, 
>
This was not clear to me. Firstly, figure 1, which I admit is 
non-normative, does not
show this. It shows the request context going in (arrow 8) and the 
response context
coming out (arrow 9). It does not show a bunch of calls from the PDP to 
the CH
requesting attributes.

Reading 7.9.2 again I see that it is actually saying this, I just didn't 
get it:

"The PDP SHALL request the values of attributes in the request context 
from the
context handler."

I took 'request context' to mean the thing that is passed from the CH to 
the PDP...
in other words the Request element. Perhaps 'request context' should be 
explictly
defined in the document to be all attributes within the system, whether 
within or
outside the Request? 'context handler' could also be capitalized.

eg. "The PDP SHALL request attribute values from the Context Handler."

The following assertion in 7.9.2 also caused me problems...

"The PDP SHALL reference the attributes as if they were in a physical 
request
context document, but the context handler is responsible for obtaining and
supplying the requested values."

What does that mean? The phrase 'the attributes' should probably be 
'attributes',
and the 'but' clause is a repeat of the previous assertion, so we're 
left with...

"The PDP SHALL reference attributes as if they were in a physical request
context document."

I don't get it. Why 'as if''? Does 'reference' mean request? So the PDP will
request all attribute values in the same way, and not have different ways of
requesting different attributes?

>As the XACML PDP evaluates a policy, it will encounter various AttributeDescriptors
>and AttributeSelectors.  Each time the PDP encounters one, it passes the information in that 
>descriptor or selector to the Context Handler.  The Context Handler searches for
>a match among the attribute objects it has parsed out of the Request Context
>received from the PEP.  If the requested attribute is not there, then the Context
>Handler queries its configured attribute sources (LDAP directory, SAML attribute assertion
>repository, file of attributes, on-line AA, etc.) for a matching attribute, passing the
>AttributeId, Issuer, etc., and the values of any corresponding subject-id, resource-id, or action-id
>attributes (as appropriate to the type of descriptor).  If there is no attribute 
>available from the configured attribute sources, then the Context Handler returns 
>either an empty bag or "Indeterminate" to the XACML PDP, depending on the value
>of the "MustBePresent" input.  If the "MustBePresent" value is true, then the Context 
>Handler returns "Indeterminate".  If the "MustBePresent" attribute is false, then the 
>Context Handler returns an empty bag.
>
>In the context of a Condition, the XACML PDP passes the returned value to the enclosing
>function.  Most, if not all, standard XACML functions return "Indeterminate" if one of 
>the inputs is "Indeterminate", but extension functions might not.  It is up to the definition
>of the function.  Similarly, if the resulting function does not take a bag as its input,
>but a bag is passed to it, then standard functions return "Indeterminate", but extension
>functions might not.
>
>In the context of a Target, the XACML PDP either passes the "Indeterminate" result to the
>enclosing function, or else passes one element at a time from the
>bag result to the enclosing function.  Again, the result depends on the definition
>of the enclosing MatchId function.
>
Yeah, I'm fine with all this, thanks for walking through the processing, 
I just didn't see
that the PDP was supposed to ask the CH for the value of attributes that 
were referenced
in a policy, but didn't exist with the request document.

>I expect that A002 and the two E tests (which require fetching policies and
>policy sets from external sources) will probably be the most difficult to
>implement, 
>
I didn't actually have any problem with policy references... 5.18 and 
5.19 are clear enough.

John