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] Proposal on item 7 ConditionReference


On Tue, 9 Dec 2003, Daniel Engovatov wrote:

> >We've argued this same concept before, and we have consistently said
> that
> >the <Policy> was the smallest unit of adminstration.
>
>
> Smallest, yes.  But not the largest unit of administration, I suppose?

I agree.

> We do have information shared between policies.  Functions for example.
> What is a fundamental difference between a function declared somewhere
> else, and an expression declared somewhere else?

Good point. However, with functions, you only run into problems when you
venture from using just the standard functions. Then you are on your own,
and that has always been the case.

However, that is not the case with arbitrary expressions. We don't exactly
have "standard" expressions for "standard" values. We do, we call them
"constants".

> Policy evaluation trusts data from the context, why not to trust a
> dynamically computed data?

The PEP is supposed to be *assured* that given a Policy, and a certain
Request Context, it will get the same answer every time it asks for an
evaluation of those two entities. This maintains integrity.

Add the complication of referencing a value expressed, or calulated
somewhere else leads to complications ensuring the integrity. You have to
put forth a lot of machinery in the specificaiton.

> In most cases a policy writer lives with the fact that a data type of a
> particular attribute is fixed and defined outside of the policy.  It is
> not declared in the policy - only used. PIP function is to provide the
> instance of the context, against which the policy is evaluated, and this
> instance is shared between policies.

Well, what does request context being "shared" really mean w.r.t. a
policy? I don't think of the Request Context as entity that is being
shared. It is merely an input specification to a function. Two policies
may be evalated against the same request context, but that doesn't mean
they are necessarily always sharing them.

PEP1  -->  PDP1 = PolicySet { PolicyRefA, PolicyB }


PEP2  -->  PDP2 = PolicyA

Here, two PEPs, with 2 corresponding PDPs. True, any request context given
to PDP1 is "used" by PolicyA and PolicyB each in their evaluations by the
requirement of the encompassing PolicySet. However, it is NOT the case
that *every* request context used by PolicyA is used by PolicyB as well,
such as in when PEP2 asks PDP2 for an access decision.

> It seems to me that there is nothing wrong with sharing not only static,
> but also a dynamically computed context data - but that would require a
> separate document to hold this policy data, with such a document being
> the description of the context (attributes and functions declarations).

Your PIP should calculate what it needs to and put it into the Request
Context to be evaluated against the policy.

> I agree that one <policy> should not reference anything in another
> <policy> document, so currently we can not share indeed.

Agreed.

You are looking for something else in order to specify the calculation of
the request context, but let us not complicate the argument here for
simple variable definition and reference within a policy.


Cheers,
-Polar

>
> Daniel.
>


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