Re: [xacml] a couple paramaters questions

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

On Thu, 2004-08-26 at 13:09, Polar Humenn wrote:
> 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.

I agree that this is useful, but isn't this what a
[Rule|Policy|PolicySet]CombinerParameters is for? It lets you specify
parameters associated with that element. I just don't believe that I
will want to specify parameter-agnostic inputs to a combining algorithm
and still associate chunks of them with different elements being
combined.

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

I've been building tools for a long time, and specifically XACML tools
for several years now. You're actually arguing for a feature that will
take up more space and take more time to process, and in the end has
exactly the same effect in processing as having a single collection of
inputs. In practice, I'm willing to wager that no one uses more than one
CombinerParameters element per Policy or PolicySet. But we both have our
(valid) opinions, so I guess let's table the tools discussion for now.

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

I understand. In my original email I asked if this was the reason for
needing separate elements. I was just trying to figure out if I'd lost
some discussion thread along the way.

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

There's no problem, I'm just trying to understand this issue fully. It's
actually no extra work to verify that no ID is used more than once, and
having non-unique identifiers can be a big problem when you think about
tools or retrieval mechanisms. So, yes, I would like to see us require
that identifiers be unique, but that's obviously not happening for 2.0.
FYI, you will also know what IDs or refernce URIs you're dealing with.

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

I'm not trying to dismantle any type system. I'm just trying to provide
as much clarity as we can.

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

That's possible. I haven't seen many of those :)

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

Agreed.

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

Agreed again.

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

Sorry, I mean "some element in a policy tree" (Policy Set, Policy,
Rule).

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

Yes, we do, of the form I described. A Policy's identifier and a
PolicyIdReference's URI cannot be the same. We say so in 2.0 (I think).


seth