OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]