[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on admin spec aka delegation profile
Hi Erik, Based on discussion of 2.0->3.0 and use of the Categories in the admin spec, I have gone thru the admin spec and assembled the following comments. Most are typos and questions that I had reading the text that did not have obvious answers without looking at the whole thing and making deductions. However, I left those questions in the comments below to be considered as suggestions for clarifying the text for readers. Also there are a couple of items for the core spec. Finally, I rev'd v17 accidentally, but then checked and it appears v18 is simply the AnyOf, AllOf replacement so the line numbers did not change. imo, the spec looks pretty solid, but I'd like to make sure that I understand things correctly. In fact, my overall suggestion is that section 4 be beefed up considerably with clear concepts that would be helpful reading the rest of the spec. As it is now, what I found was that it was very obscure and difficult to understand until I walked thru the example, which is very good, notwithstanding the comments that I made to it below. Comments: comments on Delegation profile page 1: should it be called the XACML v3.0 Administration and Delegation Profile or something more descriptive of what it actually is than the current title, "Administrative Policy", indicates? core spec line 2154 should this say "policy" instead of "policy set"? core spec line 1966, 1968 should <DisjuntiveMatch> be replaced w <AnyOf> ? was probably missed by search and replace, core spec Suggestion: have parent AllOf in Target element rather than implicit "conjunctive sequence" Should example in section 6 replace <Disjunctive... with AnyOf, etc.? line 272 PolicySet needs policy-combining-algorithm moved up from line 275-276, line 274 Policy needs rule-combining-algorithm line 297 should there be a " " before "urn"? if so, then what about lines 285, 309? also check other Policys for similar line 506-507 should this replace "subjects, resources, and actions" with something about categorys? line 508 "or rule" should be "or by rule" in order to avoid ambiguity as to what can contain targets. line 509-514: I don't understand the point. Line 509 says that Policy 1 allows any situation which is an employee who prints on the printer. If they are already allowed, what is the point of granting the privilege to allow Carol to allow employees to print who are already allowed to print? (If the case is that an "administrative" policy does not actually grant the initial privilege, please state that explicitly, so as to give this use case some substantive meaning) line 91-103: on first and second readings, I did not "get" from this that the presence of a "delegated" category implies the policy is "administrative" as implied by the example text on line 510-511. line 83-84: further confusion on what characterizes admin vs access policys since this says "possible to write a policy which matches both types of request". line 558: refers to section 5.2.6, which is not in this doc line 561: should the PolicySet be considered "trusted" because there issuer? Also might want to mention this on line 506 as well. line 564: why do we want to consider the question of whether there is an "edge" between policy 4 and policy 2 line 569: why would an admin req to policy 2 answer the above question? line 624: please mention that "Bob" is the issuer of policy 4 here. line 505,556,622: please label these listings as Listing 1,2,3 or other referencable identifier. line 624-625: please state that the subject, resource, and action from "listing 2", the original request are copied to "listing 3" the admin request, and the subject, resource and action categories are transformed to "delegated". line 607-611: I understand that above this, Bob, is copied from policy 4 in listing 1, however, I do not understand why this "administrator" element has been added. Lines 628-629 say that the CH did this, but how would the CH know it needed to do this and how would it know Bob was in the administrators group? line 633-635: Since policy 2 is permit-overrides, why would one generate a Deny request here, since we already got a "permit"? line 638: I understand that policy 2 is not trusted so we keep going, but why did we not first try to go direct from policy 4 to policy 1? If this would have worked, why bother with policy 2? Oh, because policy 4 was issued by Bob? So, that above we have to look for policies where Bob is the "delegate"? If that's the case, then why do we talk about the "reduction graph" on line 564? Don't we just run the listing 3 admin request and it finds that Bob is the delegate of policy 2 automatically? I think the graphs just confuse things. They may be useful for referencing what is happening automatically, but the text makes it seem like they are some kind of construct that one needs to build into the PDP? line 692: listing 4 line 693: here it would useful to say that since Carol is the issuer of policy 2, that here she is the requesting "delegate" of listing 4. How come Carol doesn't get an administrator group or something else like Bob did? line 694: again, why a subsequent Deny when we are operating under permit-overrides? line 707: what if the PolicySet is not trusted, i.e. what if it had an issuer like "Carol"? Do we have to go all the way up the tree? i.e. can untrusted issuers create PolicySets that contain trusted Policys with which they could possibly override other protections? Thanks, Rich
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]