directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
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!!!
disrupting a delicate process where I was trying to bring in the community
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
(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
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
what kind of product we are to deliver.  If you think these descriptions are
then point out why so we can understand you.  Don't just hide behind words
the "standard".  Again we implement standards and know their value more than

Don't just say "no this route is wrong just use NIST material."  These
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
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
of the enterprise in a vacuum by just reading academic papers.  There needs
be some balance.

More inline ...

On 10/24/07, David Jencks <> 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
why not.

Also these are not definitions for the sake of a standard.  They're simply
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.
discussions to the mailing list come much in part from the concepts in the

Let's define the problems we want to solve clearly then lets pull in these
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
descriptions.  I am not trying to define a standard here or replace NIST.
that I have said complies with the NIST paper.  You're attempting to make it
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
2). Pull in the existing research on these topics (yes NIST paper)
3). Come to some conclusions
4). Propose an implementation path

NIST paper:
> ANSI standard based on this: (I have not read this yet):

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
and flush out and divergent view points.


View raw message