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

[Tim Moses <tim.moses@entrust.com>]

Polar - You are being very definite on the subject of what the specification
is about.  Does this come from a reading of the charter?  My own feeling is
that our committee should develop specifications for implementing a
practical system for authorization.  I don't mind if our core spec. passes
on this particular topic (although I still think it should explicitly
acknowledge that there is an issue, albeit one that is out of scope).
Another spec. in the series (such as the LDAP profile) could offer
solutions.  Otherwise, different vendors' PAPs and PDPs will not solve this
question in an interoperable manner.  All the best.  Tim.

-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu] 
Sent: Tuesday, April 13, 2004 4:56 PM
To: Tim Moses
Cc: 'Anne Anderson'; 'seth proctor'; 'XACML'
Subject: RE: [xacml] Re: Section 7.2 Base policy (was A single tree?)



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_workg
> roup.p
> hp.
>