directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Triplesec] [AuthZ] Applications and Roles
Date Thu, 25 Oct 2007 07:26:47 GMT
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 <david_jencks@yahoo.com> 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

Mime
View raw message