Re: [xacml] New core and multiple resource profile

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

Thanks for the careful review. See responses inline.

Regards,
Erik

Rich.Levinson wrote:
> Hi Erik,
>
> I just went over the changes to multiple resource profile and have the 
> following questions:
>
>    1. Section 2.4.3, line 186: Should this say "The Context Handler
>       MUST construct ..."? i.e. it would have to in order to be
>       consistent w the other sections, since this is higher level and
>       includes those sections conceptually - lines 196-198.
>

Yes, this should be the same, if not for any reason that users would be 
confused about what the difference is. So, I agree with you, change 
"PDP" to "context handler".

>    1. Section 2.4.3, lines 190-191: This says that the <Attributes>
>       elements in the generated Request must be in the same order as
>       what? The order of the <AttributesReference> elements in the
>       RequestReference? Assuming so, main question here is whether
>       there is any significance to this order. i.e. does it matter in
>       an ordinary request what order the Attributes elements, each
>       with a different Category come in?
>

Yes, you are right. It doesn't really matter in 3.0. It would have 
mattered in XACML 2.0, where XPath expressions can span the entire 
request context. I was mentally in the mode of not tripping over XPath 
ambiguities. We could drop this requirement.

>    1. Section 2.4.3, lines 192-194: I am confused by this paragraph.
>       It says: "If ..., there MUST be exactly one Response ...". My
>       impression is that it is always true that there must be one
>       Response for everything in the original Request, and that if the
>       original Request is broken up into multiple individual Requests
>       by the ContextHandler, that then each of those individual
>       Requests will produce one or more Results and all the Results
>       from all the individual Requests will be packaged into one
>       Response. It also seems to say this as an after thought on line
>       198-199. It would probably be better, if that is what is
>       intended to state this at the beginning and not piece it
>       together along the way.
>

I just wanted to be clear on this point, since we are constructing 
multiple new <Request> elements, so someone could think of that there 
will be multiple <Response> elements as well. I think the text is good 
as it is.

>    1. Finally, I have a question on correlation of Results to
>       RequestReferences. The RequestReference uses the xml:id as we
>       all agreed to identify each Attributes element involved with the
>       RequestReference. So, how now are we supposed to correlate the
>       Responses? This issue was discussed at length in Jan but seems
>       to have dropped out of the picture without any clear resolution.
>       It would seem possible with xml:id, that possibly each
>       RequestReference could have its own xml:id and that this xml:id
>       could be put in the Result element by the ContextHandler while
>       it is constructing the Response.
>

The responses are correlated with IncludeInResult="true" on some 
attribute. In some cases the attribute may be "artificial" if there is 
no natural unique id already.

>     Thanks,
>     Rich
>
>
> Erik Rissanen wrote:
>> All,
>>
>> I have posted new drafts of the core and the multiple resource 
>> profile. See the change logs and tracked changes for details.
>>
>> As far as I can tell, we don't have any open issues on the following 
>> specs:
>>
>> - Core
>> - Multiple resource
>> - Administration
>> - Privacy
>> - SAML
>> - Dsig
>>
>> The hierarchical profile is being discussed currently and there was 
>> discussion about improving the RBAC profile.
>>
>> The proposed work on the RBAC profile seems in very early stages and 
>> the issue (policies about management of roles) is a major topic, so I 
>> propose that we don't bring this in 3.0.
>>
>> So, could we agree on a feature freeze on the above mentioned 
>> profiles? If so, all of the expect hierarchical are ready for review 
>> before going to committee draft.
>>
>> I also propose that if we don't get resolutions on the issues in the 
>> hierarchical profile soon and it would appear that there are major 
>> changes required, then we use the old version of that profile. 
>> However, my understanding is that Rich has pretty much completed the 
>> work on that. I haven't had the time to review it myself yet, but I 
>> will do so now.
>>
>> So, given the above, can we agree on the following?
>>
>> - everybody reviews the above mentioned profiles
>> - We correct any mistakes
>> - I will fix the metadata, references, namespaces, etc,
>> - Go CD with the above
>>
>> One final issue: we need to update the acknowledgements section of 
>> the core. What goes in there? My name is not in there, and I would 
>> like to include it. :-) I presume that we keep all the old names, 
>> right? John Tolbert has requested to be added. Anybody else?
>>
>> 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