Can we just move the policy management (with versioning) out into a
separate profile of its own? This will only delay execution of the
REST bindings for request/response. The policy management
versioning topic is wsdl/webservices all over again, which the world
is trying to run away from (via json). :)
On 06/01/2012 09:14 AM, prateek mishra wrote:
Craig,
As I understand it, the task of creating a REST/JSON binding for
XACML request/response is a well understood task which could be
accomplished in a short period of time.
It is also something the we have received a fair bit of interest
from the community, customers and from within our organization. It
could perhaps even be the basis of
a public demonstration in the next six to nine months.
The policy management work is an altogether different animal. I am
no expert in this area, but I understand that a fair bit of
research is required in this space.
There is no reason to believe that consensus could be achieved in
a short period of time. I am also not personally aware of the same
level of interest in this work from
the larger community.
Just my two cents,
- prateek
>> we should split off the policy management
aspects into a different profile and drive the REST-based
decision request to completion.
Without the policy administration, there's nothing left that
is "REST". All we have is a HTTP POST binding for XACML
requests and responses, with perhaps a JSON representation.
Calling this a "REST profile" wouldn't be accurate.
Regards,
Craig
-------
craig forster | technical lead, tivoli security policy manager
cforster@us.ibm.com
-------
Hal Lockhart ---05/31/2012 09:55:49
AM---> Accessing policies via REST is pretty
straightforward. The tricky part > is the semantics
behind
> 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.
Hal
|