Re: [xacml] wd8 multi profile comments

[Erik Rissanen <erik@axiomatics.com>]

Hi Paul,

Thanks again for your careful review. I have fixed most of these issues 
for the next working draft. See inline for exceptions.


On 2009-12-23 18:31, Tyson, Paul H wrote:
> Chair(s):
>
> 	* Hal Lockhart affiliation and email address
>    

The same error was present any several of the profiles, so I fixed them 
all. Also, although in some of them Hal's affiliation was correct, his 
email address was different from the one he is currently posting under 
at the TC list, so I updated that as well.

> Abstract:
>
> 	* change to "This document provides a profile for requesting
> more than one access control decision in a single XACML Request Context,
> ..."
>
> Section 1:
>
> 	* Revise opening to "The policy evaluation performed by an XACML
> Policy Decision Point, or PDP, is defined in terms of a single decision
> request in the XACML Specification [XACML], with the authorization
> decision contained in a single<Result>  element of the response context.
> A Policy Enforcement Point, or PEP, however, may wish to submit a single
> request context for multiple access control decisions, ..."
>
> 	* 2nd paragraph: change "can request authorization decisions for
> multiple resources" to "can request multiple authorization decisions".
>
> 	* 3rd paragraph: change "mechinism" to "mechanism".
>
> Section 2:
>
> 	* 1st paragraph: change "request for access to multiple
> decisions" to "request for multiple access control decisions".
>
> 	* 2nd paragraph, 1st sentence: change "request for access to
> multiple decisions" to "requests for multiple access control decisions";
> change "each requesting access to exactly one of the decisions" to "each
> requesting exactly one of the decisions".
>
> 	* 2nd paragraph: change "Each such decisions" to "Each such
> decision".
>
> 	* 2nd paragraph: refer to section 4 for details of the model for
> creating individual decision requests.
>    

I don't understand what you mean. Do you just want to add this text to 
the end of the paragraph?

> 	* 3rd paragraph: change "requests for access to multiple
> decisions" to "requests for multiple access control decisions".
>
> Section 2.1:
>
> 	* The "scope" resource attribute is defined in Section 5.
>
> Section 2.1.3
>
> 	* Remove sentence that begins "If a<Content>  element was
> present..." (this section does not apply to XML content).
>    

I don't agree with this. Firstly, if we simply remove this sentence, 
then it becomes unclear what the PDP should do with the content.

Also, I don't think the <Content> should be dropped. It should be kept 
as it is. It's analogous to any other <Attributes> which may be present 
in the initial request. These <Attributes> apply to all resources in the 
hiearchy. In a similar fashion, <Content> can be used to provide more 
information/attributes of all resources in the hierarchy.

> Section 2.2.3
>
> 	* 1st paragraph: change to "Such a request context SHALL be
> interpreted as a request for individual decisions regarding each of the
> nodes in the nodeset selected by the XPath expression given in the
> <AttributeValue>  of the "multiple:content-selector" attribute."
>
> 	* 3rd paragraph: change to "If multiple<Attributes>  elements in
> different categories contain a "multiple:content-selector" attribute,
> then the set of Individual Decision Requests will be formed from the
> cross product of the nodesets selected by the
> "multiple:content-selector" XPath expressions in the different
> categories.  See Section 4 for detailed description of the processing
> model."
>
> Section 2.3
>
> 	* Title: consider changing to "Repeated Attributes categories"
> (because "repeated" implies "multiple").
>
> Section 2.3.3
>
> 	* 2nd paragraph: change "according to the corresponding Section
> of this Profile listed in Section 5.1" to "according to the processing
> model specified in Section 4".
>
> Section 3
>
> 	Item 1 specifies that the Result must not have any Attributes.
> Does the context handler ignore "IncludeInResult" requests, or is it an
> error if the request context has any IncludeInResult="true"?
>    

When I wrote it, I had in mind that the the IncludeInResult would simply 
be ignored, but this is a good point. I wouldn't mind it being an error, 
that would be more consistent with the expected response for such a 
request, but I'm not sure there is really any harm, so we could allow 
it. For now, I clarified it to:

1.    There MUST NOT be any <Attributes> elements in the combined 
<Result>, regardless of the values of any of the IncludeInResult 
attributes of the <Attributes> elements.

If there is a general agreement for otherwise, I will change it.

> 	Title: consider "Conceptual model for creating Individual
> Decision Requests".
>
> 	1st paragraph: it's not clear to me what "nesting" means here.
> Consider changing to "This profile specifies several independent schemes
> for Multiple Decision Requests in sections 2 and 3. Any combination of
> features described by these schemes MAY be used in an initial request.
> This section defines a normative processing model to create Individual
> Decision Requests from an initial request context in which one or more
> features of the multiple profile are present.  An implementation MUST
> produce identical results to those that would be produced by performing
> the following operations in the given order."
>
> 	Steps 2 and 3: I suggest reversing these steps.  It would be
> cleaner to expand "scope" and "multiple:content-selector" first, because
> the result will always yield repeated attributes categories.  These can
> then be processed the same as repeated attributes categories in the
> initial request context (or result of expanding MultiRequests).
>    

Would you be ok with the current wording? If I re-order it, there is a 
risk that I mess up the cross references between the steps.

> 	Step 5: Replace with a reference to section 3 for producing a
> single combined decision.
>    

I updated step 5 to:

5.    At this stage all requests have been processed by the PDP and the 
inputs to this step are all collected Indeterminate results from the 
previous steps and all the individual results from step 4. If 
applicable, perform the processing defined in Section 3.

Is this what you had in mind?

In any case it's good you mentioned this section. It contained a 
reference to DecisionCombiningAlgorithm which I had forgot to remove.

Best regards,
Erik


> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>