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] Re: Section 7.2 Base policy (was A single tree?)


On Thu, 15 Apr 2004, Seth Proctor wrote:

>
> Are these beliefs in conflict? No, I don't think they are. At the start
> of this thread, Anne made a proposal for new text for section 7.2. I
> think it makes a lot of sense. It defines exactly one requirement: a PDP
> can only evaluate a single policy against a given request. If the PDP is
> incapable of deciding on a single policy for evaluation (though whatever
> means it likes), than this is an error.

> Her text does not require a "retrieval step", it does not mandate
> dynamic policy creation, and it does not exclude implementations where
> the PDP is configured to work with multiple policies (since the PDP is,
> in effect, using its custom logic to create a logical root policy).

So you are not talking about a "retrieval step", but you are talking about
a decision procedure of "deciding on a single policy", which is sort of
the same thing.

I still don't see the difference.

> Speaking from experience, I can say two things with certainty:
>
>   1. This text is useful for implementors. I spent a lot of time
>      thinking about how my code would react to the arrival of a
>      decision request. After re-reading the spec many times I
>      built something that provides a lot of flexibility but still
>      requires there to ultimately be a single root policy (phyiscally
>      or logically) for any given request. Clear text spelling this out
>      will help others to figure this out.

And that is your particular implementation. It may not be mine, and it may
not be somebody else's.

>   2. I get a lot of questions from users about this issue. They want to
>      understand exactly what the rules are around root policies. Anne's
>      text makes it clear what's in scope, and what XACML doesn't define.
>      I believe this will help considerably.

I have no problem with an "implementers guide", as long as it is a "guide"
with suggestions, not mandates. If you want to build it this way, you do
A, B, C, and D. etc.  If you want to build it this other way, you do, A,
B, D, E and F. It's all non-normative.

> In short, I don't believe the proposed text for 7.2 defines how you find
> a policy, how you construct a "base" policy, or how a PDP handles the
> policies it can use. The proposed text only specifies that logically
> evaluation is of the form one Request and one Policy[Set],

I have no problem with that definition up to this point.

> and that trying to do otherwise is an error.

and there I loose you, somewhat. It depends on what you mean by error. If
you mean I have to deny, then I really loose you.

> I belive this is what's already expressed in the specification, but that
> the new language helps clarify this point, and will be helpful for
> implementors and users alike.

The spec is right to say that an XACML evaluation is defined between ONE
Policy[Set] and ONE Request. Nothing else need be said.

Cheers,
-Polar


>
> As always, I welcome comments!
>
>
> seth
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>


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