Re: [xacml] RE: REST Profile wd04

On Wed, May 23, 2012 at 10:18 AM, <remon.sinnema@emc.com> wrote:

Danny,

From: Danny Thorpe [mailto:Danny.Thorpe@quest.com]
Sent: Tuesday, May 22, 2012 9:25 PM
To: Sinnema, Remon
Cc: xacml@lists.oasis-open.org
Subject: REST Profile wd04

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

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

> Suggestion: An observation somewhere that GET/POST/DELETE may not be symmetric for all policy resources.

That's a good idea. I'll add it to the document.

> 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

> The linked parent document should be the topmost parent or "root" policyset document (not an intermediate parent which is itself a child of the root policyset).

Yes. This needs to be spelled out in the document.

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

Thanks,
Ray

---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

xacml message