Re: [xacml] a couple paramaters questions

[Seth Proctor <Seth.Proctor@Sun.COM>]

On Thu, 2004-08-26 at 11:03, Polar Humenn wrote:
> On Wed, 25 Aug 2004, Seth Proctor wrote:
> 
> > In the current draft (13), I see that both PolicySet and Policy let you
> > specify CombinerParameters, but in both cases it's inside the choice
> > that allows any number of parameters. Since CombinerParameters is
> > already a container for any number of parameters, why do we need to
> > allow more than one per Policy[Set]? I can't figure out what value this
> > adds.
> 
> It's funny that the guys who like less structure, always want more
> structure constraints. (I could make a political oriented joke here, but).

Huh? Are you saying that I don't like structure? Where does this come
from? More to the point, how does it help this discussion?

> The value is that you may define each set of parameters along with the
> rule (or policy) next to each other.  It has its advantages in generating
> policies from tools.

Ok, but I'm not talking about the parameters for a specific rule or
policy (I get to that later). I'm talking about the general parameters
used for all rules or policies. I see no reason why I would ever have
more than one collection of these parameters.

As for tools, I don't buy that argument. Tools don't care where you put
elements in an XML tree. People may care, but tools do not.

> > Unless I'm missing something, I'd like to see only one optional
> > CombinerParameters per Policy[Set], which not only simplifies the
> > schema, but also the spec, since we currently explain in a number of
> > places that having multiple CP elements just results in them being
> > concatenated together. If we only allowed one block, then we could
> > remove all the extra text.
> 
> So, why the restriction? Does it make it [the XML] look neater?

I've already explained why I'd like to see this "restriction." I don't
see any value, and we could remove many sections of text that explain
how to handle the case where we have multiple blocks of general
parameters. Yes, it would also make the XML much neater (and, arguably,
much easier to work with as a person or a tool), but that's not my
primary concern in this case.

> > A related question has to do with parameters for specific
> > Rules/Policies/PolicySets. We don't have different CombinerParameters
> > types for policy and rule combining algorithms, but we do have
> > different ones for policyset, policy, and rule. Why is this?
> 
> Those combining parameters, since you brought it up, I suspect that the
> specification may be actually deficient in this regard, refer to
> particular rules, policies, policy sets. And that reason is because they
> refer to rule-id, policy-id, and policy-set-id respectively. Since there
> is no convention on the structure of those id's there, needs to be a
> construct to distinguish them.

Ok. So basically you're saying that reason I give below is the only
reason, ie, that we want to allow policies and policysets to have the
same identifier and so we need different elements to disambiguate. If we
simply said that a policy and policyset cannot use the same identifier
more than once, then there is no problem, and personally I'd rather see
this approach anyone, since I think it should be illegal to have
multiple policies with the same identifier (what would that mean,
anyway?).

> > The three all behave the same way and have the same contents. The only
> > rationale I can think of is that this allows a Policy and a PolicySet to
> > have the same identifier, but we already handle this case, in fact we're
> > explicit about this in the text explaining how parameters for references
> > are handled.
> 
> How so? We have PolicyRef and PolicySetRef for the same exact reason.

No, you misunderstand. I am referring to the fact that it's illegal to
have (for example) a Policy with an identifier that is the same as the
URI from a PolicyIdReference in the same PolicySet. If we simply said
that all identifiers at a given node must be unique, then we wouldn't
need three different kinds of parameters, since we only need different
elements now to help in disambiguating identifiers.


seth