Comments on admin spec aka delegation profile

[Rich Levinson <rich.levinson@oracle.com>]

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