RE: A note about PDPs

["Platt, Darren" <dplatt@securant.com>]

I agree with a lot of what Marlena says here, particularly:

>   In my opinion, it is important to keep separate the notions of
> policy about attribute assertions,  and policy for authZ decisions.

and

>    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 also think that Marlena's definition of PDP is better than what we have
today.

Regards,

Darren


> -----Original Message-----
> From: Marlena Erdos [mailto:marlena@us.ibm.com]
> Sent: Wednesday, April 11, 2001 12:40 PM
> To: oasis sstc core
> Subject: A note about PDPs
> 
> 
> 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-agentopt
ions-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.]


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-core-request@lists.oasis-open.org