[plasma] Fwd: The PoLicy Augmented S/Mime \(plasma\) bof discussion list

[Patrick Patterson <[e-mail]>]

From Trevor:

Begin forwarded message:

> From: Trevor Freeman <[e-mail]>
> Date: July 27, 2012 6:58:56 PM EDT
> To: "Patrick Patterson [[e-mail]]" <[e-mail]>
> 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: [phone]
mobile: [phone]
fax: [phone]