Re: [xacml] wd8 multi profile comments

[Erik Rissanen <erik@axiomatics.com>]

See inline

On 2010-01-05 15:39, Tyson, Paul H wrote:
> See inline
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Monday, January 04, 2010 12:31
>> To: xacml@lists.oasis-open.org
>> Subject: Re: [xacml] wd8 multi profile comments
>>
>>      
>>> 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?
>>      
> The last two sentences refer to the "preceding model" for mapping an
> initial request to individual decision requests.  But we moved the
> normative definition of the model to section 4.  So somehow this needs
> to be reworded to make sense.
>    

Oh, thanks. I understand it now. I think the best way is to simply to 
move the sentences to section 4. The first paragraph of section 4 then 
becomes:

--8<--
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.  This Profile does NOT REQUIRE that the 
implementation of the evaluation of a request for access to multiple 
decisions conform to the model below or that actual Individual Decision 
Requests be constructed.  The Profile REQUIRES only that the <Result> 
elements SHALL be the same as if the model below were used. An 
implementation MUST produce identical results to those that would be 
produced by performing the following operations in the given order.
--8<--


>>      
>>> 	* 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.
>>      
> No, it's not unclear, because it says the resulting individual requests
> shall be identical to the original, with two exceptions.  There is no
> exception for<Content>, so it would be included by the first
> requirement.
>    

You are right. I will remove the sentence.

>>> 	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.
>>      
> If you leave it as is, you should add a loop condition to repeat step 2
> if there are repeated attributes categories.  It is a cleaner algorithm
> to resolve multiple:content-selector ahead of repeated attributes
> categories.
>    

How could there be repeated attributes categories after step 2 has 
already been performed? The order of processing appears entirely 
arbitrary to me.

Thanks,
Erik


> Regards,
> --Paul
>
>