Craig, From:
xacml@lists.oasis-open.org [ mailto:
xacml@lists.oasis-open.org ] On Behalf Of Craig R Forster Sent: Friday, June 01, 2012 1:19 AM To:
xacml@lists.oasis-open.org Subject: [xacml] REST API -- finding a policy based on it's PolicyId > In my view, a common use of the REST profile will be for the PDP to fetch policies from a PAP / policy repository. Danny has mentioned this as well. I countered that that seems to be a very inefficient way to go about it, and that it's more likely that the PAP would write policies to some sort of Policy Repository and that the PDP would query that repository. The representation of policies in the repository is likely optimized for querying by the PDP. But if people think this is a good use of the REST API, then I'll add it as a use case to the profile. > A key part of this process will be finding the URI of a policy based on it's PolicyId/PolicySetId, as we've already > determined that these two are separate (that is, one can't derive the URI from the PolicyId). > > Do we need to standardize a way to do this, something that's more efficient than "list all policies, examine the > returned Atom document and find the one you want"? We could even limit it to the semantics of "get me the latest > version of the policy with this identifier"... That's a very good idea. Unfortunately, neither RFC 4287 nor 5023 define filtering/querying of Atom feeds. So we can either cook up our own scheme, or use something like OData:
http://www.odata.org/media/30002/OData.html#thefiltersystemqueryoption > Perhaps something like: > GET /authorization/policies?identifier=<policy id>&version=current Yes, that would be our own scheme. I think this works best for the current use case, since it's such a simple one. However, I do foresee that we'll want to do more sophisticated filtering in the future. For instance, list all policies that target a given subject (to support Reverse Query-like operations). > I imagine getting the latest version of a policy will be something that policy authoring components will want to do > as well. However, neither of these scenarios may be possible as we've pushed the semantics of a version to the client > (ie the server can't work out what 'current' means). There is nothing in a policy that indicates that it is the "current" version. So the only thing we can use, is the version relative to other versions of the same policy. This means we need to compare version numbers, which is currently unspecified by the core spec, as Danny recently pointed out. Thanks, Ray