David this is exactly what you promised not to do but you did it anyway!!! Your disrupting a delicate process where I was trying to bring in the community to discuss these matters.
We were going to take an approach in small steps: (1) discuss the problems to be solved with clear language (2) discuss various research papers on the topic to understand existing approaches (3) decide on a design which incorporates these and other ideas It was this community which pointed out these papers to you in the first place. We implement standards here. We're not saying don't use them or we would not say hey here read these materials. The point is we need first to discuss the problems we want to solve to understand what kind of product we are to deliver. If you think these descriptions are incorrect then point out why so we can understand you. Don't just hide behind words like the "standard". Again we implement standards and know their value more than most people. Don't just say "no this route is wrong just use NIST material." These discussions are not in opposition to the NIST paper. But if they are please state why. How many people do you think we will be able to engage when we start talking about the set definitions for symmetric RBAC from the start of a conversation? Let's factor in these papers to be considered after we define what it is we're trying to do. We want them to be considered of course or we would not have pointed them out. However you cannot design a solid product that solves the problems of the enterprise in a vacuum by just reading academic papers. There needs to be some balance. More inline ... On 10/24/07, David Jencks <[EMAIL PROTECTED]> wrote: > > I have some problems with these definitions that I have not had time > to write up comprehensibly but I would appreciate more discussion > before we put them on the web site. Yes I did not want to rush to put them on the website. Emmanuel may have skipped a step. Guys let's discuss if these descriptions are correct and if not why not. Also these are not definitions for the sake of a standard. They're simply definitions for clear every day language while discussing the problem to be solved. Then we'll move on and get really academic about it as we delve deeper. I'd like to counter-propose that we use the definitions from the NIST > paper or better the standard which it has turned into instead. I have read the NIST paper several times before you even knew it existed. These discussions to the mailing list come much in part from the concepts in the NIST paper. Let's define the problems we want to solve clearly then lets pull in these papers and discuss that. To me > they are a lot more self contained and clearer. For instance, Alex's > definitions below use the term "principal" which I don't think he's > defined yet. I think there's a good chance that terms or definitions > that have been used by the research community for 10-15 years have > clearer definitions and fewer conceptual holes or redundancies than > terms or definitions we come up with even if based on common practice. Yes I should have defined principal. But I think I was pretty damn clear in my descriptions. I am not trying to define a standard here or replace NIST. Everything that I have said complies with the NIST paper. You're attempting to make it sound as if it does not and trying to distract from a simple approach. I am taking this in baby steps. 1). Discuss the problems in terms people on this list can understand but be clear 2). Pull in the existing research on these topics (yes NIST paper) 3). Come to some conclusions 4). Propose an implementation path NIST paper: > http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf > > ANSI standard based on this: (I have not read this yet): > http://www.techstreet.com/cgi-bin/detail?product_id=1151353 > I looked at this one too. But we need discussion because interpretations can be flawed. The whole point to this effort is to discuss and define the real world problem first then to delve into the research that has dealt with it. This way we can express our interpretations and flush out and divergent view points. Alex
