REST Profile wd04

[Danny Thorpe <Danny.Thorpe@quest.com>]

Section 1.5  - Can we add a use case for PDP <- PAP?   A PDP may use the REST API to fetch policies for evaluation.

 

----

 

Section 2.2.3.2 Policy or PolicySet

 

There’s no indication or guidance about how the version of the document being posted is computed or identified.  Is this a minor revision, or is this bumping the revision from 1.0.0.123 to 1.5?

 

Suggestion: The client MUST set the Policy/Set version field to the version string desired for the new document to be created by the POST.  If the unique key combination of policy ID + version string already exists in the repository, the response MUST fail with (409 Conflict).

 

-------

 

Suggestion: An observation somewhere that GET/POST/DELETE may not be symmetric for all policy resources.  Implementations may expose individual policies for reading via GET but not support direct editing of that policy because that policy is a child element contained in a parent policyset. The parent policyset document can be identified by a link with an “enclosure” link relation.  The linked parent document should be the topmost parent or “root” policyset document (not an intermediate parent which is itself a child of the root policyset).

 

Perhaps the phrasing should be turned the other way around:  Because XACML policy/set references allow referencing external policy/sets without regard to their containment, REST API implementations SHOULD make child policy/sets accessible via GET even if such resources are not editable independently of their parent documents. The parent policyset document can be identified in the child policy ATOM element by a link with an “enclosure” link relation.  The linked parent document should be the topmost parent or “root” policyset document (not an intermediate parent which is itself a child of the root policyset).

 

 

I’m not sure how to express in the linkrels that editing of the child policy must be done by POSTing the parent document.

 

The reason for noting this asymmetry in the REST API profile is to reduce the REST API exposure to the semantics of how version numbers change in revisions, particularly between different policies.  Asymmetric operations on child policies allow for implementations to manage version propagation internally when changes are made to a child policy. When making a change to a contained child policy, it’s usually the case that the parent / container also needs to have its version bumped, all the way up the parent chain to the root node, in order to preserve the semantics of the container prior to the child revision. This is not an issue for external policy/set references.

 

-Danny

 

Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com