A note about PDPs

[Marlena Erdos <marlena@us.ibm.com>]

Dear Core Colleagues,

   I've done a bit of looking around for definitions of "PDP".  This
search was very very far away from exhaustive (I used Google), but what
I did find was in accord with my take on what a PDP is.  I also
looked around for notions of "policy decision" in general.  Policy
decisions cover a huge range of topics and policies.

  Because of time limitations I decided to not review the sources that
Jeff cites. (I figure he's done that already and some aren't
so easily available.).  So my sources aren't official standards
bodies (very far from it).  Even so, I think/hope you'll find
the discussion below persuasive.

  I'm going to show one definition  of PDP that I think fits well; then
talk about the existing definition and why I think we have some
confusion about the role of the PDP in an authorization decision;
and then I'm going to segue into a couple examples about the use of
a PDP in validating attribute assertions.  It is this use i.e.
the need to validate attribute and authN assertions that calls
for a different PDP than that used in authorization decisions.


A Definition Marlena Likes/

 PDP: A third party system responsible for handling policy
 decisions on behalf of PEPs.

 [This definition is from "Orchestream,a global leader in the development
of software  for activating services on and enhancing  the performance
of Internet Protocol (IP) networks."]


The Current Glossary Definition/

  (a) A [system] entity that makes policy decisions for itself
  or for other system entities that request such decisions. [31]

  (b) Synonymous with Access Control Decision Function. [10]


Here is part of the source of the confusion.  "b" refers specifcally
to an access control decision function (ACDF).  If we look at the
definition for the ACDF, we get:

  "A specialized function that makes access control decisions by
  applying access control policy rules [JDH1] to an access request,
  access control decision information (of initiators, targets, access
  requests, or that retained from prior decisions), and the context in
  which the access  request is made [10]."

Note that the only policy mentioned in the ACDF definition is access
control policy.  This is an important part of the SAML space and the
overall policy space but it is by no means encompassing.


Some Examples of Non-authZ Policy and Policy Decisions/

  In the case of SAML, part of the deal is "policy" about authN
assertions and attribute assertions.  Here's a example:  Let's say the
relying party is Brown Univer sity and the attribute authority(AA) is
owned and controlled by MIT. One of the attribute assertion policies
Brown might use with respect to the  MIT AA is, "Accept 'enrolled in'
attributes about MIT courses but don't accept "enrolled in" attributes
that refer to classes at other universities."
  This might seem contrived but imagine an AA that is a clearinghouse
for information from a number of sources.  The relying party's policy
might enumerate for which sources the AA is considered to be
authoritative and under what conditions.
  A real-life example of this is American Express Travel as a
clearinghouse of information from airlines.   I've learned from hard
experience that *my* policy as a relying party in bad weather, is to get
AMEX to call the airline directly instead of using the information that
is apparently available "on screen".

How Does this Relate to SAML's Model/

  In my opinion, it is important to keep separate the notions of
policy about attribute assertions,  and policy for authZ decisions.
(I tend to think that policy about authN assertions might be lumped in
with that for attribute assertions but logically it is separate too.)
  I think this separation is not just conceptual but will have
reflection in the formats we decide on for the authZ decision question.
Why?  Well, usually policy about attribute and authN assertions relates
very much to the packing of the information.  There tends to be lots of
policy about authenticating the asserting party.  In the case of digital
signatures, there are all the usual policy questions about revokation
(e.g. do you check for revokation each time or rely on cached
information).
   I don't think that the authZ decision question should drag along
the packaging from the attribute assertions.  (Or at least, this
should be only an option).   I tend to prefer unpackaged attributes
because that let's me as a resource manager use attributes
from various sources that have different packaging in my
authZ decision question.


That's it.  Two references to things I looked at are below.
I picked representative 'interesting ones' for inclusion here.
(If you search on "policy decision" you'll get a ton of
stuff back.  Many but not all of the computer-related ones
concern either validation decisions or authorization decisions.)

Let me know if this helps, and where we go from here.

Regards,
Marlena

PS I apologize for the lateness of this note.  A business trip
where I had little net access is partially to blame.

PPS  I can point to more formal examples of policy decision for
validation (e.g. XKMS) if needed.


1)  Addition of Device Class to Agent Options
http://search.ietf.org/internet-drafts/draft-ietf-dhc-agentoptions-device-class-01.txt


   The cable modem signals its device class information to the
   Relay Agent using DOCSIS signalling, and the Relay Agent forwards
   the device class information to the DHCP Server which can then make a
   policy decision based on it.
   ...
.  DHCP servers MAY use the Device Class for IP and other parameter
   assignment   policies for cable modems.

   [This one is interesting because the policy decision is neither
    validation nor authorization, but is yet computer-related.]


2) Therapeutic Products Program, Health Canada
http://www.hc-sc.gc.ca/hpb-dgps/therapeut/zfiles/english/y2k/y2k_validation_e.html
  [This one concerns a policy decison relation to validation of procedures,
  processes, and materials for producing drugs.]