Hi Erik, The purpose of this discussion is not to limit products, but to make them more interoperable. The meta-data example you gave seems like data for the policy editor, so I would think it would be stored with the editor, not in a PRP, since it doesn’t have to be available for a PDP. Anyway, we can’t even have these kinds of discussions if we don’t agree that there is such a thing as a PRP. Currently, the core spec says: “the communications between the PDP and the PAP may be facilitated by a repository. The XACML specification is not intended to place restrictions on the location of any such repository, or indeed to prescribe a particular communication protocol for any of the data-flows.” I don’t want to prescribe a protocol, but I do think having an optional standard communication protocol between PDP/PAP and PRP may improve interoperability. Thanks, Ray From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen Sent: Friday, December 12, 2014 9:56 AM To: Hal Lockhart; xacml@lists.oasis-open.org Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded Hi Hal,
Sure, I did not mean to say that there should be no work. I just meant that I don't find this work very interesting, and it might be potentially limiting on products. But I could be persuaded otherwise. :-)
As of an example of metadata, let's say that you have a policy editor which allows you to browse a "cohort" and edit it. The last edit position and how the cohort was expanded in view to the user at last edit time is something that the editor might want to save in the cohort for the user's convenience. It would be a pity if a standard file format for a cohort would prevent a vendor to do something like this or other user enhancements.
BTW, I don't like the term "cohort". It is not descriptive to end users, and even if we would think of it as a technical term, these technical terms tend to trickle up to the user level one way or another in the end. I would prefer something more user friendly.
Best regards, Erik
On 2014-12-11 18:18, Hal Lockhart wrote: The currently agreed ABAC architecture (PDP, PEP, PIP, PAP) is deployed in many different environments and explicitly permits proprietary extensions in various places. I don’t accept that we cannot find further architectural elements which we can agree on which will be beneficial to organizations deploying XACML. I could be persuaded after discussion, but I don’t see limiting ourselves a priory. I don’t understand the relevance of your point about metadata. If metadata is embedded in policy syntax, it should use existing extension points or special comment formats like Java does. Other PDPs should be able to evaluate policies without any of the enhancements. Otherwise XACML does not provide interoperability. Perhaps a better way to make progress is try to agree on a set of requirements which are basic to the standard and identify areas for proprietary extension. Hal All,
There are lots of different possible architectures and workflows for policy distribution and management. I am a bit afraid that standardizing these aspects is going to be too rigid and slow down the evolution of XACML products. For instance a policy editor component may want to put all kinds of metadata into the storage or distribution formats to facilitate a good user experience. And depending on needs, distribution and deployment could be done in vastly different ways by different organizations.
Best regards, Erik
On 2014-12-09 10:21, Remon Sinnema wrote: Submitter's message All,
I'd like to re-start the discussion about PAPs, cohorts, and policies. This document may help with that.
Thanks, Ray -- Mr. Remon Sinnema Document Name: Discussion: Proposed PAP Architecture Description This note briefly discusses a proposed architecture for policy administration. It is intended to stimulate discussion, which may or may not end up being formalized in a profile. Download Latest Revision Public Download Link Submitter: Mr. Remon Sinnema Group: OASIS eXtensible Access Control Markup Language (XACML) TC Folder: repository Date submitted: 2014-12-09 01:20:56 |
|