OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] wd8 multi profile comments


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.
> 
> > 	* 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.

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

Regards,
--Paul



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]