Re: [xacml] Concrete Proposal of ConditionReference (#7)

[Polar Humenn <polar@syr.edu>]

On Thu, 19 Feb 2004, seth proctor wrote:

> I don't want to re-open this discussion, but just for the record...
>
> > This "current-time" attribute name is still burning us. The RequestContext
> > is "notional", but the information in it is not. All information must be
> > there. The Request must contain the "current-time" attribute (if used).
> >
> > The PDP has no concept of "current" time. I've said this time and time
> > again. :)
> >
> > You must supply the current-time in the RequestContext.  It is valid to
> > ask if Alice has access to a resource at any time, whether or not that
> > time is said to be "current" in reality.
> >
> > A PDP that supplies a value for the current time attribute is not correct.
> > It is the XACML Request Handler that will supply that attribute.
> > Therefore, in your scenario, your two requests would actually be
> > different.
>
> The specification clearly states in 10.2.5
>
>    If values for [current date/time] are not present in the decision
>    request then their values must be supplied by the PDP. So, unlike
>    most other attributes, their semantics are not transparent to the
>    PDP.
>
> I don't think it gets any clearer than that. A PDP that supplies these
> values is not only correct, it's a requirement.
>
> Do I think this is "burning us"? No. I do think, however, that since
> these attributes are special-cases, it's ok to call them out. That's why
> I suggested that we make those constrained over an evaluation (which I
> think was picked up for 2.0).

Generating these unfortunate attributes should be constrained to the
RequestHandler. Not the PDP. Ugghghhhhhhh!

So much for mathematical integrity!

> >>There is no such requirement in XACML. The RequestContext is amorphous,
> >>and therefore gives you no guarentees about anything remaining constant.
> >
> > If there isn't, it should be. I don't have the spec in front of me, but I
> > believe we mandated that a long time ago. At least I know I did.
>
> No. There is no such requirement, and I don't agree that there should
> be. I do agree that there's value in a ValueRef stype statement that
> lets you explicitly constrain values over the course of an evaluation,
> but that's a separate issue.

The "time" line of an evaluation should NOT even enter into the
discussion. 2+3 doesn't change its value over time, no matter if you do it
in your head, or you have your great grandmother do it with oranges.

> > Time information is like any other information in the request. There is no
> > notion of values changing throughout the coarse of an evaluation.
> > Implemenations that do so, may play that card in some hopes for
> > efficiency, as Daniel may have taken advantage of. However, those that do,
> > and do so in a way that yields different results for the same request are
> > in violation. Any "clarifications" to that effect of specific attributes
> > are redundant, and could lead to implications that for all other
> > attributes it is not the case unless specified.
>
> Let's be clear here. Implementations that allow referenced values to
> change over the course of an evaluation are _not_ in violation of the
> 1.0 or 1.1 specification.

That is EXTREMELY unfortunate, and any product that does that I wouldn't
put any faith in, let alone buy. This is why standards must adhere to
formalizisms that guarrantee the integrity of the products that are
deployed. I am sorry you feel the way you do.

> It is perfectly legal, and indeed expected, that the same Request may
> yield different Responses.

Who "expects" it? That's where you an I differ. Just because there is a
problem with the specification where it said "PDP" instead of
"RequestHandler", I WOULD NOT expect that behavior out of a quality
implemenation. Maybe bill gates does, but I do not. Sorry.

> There is nothing in the specification that says otherwise. I have
> re-read the specification several times in the last week, and I cannot
> find any language that says otherwise (other than the explicit statement
> about functions, which I mentioned in my earlier mail). Therefore,
> clarifications for the new def/ref mechanism are very useful.

We should definately recitify this problem. And it is a problem.
I am sure it was a mandate when we started that given the same request
context, the PDP MUST return the same answer, (with exception of error
cases). That is to say, if the PDP returns Permit for a particular
request, it will always return Permit for that exact request, or quite
possibly return Indeterminate, but never Deny. And the same argument
follows for Deny.

Cheers,
-Polar

>
> seth
>