Prateek,

I didn't mean to suggest that the runtime and administration pieces couldn't be tackled separately, just that calling an XACML over HTTP POST (using XML or JSON) a "REST" protocol is a misnomer (IMO). I completely agree that a runtime profile could be knocked out fairly quickly.

However, how does this differ from previous suggestions that we standardize an XACML over SOAP protocol? This wasn't something the TC was keen to pursue (ie the SAML binding is the official runtime protocol), so how is XACML over HTTP POST different? If we're going to standardize runtime bindings then both SOAP and HTTP POST are valid candidates.

Regards, Craig

------- craig forster | technical lead, tivoli security policy manager cfor...@us.ibm.com

-------

|------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |prateek mishra <prat...@oracle.com>
| >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |xac...@lists.oasis-open.org, Craig R Forster/Austin/IBM@IBMUS,
| >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |06/01/2012 09:15 AM
| >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [xacml] REST Profile - PAP Issues
| >--------------------------------------------------------------------------------------------------------------------------------------------------|

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 cfor...@us.ibm.com -------

Inactive hide details for Hal Lockhart ---05/31/2012 09:55:49 AM---> Accessing policies via REST is pretty straightforward. ThHal Lockhart ---05/31/2012 09:55:49 AM---> Accessing policies via REST is pretty straightforward. The tricky part > is the semantics behind

From: Hal Lockhart <hal....@oracle.com>

To: Danny Thorpe <Dann...@quest.com>, remo...@emc.com,

Cc: xac...@lists.oasis-open.org

Date: 05/31/2012 09:55 AM

Subject: RE: [xacml] REST Profile - PAP Issues

Sent by: <xac...@lists.oasis-open.org>

> 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

--------------------------------------------------------------------- To unsubscribe, e-mail: xacm...@lists.oasis-open.org For additional commands, e-mail: xacm...@lists.oasis-open.org