13 messages in org.oasis-open.lists.xacml[xacml] RE: REST Profile wd04| From | Sent On | Attachments |
|---|---|---|
| Danny Thorpe | May 22, 2012 12:24 pm | |
| Craig R Forster | May 22, 2012 12:31 pm |  .gif, .gif |
| Danny Thorpe | May 22, 2012 2:17 pm | .gif, .png, .png |
| remo...@emc.com | May 23, 2012 1:17 am | |
| David Brossard | May 23, 2012 1:37 am | |
| remo...@emc.com | May 23, 2012 1:47 am | |
| Craig R Forster | May 23, 2012 7:20 am | .gif, .gif |
| Danny Thorpe | May 23, 2012 10:20 am | |
| Danny Thorpe | May 23, 2012 10:27 am | |
| remo...@emc.com | May 23, 2012 1:06 pm | |
| remo...@emc.com | May 23, 2012 1:19 pm | |
| remo...@emc.com | May 23, 2012 1:23 pm | |
| Danny Thorpe | May 23, 2012 2:34 pm |
| Subject: | [xacml] RE: REST Profile wd04 | |
|---|---|---|
| From: | remo...@emc.com (remo...@emc.com) | |
| Date: | May 23, 2012 1:17:41 am | |
| List: | org.oasis-open.lists.xacml | |
Danny,
From: Danny Thorpe [mailto:Dann...@quest.com] Sent: Tuesday, May 22, 2012 9:25 PM To: Sinnema, Remon Cc: xac...@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