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] xacml, policy, issuer, combinator parameters...

comment, of course, by me, :) in line.

On Thu, 15 Jul 2004, Frank Siebenlist wrote:

> First "my" philosophical/religious reason to make the policy and issuer
> inseparable, are based on the believe that there is no policy statement
> without an issuer - it just doesn't make sense. There is alway some
> subject (implicitly) associated with a statement. The only reason we
> have been able to ignore the issuer so far, is that the local "PDP" (or
> how ever we want to call that local authority) has been the implicit
> issuer of all the policies that it considers.

There in lies the rub.

The PDP "issues" the policy, but it almost certainly didn't write it.

You can imagine a library where policies are stored and integrity
protected, but not "issued". The effectively are "issued" when they are
placed inside a PDP.

My problem with the <Issuer> being inside the policy is taking the policy
and when "accepting" it into the PDP, changing the <Issuer> to something

When you add a CombinerParameter into a policyset and associate it with a
particular policy, you are doing that at policyset writing time,
effectively "accepting" the policy into the policy set.

Note, this approach will work for rules inside a <Policy> as well, with no
great effort, To get the same capabilityh you would have to add and
<Issuer> to a <Rule> as well.

> Which would point at another criteria for inclusion: a policy element
> should (at least) include all elements/attributes that make it a
> "policy".  In other words, a policy should be a tuple that conveys the
> "semantical" meaning of a policy... For me this would put the target and
> rules back into the policy envelop ... as well as the issuer.

The <Target> of a policy is not so much meta-data of the policy as it is a
predicate of the policy. The semantics of the target is that the predicate
specified as such must be satisfied in order for the policy to be
considered applicable. (whether there is a further applicable decision is
another question).

The only thing we might argue is an attribute or meta data of the policy
that is INSIDE the policy is the policy-id. It has no functional aspect to
the evaluation of the policy itself. However, the only reason it exists is
to reference it. And there are definite problems with it. (I don't like
Policy/Set Ids/References, but I lost that battle) :)

> The other parallel I see is with the attributes we have, which also have
> issuers associated with them. The attributes came in through some form
> external assertions, like SAML. Why did we decide to add the issuer to
> the attribute, and why didn't we add attribute issuer as a combining
> algorithm parameters?
> The reason for the latter is probably more historical ... but suppose we
> could do it over again and start from scratch: where should the
> attribute-issuer association be kept?

The <Attribute> is part of the Request Context, and as such the issuer of
the attribute is stated in the ReqeustContext, not a Policy.

The CombinerParameters, which are inside a policy or policyset, associate
values to Policies, not Attributes found in the RequestContext.

> The practical/pragmatic reason is of course that we wouldn't have to
> make any schema changes to the PolicySet/Policy type elements, which is
> only a valid argument if we have to cut corners and such...
> A related reason would be that we are still uncomfortable with all this
> delegation stuff, and that a combining algorithm parameter solution
> allows us to side-step the whole issue at the expense of some elegance
> and purity...
> In conclusion, adding the policy-issuer association as a combining
> algorithm parameter would work but IMHO it is a butt-ugly hack... and I
> would prefer to add the issuer info to the policy element.
> Regards, Frank.
> PS. Polar mentioned that there are possible "issues" when the issuer
> would be included in the policy, but without giving more details it
> sounds like FUD to me ;-)

One of the chief issues I keep on about is the problem with conflicting

Say there is a policy A written by Bob. Is Bob the issuer?

Say Alice, a policy administrator, pulls policy A out of a library, and
puts in into her PDP? Is the issuer Bob? Or is the issuer Alice? Is Alice
allowed to Change the <Issuer> element in the policy to herself?

Let's say Alice is writing a PolicySet. The point at which she "accepts" a
policy into a PolicySet is the point in which she places the policy (or,
gak! its reference) into the PolicySet. That is the point in which she
decides who is the effective issuer.

If she got Policy A (with <Issuer>Bob</Issuer>) she is mandated to either
accept the fact that Bob is the issuer (and whatever that really means),
or not accept it. Alternatively, she can change (or copy) and change the
<Issuer> effectively rewriting the policy.

These are the steps I don't like:

1. You are mandated to accept the fact that Bob is the issuer or not.
     (reason: I don't want you telling me how to administer policies).
2. The fact that you can "change" a policy once the effective meaning of
   that policy is established within the structure.

You have to do 2 if you don't adhere to 1.

Second of all, this <Issuer> element is *only* going to have meaning in
the application of these fancy, iterative, Combining Algorithms that pay
attention to this element.

Therefore, putting the issuer in the combiningParameter for that
particular combining algorithm makes more sense.


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