Re: Section 7.2 Base policy (was A single tree?)

[Polar Humenn <polar@syr.edu>]

Maybe it's the cloud my head is in from the flu from the last week, but I
still don't see what any of these requirements on how a PDP operates means
anything significantly helpful, and is in fact harmful.

I wish that we would admit to ourselves that the only REAL requirement of
the XACML specification is that when evaluating (whether that's a PDP or
Seth with a pencil and paper) an XACML Policy or XACML PolicySet structure
against the information in an XACML RequestContext structure, it will
produce a result according to the semantics explicitly defined within the
XACML specification.

I mean, for a certain <Policy> and a certain <RequestContext> and I
produce a result of Permit, and you get a Deny, you can tell me that my
implementation is not XACML compliant, and I might have a look at the spec
and say "Gee, you know, you're right."

People will lay trust down in the specification because we went to great
lengths and arguments to keep the specification type safe,
determinitistic, and implementable, and provide a simplistic model that
applies for access control.

If you tell me that I'm not XACML compliant because my implementation
happened to retrieve two "policies" for a particular request and made a
determination based on configuration parameters suitable for that
organizations policies. I'm going to get insulted to tell you "So what, go
take a friggin hike".

There is all this talk about retrieving Policy or PolicySets as if you are
supposed to pull XML out of a database, or even, wait! the PDP creating a
PolicySet! It's like your are trying to mandate some organization's
composition and operation of its components and the way it wants want to
store or retrieve their policies. You're trying to write requirements with
information that you don't have.

These "requirements" are words lost in the ether, because somebody can
still conform the REAL requirement of the specification and ignore all the
other stuff, because those "requirements" are basically out of scope of
what this document can and should be.

Cheers,
-Polar


On Tue, 13 Apr 2004, Anne Anderson wrote:

> I think "Section 7. Functional requirements", "7.2 Base policy"
> can be clarified.
>
> Here are the essential points:
> 1) PolicyCombiningAlgorithm is the only defined way for a PDP to
>    deal with multiple PolicySet or Policy instances.  This means
>    the PDP's ultimate evaluation interface can only evaluate one
>    PolicySet or Policy for a given Request.
> 2) We do not want to constrain where or how this one applicable
>    PolicySet or Policy is created.  It might be created by the
>    policy authoring mechanism, by the policy storage mechanism,
>    by the policy indexing mechanism, or by the policy retrieval
>    mechanism.
> 3) For well-defined behavior, we need to define a default for the
>    case where multiple Policy or PolicySet instances apply.
>
> Here is a suggested wording:
>
>   A PDP SHALL evaluate only one Policy or PolicySet instance with
>   respect to any given Request Context.  This specification does
>   not constrain how or when this single Policy or PolicySet is
>   created, selected, retrieved, or represented.  Among other
>   solutions, a policy authoring and storage mechanism MAY ensure
>   that there is only one applicable policy that can be retrieved
>   for any given Request; or, a policy retrieval mechanism MAY
>   construct a single PolicySet having a specified Policy
>   Combining Algorithm dynamically from all applicable policies in
>   the repository.
>
>   If for some reason more than one Policy or PolicySet is
>   applicable to a given Request at the point where the Policy or
>   PolicySet instances must be evaluated by the PDP, the default
>   behavior of the PDP SHALL be to return a result of
>   "Indeterminate".
>
> Anne Anderson
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>