[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New core and multiple resource profile
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]