Re: [xacml] Comments on XACML v3.0 administration policy, Draft 06

[Erik Rissanen <mirty@sics.se>]

Thanks Anne,

I have incorporated these suggestions in the latest draft which will be
out in a moment. The only comment I did not address was the second to
last one, since I am not sure what you wanted with that.

Best regards, Erik


Anne Anderson wrote:

>I have not yet finished working through the spec, but the first part of
>the spec would be easier to read with some of the following editorial
>changes.  Perhaps Erik can work some of these into the next draft.
>
>- Under "2 Use cases", clearly label 2.1.1 as "Use case 1: Policy
>administration" and 2.1.2 as "Use case 2: Dynamic delegation".  "Use
>cases #1 and #2" are referenced in 2.1.3 Discussion, starting at line
>24, but were not clearly identified as such.
>
>- 2.1.3 Discussion, line 26: that says that the [issuer] of one policy"
>
>- 2.1.3 Discussion, line 31-32: "It is still necessary to find a chain
>of policies back to the PDP in order for Fred's policy to be enforced."
> This is not part of the use case.  It is also a bit confusing to a new
>reader because the idea of a "chain back to the PDP" has not been
>introduced.
>
>- 3. Solution Overview..., line 3: I think we need a better term than
>"issued directly by the PDP".  In the XACML model, a PDP does not issue
>policies.  Perhaps "directly trusted by the PDP".
>
>- 3. Solution Overview..., general: There are four cases, and these
>could be more clearly identified.  See next comment for proposal.
>  Has <PolicyIssuer> AND <PolicyIssuerMatch>
>  Has <PolicyIssuer>
>  Has <PolicyIssuerMatch>
>  Has neither
>
>- 3. Solution Overview..., general: The semantics of the syntactic
>elements that make something an access policy or an administration
>policy are separated from the semantics of the two types of policies.
>Maybe have one section for "administration policy", giving syntax and
>semantics, and one section for "access policy", giving syntax and semantics.
>
>- 4.1.1 and 4.1.2, last sentence of each section says: "...Combining
>algorithms that can result in "Deny" SHALL NOT be used."  It would be
>good to have an explanation/justification for this requirement in the
>non-normative description.
>
>Anne
>  
>