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: REST API follow up

Follow ups from today’s call:


In earlier email I expressed concern about leaving version semantics up to the client, that different clients may implement conflicting client-side versioning semantics.  Given the policy containment model defined in the core XACML spec, I have not been able to come up with an example of two conflicting client-driven versioning schemes. So, I withdraw my concern about leaving versioning of policies up to the client.


I’m fine with saying the client is responsible for updating the policy version when POSTing a revision to the REST API.  The server’s only responsibility is to verify that the policy ID + version is unique within the set of policy revisions it owns. PUT modifies an existing policy in-place, POST creates a new revision of the policy uniquely identified by policy ID + version string.


For its intended purpose of representing CRUD operations, the REST API is sufficient.  There are many higher level questions about policy management left to discuss, but these all seem to be primarily organizational issues independent of the REST API’s simple CRUD interface.  When posting a revision to a policy via the REST API, does that immediately impact a PDP?  Does the repository contain all policies or only a selected subset of policies relevant to some use? These are outside the scope of the REST API itself.  We’re not defining the system or the server, we’re just defining a CRUD interface.


The only unresolved discussion point in my mind is the matter of whether policy references must be fully resolvable when a policy revision is POSTed to the server. I believe the current proposal states that all policy references must be resolvable and validated or the server must reject the post.  I understand the Admin profile requires “late bound” policy references which may only be resolvable in the context of a particular auth request.


From a relational integrity standpoint, it seems worrisome to accept policies without validating their outbound references. However if the Admin profile actually requires storing policies which contain references that cannot be resolved out of context, we may not have much choice here. 




Is there a way that the client can indicate when POSTing an update that this policy is an Admin policy and reference validation should be relaxed?  This would allow us to maintain relational integrity checks for “normal” policies and suppress them for Admin policies.




Danny Thorpe

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


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