RE: [xacml] Re: Section 7.2 Base policy (was A single tree?)

[Polar Humenn <polar@syr.edu>]

I find, in the many specs that I've had experience with, if you don't have
something definitive to say, say nothing about it. When you give an answer
that seems to make mandates on points you don't control, because you don't
control them, you cause confusion.

The question "what if I find...." is not really relavent, because the spec
is about:

Here is *the* Policy.
Here is *the* RequestContext.
and, *this* is the defintiive answer.

It's not about *finding* policies, it's not about creating them on the
fly to represent some fictious requirement.

If we were writing some query language for retreiving policies, then we
would have a purpose and directive in that area.

That question is like having an standard for driving a car. One day, you
find your Honda and your Mercedes both your driveway. Do you look in the
Driving Standard to find out what to do?

Of course, it might say "You take the Mercedes."

unless, of course, you're married, and they didn't print the "over my dead
body" scenario in the standard.


Cheers,
-Polar




On Tue, 13 Apr 2004, Tim Moses wrote:

> Personally, I expect readers to ask (and that the authors should anticipate
> the question) "What if I find more than one policy that is applicable to the
> request?"  I don't object if we say "That's out of scope" or "Look in the
> LDAP - or some other - profile".  But, I don't think we should stay silent
> on the topic.  All the best.  Tim.
>
> -----Original Message-----
> From: Polar Humenn [mailto:polar@syr.edu]
> Sent: Tuesday, April 13, 2004 12:23 PM
> To: Anne Anderson
> Cc: seth proctor; XACML
> Subject: [xacml] Re: Section 7.2 Base policy (was A single tree?)
>
>
>
> 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
> >
>
> 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.p
> hp.
>