Re: [xacml] a couple paramaters questions

[Polar Humenn <polar@syr.edu>]

On Thu, 26 Aug 2004, Seth Proctor wrote:

> 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?

Uggh. I just trying not to be so damn serious all the time. :)

> > 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.

The original use case was that you can associate in this collection of
parameters, by order, one or some collection for each rule/policy/set
based on the combining algorithm definition, say for "ordered" combining
algorithms. So, being able to define them in more than one place seems
reasonable, and yet has no adverse effect.

> 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.

Well, people write tools that do things, and having to write a tools that
saves up all the arguments, and has to put them into a special place,
which may indeed have to come before I have to write 10000 policies to a
stream, would have an adverse effect the writing of the tool. Especially
if I am to be processing each policy one at a time in succession.
Space/Time Efficiency. That's why. (I guess I'm just old, :^) and I just
spent a lot my experience writing compilers that had to run on machines
without much memory).

> > > 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.

So, above is the use case. Especially when I have to write policies and
their relevant parameters to a stream. I happen to think that space time
efficiency is a valid concern.

> 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.

It's not that we want to allow same identifiers, but we do allow the use
of any identifiers (which means that they *may* be the same identifier).
And yes, we need different elements to distinguish them, because of that
"feature".

> 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?).

What's the big problem? We have a solution to the problem that is easily
verified by the compiler.  Having to put in the extra work of finding that
no <Policy> uses the same identifier as <PolicySet> is a problem. And in
some cases, the ids that Policys [sic] and PolicySets use may not be in
your control. Hence, the distinction is needed.

We have a pretty tight type system here. Why torpedo it into obscurity?

Second of all, as I have stated many times before, there are more problems
with PolicyRef and PolicySetRef than a truffle pig in a swamp.

With our current approach, the RuleCombiningParameters points a rule with
the same id within the combining algorithm, otherwise, the policy
definition is invalid. Kind of like a undeclared variable in some
compilers. The same goes for PolicyCombiningParemeters, and PolicySet.
However, there is nothing stating that two policies cannot have the same
identifier in this context. So, therefore, two policies with the same
identifier can logically have the same set of arguments applied to it.

The problems I talk about stem from "referencing" a policy outside of its
context, i.e. some PolicyRef with a URI ? Well, you would think that a URI
actually only points to one thing. (or maybe nothing), but does it point
to 2 things? I don't know. It may point to something other than a policy?
If it does point to a policy, can it be trusted, etc. etc.

> > > 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.

I don't know what you mean by "node". Is there a definition? And why does
it have an identifier?

Furthermore, we don't have a constraint that says the ids must be
different. So, therefore we need these constructs.

Otherwise, we would have to invent a naming scheme that would disambiguate
rule-ids,policy-ids, and policy-set-ids.

I think the current approach (vs inventing a naming scheme) is:

1. much easier to define and adhere to
2. immensely precise
3. backwards compatible with current ids

Cheers,
-Polar


>
>
> seth
>