Re: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded

[David Brossard <david.brossard@axiomatics.com>]

Additional comments inline

On Wed, Apr 25, 2012 at 8:15 AM, <remon.sinnema@emc.com> wrote:

Jean-Paul,

Thanks for your feedback.

> -----Original Message-----
> From: Jean-Paul Buu-Sao [mailto:jean-paul.buu-sao@tscp.org]
> Sent: Tuesday, April 24, 2012 9:00 PM
> To: Sinnema, Remon
> Cc: xacml@lists.oasis-open.org

> Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0,
> working draft 02 uploaded
>

> a) Lose coupling between PAP and PDP: Policy Administration Point can
> manage policies on Policy Decision Points from different vendor,
> without knowledge of any vendor-specific PAP-to-PDP API. Allowing a
> broader range of PAP offering

This is a very interesting idea. How do you see the REST profile enabling this use case?

[djob] If you go back to the XACML architecture, you will notice there is no direct link between PAP and PDP. There is already a very loose coupling between the PAP and PDP therefore. The REST profile neither promotes nor hinders this coupling. Keep in mind that the PAP should produce and manage XACML policies that are stored in the PRP and the PDP should load the policies from the PRP (notice the lack of direct link between PAP and PDP).

> B) Representation, mapping
> I think that a REST profile cannot avoid discussing representation
> format(s). I expected a section 2.2.1 that calls out the profile
> specifies (e.g. XML and JSON), before the considerations on constraints
> of those representations. Would you think useful to include the
> possibility of other structured representations as well, as I don't
> think that neither the style or constraints would be violated?

The XML format is defined by the core spec. The JSON format can either be defined in a separate profile, or in the Media Types profile. Either way, both formats have to be registered, and that is what the Media Types profile is for. (Although it seems much more common for a specification to both define a format and provide registration details for IANA. We decided against that for the XML format because we didn't want to update the core spec.)

Other representations than XML and JSON are certainly imaginable. We've already seen the OpenAz shorthand format and Massimiliano's formalized grammar. A Protocol Buffers-like binary format to minimize bandwidth might also make sense.

I don't think it's a good idea to include format definitions in the REST profile. The REST profile is about interactions with the PDP and PAP. The nature of those interactions doesn't depend on the representation. We shouldn't have to update the REST profile when a new format is devised, but rather when new interactions are defined (like Paul's suggestion to include the PIP).

 [djob]My hope was to define a format representation for the request and response elements at least within the JSON over HTTP profile which can be referenced here. There is little benefit to having the entire XACML policies defined in JSON. There is however a benefit in using a simple JSON syntax for XACML requests and in particular having shorthands for the long category and attribute URIs.

> In my opinion, sections 2.3.1 to 2.3.4 contain the essence of the profile.

Agreed.


> Is it possible to postpone the discussion of the constraints
> related to representations (i.e. "For a JSON representation, it is
> RECOMMENDED to use [JEP] but with added link relation types" in 2.3.3),
> that throw in some "noise". How about a specific section on these
> constraints afterwards, making sections 2.3.1 to 2.3.4 representation
> agnostic?

Yes, that would be better.

Ideally, the REST profile shouldn't have to talk about representations at all, but just refer to other specifications that do. However, the core spec, that defines the XML format, doesn't include enough information to make the REST profile work. For instance, there is no concept of a list of policies. (Well, there is the PolicyIdentifierList in 3.0, but it doesn't contain links to the individual policies, and it's not available for earlier versions.)


Thanks,
Ray


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

--
David Brossard, M.Eng, SCEA, CSTP
VP Product Marketing & Customer Relations
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics