RE: [xacml] REST Profile wd04

[Craig R Forster <cforster@us.ibm.com>]

That's a fair explanation Ray, and I agree with your conclusions.

To me, it seems like this API is not exposing PAP functionality but Policy Repository functionality -- in my mind, the authoring/administration component would be the one pushing policies via this API and the PDP would be the one reading them for runtime evaluation. If the client is controlling the version too, then the server in this profile is even more like a pure policy repository.

From your other note:

>> most PAPs will write policies to some sort of Policy Repository, which the PDP then queries

I completely agree, and the "PAP" API defined in the REST profile would be the perfect protocol for both sides of this flow.

Regards,
Craig

-------
craig forster | technical lead, tivoli security policy manager
cforster@us.ibm.com
-------

---05/23/2012 03:49:05 AM---Craig, From: Craig R Forster [mailto:cforster@us.ibm.com]

From:	<remon.sinnema@emc.com>
To:	Craig R Forster/Austin/IBM@IBMUS,
Cc:	<xacml@lists.oasis-open.org>
Date:	05/23/2012 03:49 AM
Subject:	RE: [xacml] REST Profile wd04
Sent by:	<xacml@lists.oasis-open.org>

---

Craig,


From: Craig R Forster [mailto:cforster@us.ibm.com] 
Sent: Tuesday, May 22, 2012 9:32 PM
To: Danny Thorpe
Cc: Sinnema, Remon; xacml@lists.oasis-open.org
Subject: Re: [xacml] REST Profile wd04

> Shouldn't the server control the version?

I don't see how a server could know whether an update indicates a minor or major change. So unless you have a very simplistic versioning scheme, where you just increment a single digit, the server can't implement it. The client, on the other hand, is in a much better position, since it most likely has knowledge of what events led to the creation of a new version of the policy. So it could, for example, implement semantic versioning [1].

So there are basically two approaches that we can take:
(1) let the client specify the version
(2) let the client indicate to the server what kind of change is made

Approach #2 is what you see in source code control systems like SVN, where there are different commands for incrementing the minor and major version (commit vs. branch).

I like #1 better, because
(1) it's simpler, which keeps the costs for implementation low
(2) it allows the client to chose any versioning scheme it wants, instead of having the server dictate one
(3) it allows the server to validate the given policy as-is against the policy schema

#2 is especially important for the Authorization-as-a-Service use case, where different tenants may want to use different versioning schemes, while using the same server (farm).


Thanks,
Ray


[1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf