9 messages in org.oasis-open.lists.xacmlRE: [xacml] Groups - REST Profile of ...| From | Sent On | Attachments |
|---|---|---|
| Remon Sinnema | Apr 24, 2012 4:01 am | |
| David Brossard | Apr 24, 2012 6:32 am | |
| remo...@emc.com | Apr 24, 2012 8:24 am | |
| remo...@emc.com | Apr 24, 2012 11:14 pm | |
| David Brossard | Apr 25, 2012 4:21 am | |
| Danny Thorpe | May 3, 2012 10:17 am | |
| remo...@emc.com | May 3, 2012 12:31 pm | |
| Danny Thorpe | May 3, 2012 3:38 pm | |
| remo...@emc.com | May 3, 2012 11:27 pm |
| Subject: | RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded | |
|---|---|---|
| From: | remo...@emc.com (remo...@emc.com) | |
| Date: | Apr 24, 2012 11:14:32 pm | |
| List: | org.oasis-open.lists.xacml | |
Jean-Paul,
Thanks for your feedback.
-----Original Message----- From: Jean-Paul Buu-Sao [mailto:jean...@tscp.org] Sent: Tuesday, April 24, 2012 9:00 PM To: Sinnema, Remon Cc: xac...@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?
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).
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