atom feed13 messages in org.oasis-open.lists.xacmlRE: [xacml] REST Profile wd04
FromSent OnAttachments
Danny ThorpeMay 22, 2012 12:24 pm 
Craig R ForsterMay 22, 2012 12:31 pm.gif, .gif
Danny ThorpeMay 22, 2012 2:17 pm.gif, .png, .png
remo...@emc.comMay 23, 2012 1:17 am 
David BrossardMay 23, 2012 1:37 am 
remo...@emc.comMay 23, 2012 1:47 am 
Craig R ForsterMay 23, 2012 7:20 am.gif, .gif
Danny ThorpeMay 23, 2012 10:20 am 
Danny ThorpeMay 23, 2012 10:27 am 
remo...@emc.comMay 23, 2012 1:06 pm 
remo...@emc.comMay 23, 2012 1:19 pm 
remo...@emc.comMay 23, 2012 1:23 pm 
Danny ThorpeMay 23, 2012 2:34 pm 
Subject:RE: [xacml] REST Profile wd04
From:Craig R Forster (cfor@us.ibm.com)
Date:May 23, 2012 7:20:33 am
List:org.oasis-open.lists.xacml
Attachments:

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 cfor@us.ibm.com

-------

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

Craig,

From: Craig R Forster [mailto:cfor@us.ibm.com] Sent: Tuesday, May 22, 2012 9:32 PM To: Danny Thorpe Cc: Sinnema, Remon; xac@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