MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Comments on XACML v3.0 administration policy, Draft 06
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
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]