OASIS ACAL [XACML] TC

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? > 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

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

Feedback on the REST profile draft:   Section 2.3 Resources “Each section defines with operations are supported… ”    typo.  with => which     It would be helpful if there were non-normative examples urls for illustration. I realize that since the REST responses are supposed to be self-documenting for discovery, specifying the URL patterns should not be part of the normative text.  Including examples in the normative sections 2.3.* might be confusing to keep normative separate from nonnormative, but perhaps a new examples section that follows the normative 2.3.* text?   For example, what is the REST entry point referred to in 2.3.1?  For a PDP at http://pdp.example.com/v1/ , is the REST entry point described in 2.3.1 http:/pdp.example.com/, which will list the v1 url as one of the interfaces provided by that server and only that server?  Or is the REST entry point an entirely separate service entity ( http://discover.example.com ) which lists available PDP (and other) interfaces on all servers?     Section 2.3.1 REST Entry Point uses HTTP GET to obtain information about what services / interfaces are available.  Isn’t that the job of the HTTP OPTIONS method?     Should section 2.3.1 mention anything about best-practices such as filtering results to only return links to services that the client credentials are authorized to use?  If an organization has multiple PDPs running, and some of them are domain specific and only accessible to certain clients, it could be considered a breach of disclosure if the REST Entry Point returned all the PDP services links, including links to services that the client can’t access.     Section 2.3.3 Policy Administration Point GET returns a list of available XACML policies.  It would be helpful to mention the use of “next”, “prev” link relations to manage pagination of large result sets.    http://www.iana.org/assignments/link-relations/link-relations.xml     Thanks, -Danny     Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com  

Danny, Thanks for your feedback. From: Danny Thorpe [ mailto:Danny.Thorpe@quest.com ] Sent: Thursday, May 03, 2012 7:18 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 > Section 2.3 Resources > "Each section defines with operations are supported. "    typo.  with => which Thanks for catching this. >> It would be helpful if there were non-normative examples urls for illustration. I realize that since the REST responses are supposed to be self-documenting for discovery, specifying the URL patterns should not be part of the normative text.  Including examples in the normative sections 2.3.* might be confusing to keep normative separate from nonnormative, but perhaps a new examples section that follows the normative 2.3.* text? << Yes, good idea. I'll add an Examples section with a couple of use cases. >> For example, what is the REST entry point referred to in 2.3.1?  For a PDP at http://pdp.example.com/v1/ , is the REST entry point described in 2.3.1 http:/pdp.example.com/, which will list the v1 url as one of the interfaces provided by that server and only that server?  Or is the REST entry point an entirely separate service entity ( http://discover.example.com ) which lists available PDP (and other) interfaces on all servers? << I'm not sure I understand the implications of having multiple servers. Do you envision those servers to be identical, or could each have their own capabilities? > Section 2.3.1 REST Entry Point uses HTTP GET to obtain information about what services / interfaces are available.  Isn't that the job of the HTTP OPTIONS method? The response to an OPTIONS call lists which HTTP verbs are allowed on the REST resource (using the Allow header). What I'm talking about here is which REST resources are available on the server. I don't think you can do that in a standard way with OPTIONS. Also, OPTIONS is not cacheable, while GET is. And since this information is not likely to change much, we should take advantage of caching. > Should section 2.3.1 mention anything about best-practices such as filtering results to only return links to services that the client credentials are authorized to use? Yes, definitely. >> If an organization has multiple PDPs running, and some of them are domain specific and only accessible to certain clients, it could be considered a breach of disclosure if the REST Entry Point returned all the PDP services links, including links to services that the client can't access. << I guess the current draft assumes a single server or farm of identical servers. I haven't really thought about multiple servers with different capabilities. > Section 2.3.3 Policy Administration Point > GET returns a list of available XACML policies.  It would be helpful to mention the use of "next", "prev" link relations to manage pagination of large result > sets.    http://www.iana.org/assignments/link-relations/link-relations.xml Will do. Thanks, Ray

inline -----Original Message----- From: remon.sinnema@emc.com [ mailto:remon.sinnema@emc.com ] Sent: Thursday, May 03, 2012 12:32 PM To: Danny Thorpe Cc: xacml@lists.oasis-open.org Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded [...] >> For example, what is the REST entry point referred to in 2.3.1?  For >> a PDP at http://pdp.example.com/v1/ , is the REST entry point >> described in 2.3.1 http:/pdp.example.com/, which will list the v1 url >> as one of the interfaces provided by that server and only that >> server?  Or is the REST entry point an entirely separate service >> entity ( http://discover.example.com ) which lists available PDP (and >> other) interfaces on all servers? << I'm not sure I understand the implications of having multiple servers. Do you envision those servers to be identical, or could each have their own capabilities? [DT] Different PDP servers running different policy sets. Could be separated by administrative or organizational domains (divisions within a company) or by operational or geographic domains (export regulations in the Singapore office vs card access to the San Francisco office building. Completely unrelated domains, why should they be on the same PDP?). Another multi-PDP case is phased deployment: one server in production, one for staging and testing new policy revisions. The two PDPs could be on the same network and visible to clients, but the test PDP should be locked down to only accept requests from authorized testers. > Section 2.3.1 REST Entry Point uses HTTP GET to obtain information about what services / interfaces are available.  Isn't that the job of the HTTP OPTIONS method? The response to an OPTIONS call lists which HTTP verbs are allowed on the REST resource (using the Allow header). What I'm talking about here is which REST resources are available on the server. I don't think you can do that in a standard way with OPTIONS. Also, OPTIONS is not cacheable, while GET is. And since this information is not likely to change much, we should take advantage of caching. [DT] Ok, good points. :> > Should section 2.3.1 mention anything about best-practices such as filtering results to only return links to services that the client credentials are authorized to use? Yes, definitely. >> If an organization has multiple PDPs running, and some of them are >> domain specific and only accessible to certain clients, it could be >> considered a breach of disclosure if the REST Entry Point returned >> all the PDP services links, including links to services that the >> client can't access. << I guess the current draft assumes a single server or farm of identical servers. I haven't really thought about multiple servers with different capabilities. [DT] It would probably be best to limit the scope of the REST Entry Point to the server receiving the request. For replicated identical servers behind a load balancer, each individual server speaks for the collective - the returned links would not be bound to that specific server machine. Discovery of services across multiple different servers is probably out of scope for this discussion. Thanks! -Danny

Danny, > -----Original Message----- > From: Danny Thorpe [ mailto:Danny.Thorpe@quest.com ] > Sent: Friday, May 04, 2012 12:40 AM > 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 > > [DT] It would probably be best to limit the scope of the REST Entry > Point to the server receiving the request. For replicated identical > servers behind a load balancer, each individual server speaks for the > collective - the returned links would not be bound to that specific > server machine. > > Discovery of services across multiple different servers is probably out > of scope for this discussion. Yes, let's keep things as simple as possible. Thanks, Ray