RE: 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. 

I don't think a lot of systems will be implemented this way; most PAPs will write policies to some sort of Policy Repository, which the PDP then queries. Also, there is the whole policy distribution idea that Hal proposed. So I'm leaning against this idea, unless others agree with you.
<<<<<<<<<

FWIW, I'm planning to implement a REST API on my policy repository server.  Thus my question about PDP fetching policies via a REST API. 


>>>>>>>>>> 
> 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?

My goal with the REST profile is simply to make existing PAP (and PDP) functionality available through a REST interface. I'd prefer it if we didn't introduce new functionality. IMO, if we are to define versioning of policies, then that should be done in the core spec (or a dedicated Versioning profile), not in the REST profile.

I think that the policy supplied in the body must validate against the XACML policy schema (or else 400 Bad Request). This means that the Version attribute must be supplied by the client, and the version is opaque to the REST server. The server need only be able to tell whether versions are identical.

If people agree with this position, then I'll document it in the profile.

The core spec should define how versions are to be compared. Since it currently doesn't, as you mentioned earlier, I'm okay with temporarily adding some text about it in the REST profile, so that we can enable interoperability between different implementations of the profile.
<<<<<<<<<<<<

I understand and agree with not wanting to introduce new core functionality in the REST API.  

My concern is that if versions are a mandatory part of the XACML spec and every vendor must implement some sort of versioning semantics, how do we abstract the REST API so that a client can work with any conforming implementation but not know anything about how versioning is handled?

From your reply to Craig on this topic, you suggest that the server be versioning agnostic and that the client dictate the versioning semantics.  Hmm.  I'll have to mull that one for a bit.  I'll follow up on that thread.

>>>>>>>>>>>>
> 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.

That doesn't seem to fit the definition of "enclosure":
http://tools.ietf.org/html/rfc5988#page-13

How about "up"?
http://tools.ietf.org/html/rfc5988#page-16

[...]

> 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 way link relations work, is that the spec must define what operations a server accepts for the link relation and what they mean. The client must understand these semantics.
<<<<<<<<<

So, we could define our own linkrel "root" to indicate the root of the policy tree instead of trying to repurpose one of the well-known linkrels?

-Danny