OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] a couple paramaters questions


On Thu, 26 Aug 2004, Seth Proctor wrote:

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

Yes, but what harm is there?

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

How so?

If your combining algorithm processes policies sequentially, you can
devour the parameters along with the policy and combine the accumulative
result, and your space consumption stays relatively constant.

> and in the end has exactly the same effect in processing as having a
> single collection of inputs.

Ah, consistency! So, what's the problem?

> In practice, I'm willing to wager that no one uses more than one
> CombinerParameters element per Policy or PolicySet.

So?

> But we both have our (valid) opinions, so I guess let's table the tools
> discussion for now.

Okay.

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

You're right. That is the reason we have separate elements.

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

"Requiring" identifiers to be unique without a surrounding context is
extremely hard thing to conquer.

Furthermore, as far as two Rules, Policys [sic] or PolicySets having the
same identifier within the context of a combining algorithm, I see no
logical problem with. Within the context of a combining algorithm, the
Rule/Policy/PolicySet CombiningParameters refer to all Rules, Policys
[sic], and PolicySets with the respective corresponding ids (within the
context of the combining algorithm).

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

Well, then, let the type system speak for itself.

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

Really? How so?

I thought a PolicyIdReference's URI was supposed to "point" to a Policy
with the same identifier? Hmmm.

> seth
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]