> The REST API should allow for an implementation to express a staging or
> process workflow around policy creation, revision, testing, approval,
> deployment, and retirement, but I don't think that workflow definition
> should be part of the REST API. I would expect that such a workflow
> would use the REST API, not the other way around.
>
> One way to express such a workflow would be to set up a different
> independent PAP for each distinct stage in the workflow. Policy
> development and testing happens on PAP.Staging. PAP.Staging is only
> accessible to PDPs used for testing, not accessible to production PDPs.
> After the workflow for policy revision, testing, and approval has been
> completed, the policy/policyset/cohort are copied to PAP.Production,
> where they are accessible to the production PDPs. PAP.Production is
> very restricted in who can post changes to that repository -
> PAP.Staging less so. How and when the PDPs discover and begin to
> enforce the revised policies is also beyond the scope of the REST API.
>
> All of that can be done using the simple "PDP production oriented" REST
> API as sketched out. (subject to version management in the next email)
This sounds reasonable, but I would have to see the details to really judge.
It does seem like it would make sense to have a separate profile dealing with all the policy management issues.
Hal
