atom feed19 messages in org.oasis-open.lists.xacmlRe: [xacml] REST Profile - PAP Issues
FromSent OnAttachments
Hal LockhartMay 16, 2012 3:28 pm 
remo...@emc.comMay 16, 2012 11:43 pm 
Hal LockhartMay 17, 2012 8:00 am 
Danny ThorpeMay 17, 2012 11:34 am 
Danny ThorpeMay 17, 2012 12:44 pm 
remo...@emc.comMay 17, 2012 2:29 pm 
Hal LockhartMay 29, 2012 12:48 pm 
Hal LockhartMay 29, 2012 12:53 pm 
Hal LockhartMay 29, 2012 12:58 pm 
Danny ThorpeMay 29, 2012 3:20 pm 
Hal LockhartMay 31, 2012 7:50 am 
David BrossardMay 31, 2012 7:53 am 
remo...@emc.comMay 31, 2012 3:14 pm 
remo...@emc.comMay 31, 2012 3:48 pm 
Craig R ForsterMay 31, 2012 4:10 pm.gif, .gif
prateek mishraJun 1, 2012 7:13 am 
Anil SaldhanaJun 1, 2012 8:24 am 
Craig R ForsterJun 1, 2012 8:27 am.gif, .gif
Hal LockhartJun 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
List:org.oasis-open.lists.xacml

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.