Hi Scott,
To slightly misquote Arnold "I am back" Yes you are on the mark that a role represents a collection of policies and each policy is represented by a unique pointer. Different projects which are covered by different licenses would be represented by different policies. This model is trying to achieve two objectives 1. Make the end user choice a simple as possible even in complex environments so they can pull the trigger with a little fuss a possible and still get the right result 2. Not open up a can of PEP interoperability woopass that optional parameters would invoke. By presenting a two level hierarchy (each user has a set of roles and each role has a set of policies) you can in effect present a large number of combinations of parameters to the end user without their knowledge about the details of the combination or making the client more complex. It would be good feedback to have some estimate of the number of permutations a user would be allowed to assert. This model is trading client simplicity for server complexity. I hear what you saying about the number of instances of polices you need to create under this model most of whom would have very similar rules. However I do see that as a tractable problem for PAP implementations with many similarities to code reuse. You are saying there are a relatively small number of policy rule sets which you want to use across a large number of instances of policy. As a corporation, we have standard terms and conditions for contracts which we use across thousands of contracts which all result in access to different sets of corporate assets. You need a policy authoring tool which reflects that reality much like we want a developer to use shared libraries for common operations. Under this model a generic set of ITAR rules could exist as an abstract policy much like an abstract class in code, which could be reused across multiple instances of program policies. Trevor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Fitch, Scott C Sent: Saturday, August 06, 2011 3:07 PM To: '[email protected]'; '[email protected]' Subject: Re: [plasma] Advanced Policies Ok. I think it's coming together for me, including my other comments on PEP bootstrapping. To test my understanding, the Roles from the PDP could be thought of as "policy collections" and the Policies as a pointer to all the resource attributes that the PDP needs to make its access decision. Is that a correct (re)characterization? I definitely agree with Trevor about limiting the inputs that a user needs to make, particularly for email, which most users take a ready-fire-aim approach to. So the question that comes to mind is whether there are other uses of those attributes outside of plasma that may be helpful in having available directly in the message? Document retention/destruction and search are two that come to mind. Another conderation is the number of individual policies that this approach results in, particularly for organizations that have thousands of active licenses and agreements. This is really an architecture allocation question: what component(s) are responsible for managing and resolving the individual resource attributes. It needs to be done somewhere, and plasma is recommending the PDP. I'm content to have a better understanding (I hope) of the plasma approach for the moment. I know Trevor has thought this through a lot and will be quite happy to share his views when he get back. Please do correct me if my understanding is still off or if you disagree with the considerations above though. Scott ------ Sent from my BlackBerry ----- Original Message ----- From: Jim Schaad [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Saturday, August 06, 2011 05:27 PM To: Fitch, Scott C; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: EXTERNAL: RE: [plasma] Advanced Policies Having separate threads is frequently simpler so I have no objections to that. I really wish Trevor was not on vacation so he could respond. Instead I will attempt to channel him and try not to get things really wrong. Based on previous conversations that I have had with Trevor (including last week at the Plasma side bar), the assumption we are working on is that users are not the brightest of people and things should be made as simple as possible for them. One of the corollaries of this is that options should generally not be given to users for configuration purposes. This means that there is no expectation that a generic ITAR policy would ever exist for a company. Instead you would define a different policy for each of the ITAR export licenses/ projects. Thus if you work on aircraft as an engineer, you would choose a role for a specific plane and get a small list of policies. It might be that the end-user would not even see that it was ITAR export controlled, but rather just that it is internal, external for that specific project. The more options that make the end user select, the more likely that are to get things wrong has been a basic philosophy that Trevor has espoused during the design. Counter arguments would be interesting, but probably better after he gets back at the end of the month. Jim > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]]<mailto:[mailto:[email protected]]> On > Behalf Of Fitch, Scott C > Sent: Thursday, August 04, 2011 2:05 PM > To: [email protected]<mailto:[email protected]> > Subject: [plasma] Advanced Policies > > (Apologies for all the posts. Just trying to keep the threads separate > for > commenting.) > > It's important to acknowledge that many Advanced policies will > required information about the message beyond just the Policy > identifier. An example > from the export control world: An email may be governed by the ITAR policy, > however, access control decisions are made based ITAR and the specific > export license or agreement that applies to the message. Simply identifying > that the document is export controlled doesn't given the PDP enough > information to make a grant or deny decision. > > Stated differently, an access decision is based on attributes about > the requester, resource, environment, and action. The plasma scenarios > for Advanced Policies should include the ability to convey attributes > (labels) about the message (including, but not limited to the policy > identifier) and > attributes about the recipient. > > > > > > Scott Fitch > Cyber Architect > Lockheed Martin Enterprise Business Services > > > _______________________________________________ > plasma mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/plasma _______________________________________________ plasma mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/plasma
_______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
