|Hal Lockhart||May 16, 2012 3:28 pm|
|remo...@emc.com||May 16, 2012 11:43 pm|
|Hal Lockhart||May 17, 2012 8:00 am|
|Danny Thorpe||May 17, 2012 11:34 am|
|Danny Thorpe||May 17, 2012 12:44 pm|
|remo...@emc.com||May 17, 2012 2:29 pm|
|Hal Lockhart||May 29, 2012 12:48 pm|
|Hal Lockhart||May 29, 2012 12:53 pm|
|Hal Lockhart||May 29, 2012 12:58 pm|
|Danny Thorpe||May 29, 2012 3:20 pm|
|Hal Lockhart||May 31, 2012 7:50 am|
|David Brossard||May 31, 2012 7:53 am|
|remo...@emc.com||May 31, 2012 3:14 pm|
|remo...@emc.com||May 31, 2012 3:48 pm|
|Craig R Forster||May 31, 2012 4:10 pm||.gif, .gif|
|prateek mishra||Jun 1, 2012 7:13 am|
|Anil Saldhana||Jun 1, 2012 8:24 am|
|Craig R Forster||Jun 1, 2012 8:27 am||.gif, .gif|
|Hal Lockhart||Jun 7, 2012 8:26 am|
|Subject:||Re: [xacml] REST Profile - PAP Issues|
|From:||David Brossard (davi...@axiomatics.com)|
|Date:||May 31, 2012 7:53:49 am|
I agree with your last point, Hal. Representing the request / response alone in JSON will be much easier.
As a matter of fact, I realized the spec probably lacks a class diagram of the request / response much like there is one for policies. The class diagram can help formally drive the JSON definition, and ultimately why not an IDL for Thrift?
On Thu, May 31, 2012 at 4:51 PM, Hal Lockhart <hal....@oracle.com>wrote:
Accessing policies via REST is pretty straightforward. The tricky part is the semantics behind POST for policy revision. If we can't find an abstraction that we can be confident will be compatible with an as yet undefined policy management policy/semantic, perhaps the best step for moving the REST profile along is to remove policy POST from the REST spec for the moment?
I think XACML has benefitted from having a relatively clear model of the relationship between the PEP and the PDP. In particular it has guided decisions about what aspects to standardize and what to leave unspecified.
Currently the PAP concept is pretty vague. I think we need to break it up into subcomponents and define their relationships. This will give us the ability to decide what aspects should be standardized, what properties the components are required to implement and where the opportunities for unstandardized value add are.
I therefore agree with Danny that we should split off the policy management aspects into a different profile and drive the REST-based decision request to completion. I am uncertain whether this should wait on the JSON representation or that should be put off to a later version. An additional possible advantage of this approach is that it may be prove much simpler to specify the Request in JSON than the policy language.