OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded


Corpus/Corpora is another option with similar heritage. 


b


On Dec 15, 2014, at 7:55 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I am open to suggestions. The obvious term is policy set, but that is too easily confused with <PolicySet> which it may or may not correspond to.

 

Cohort is a perfectly good English language word and is in widespread use in the social sciences to express a similar concept. (individuals of similar age as they move through time, e.g. Baby Boomers, Millennials) I actually LIKE the fact that it has no other common meaning in security or computer science. In an industry which frequently invents new terms for things which already have a perfectly good one (e.g. Claims – Attributes), I am happy to introduce a new term for a relatively new concept with no current name.

 

Would you prefer we invent a totally new word like “Gorp”? That doesn’t seem very user friendly to me. I don’t see how one can use XACML or ABAC in general without learning a couple of new things. Apparently you consider PDP and PEP descriptive. Along the same lines, how about PIFAST? (Policies In Force At the Same Time).

 

The name Cohort does not matter to me. The important thing is that in general, a group of policies intended to be used at the same time must be tested, analyzed and deployed as a unit. One cannot, for example update the currently active Cohort by changing and testing one policy. One must test the policy in combination with the rest of the Cohort and conceptually update the entire Cohort. Of course for efficiency we don’t need to transmit anything that has not changed, but that is merely an optional optimization.

 

The primary requirement coming from the field is to have the ability to distribute policies from a repository to PDPs which are independent implementations. I think we should also support features such as pre-staging. (These policies go in effect at midnight. The PDP receives them at 8 PM and holds them until midnight. It then begins using them for new decision requests, while still using the old Cohort for requests in progress.)

 

My suspicion (assumption?) is that one result of the PAP architecture exercise of will be that we leave the whole – editing, testing, analysis, version control part of the architecture a black box.

 

WRT to your idea of Cohort metadata, that sounds perfectly reasonable to me. Policies have comments and extension points where you can add metadata which is not defined by XACML. I don’t see why similar things can’t appear in a Cohort.

 

Hal

 

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Friday, December 12, 2014 3: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

 

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Thursday, December 11, 2014 10:33 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Groups - Discussion: Proposed PAP Architecture uploaded

 

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]