>From Trevor: Begin forwarded message:
> From: Trevor Freeman <[email protected]> > Date: July 27, 2012 6:58:56 PM EDT > To: "Patrick Patterson [[email protected]]" <[email protected]> > Subject: RE: The PoLicy Augmented S/Mime \(plasma\) bof discussion list > > > Hi Hal. > > > > Thanks for the feedback. > > > > The editorial comments (P4 & P7) seem straight forward I have incorporated > those in the 02 draft I just published. In that draft, I also revised the > ABAC definition in line with your comments. We had a lot of feedback in > Paris on the terminology\vocabulary and I have tried to incorporate that in > the new draft. > > * We have changes the name of the Plasma client from a PEP to a > Decision Requestor. This is to more accurately reflect is does not enforce > decisions, and that Plasma supports many types of decision types, not just > access control. > > * We have changes the PDP to be a Policy Decision and Enforcement > Point to reflect that in the Plasma model both functions are in the single > logical entity (this does not require they be implemented as a single > physical entity) > > * We have changed policy set to policy collections to avoid confusion > with the XACML policy sets. In Plasma the policy collection is used by > clients as a means to manage what choices a client has for which polies can > be applied to a message. They don't play a part in the actual decision itself. > > * > > You have a number of technical questions which I believe are answers in the > following Plasma documents. > > > > http://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ > > > > http://datatracker.ietf.org/doc/draft-schaad-plasma-service/ > > > > > > I have added a new scenario for document integrity policy. Plasma is intended > as a general purpose policy enforcement mechanism, not just access control. I > have realized that while we talk about this point a number of places, the > language still assume just access policy so those changes are causing a > bigger ripple through the document as I try to realign the terminology. > > > > The current work is targeted as a means to make generic policy decision > requests so by design has no dependencies on any specific language as we want > to insulate the client from policy. We plan to tackle the distribution of > policy between the PDEP and PAP as a subsequent work which is where much of > the policy specific dependencies will be called out. I will clarify the needs > for standards in this area in the generic requirements doc. I understand a > lot of large customer have invested in XACML so I don't doubt XACML will be > part of the policy distribution draft. > > > > Thanks again for taking the time to review our work. > > Trevor > > > > In response to Requirements for Message Access Control > (http://tools.ietf.org/pdf/draft-freeman-plasma-requirements-01.pdf) the > OASIS XACML Technical Committee has agreed to submit the attached comments. > > > > The public link to this document is: > > > > https://www.oasis-open.org/committees/download.php/46049/Proposed%20response%20to%20Plasma%20v1-3.docx > > > > Hal Lockhart > > Bill Parducci > > Co-chairs OASIS XACML TC > --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 _______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
