Re: [Auth]status

[Barry Fitzgerald]

I'm catching up on some e-mail and just read this discussion.  I'd
skimmed it before but just read it in detail.

I have a few observations:

1) I'd like to clarify the points of the horse-race, accepting projects
for active dotgnu endorsement, and the requirements to fulfill that
endorsement.  When we made the decision to accept a horse-race scenario
a number of months ago, we did so because everyone was sort of running
off in different directions.  This is not a bad thing at all, it's
natural.

Who was it that said "Managing programmers is like herding cats"?  Was
it Knuth? Anyway, my experience here with DotGNU has somewhat proven the
statement. :)

However, this is not a bad thing at all.  To some people it looks like
chaos, and it is - but that's not bad.  Not when you have the GNU GPL
that is.  Take 10 artists and put them into a room with a canvas and
some paint.  Ten great artists will paint something entirely different. 
Ten mediocre artists will probably paint the exact same thing in
concept.  I think that the differentiation in ideas here only goes to
show the talent that you both have and that you're dealing with.  In
this horse-race, you can develop two different implementations and come
up with different points in each one.  Pluses and minuses in both
packages.  This is just part of the equation.  Where the GNU GPL comes
in is that it ensures that you can learn from each other, and this is
very very good.  I think that you *ARE* learning from each other, from
what I've read.

In any case, this is the best possible result.  If someone came to the
Steering Committee with some horribly insecure library and asked us to
endorse it, would we?  Define endorse - if endorse means that we
recommend it for use, then no - we wouldn't.  If endorse means that we
might link the code to our site asking people to work on it - then
perhaps we would.  That's the whole point.  At some point (pick any
random point in time) somebody out there is going to find SOME problem
with ANY program.  That person is going to find some security problem or
some privacy violation.  

In the proprietary world, these are killer issues.  In the Free Software
world, they're just demons to be exorcised.  However, the best way to
get here is to accept as much code as possible and learn from it.  If
there's nothing that can be learned, then just throw it away.  But, I'm
willing to bet that there's SOMETHING that could be learned from any
implementation out there.  And that means that there's some idea that
can advance any one of your fine packages.

This brings us to my next point:

2) Combine ideas and projects where they overlap.  Cut your projects
down where work can be combined, if it's feasible.  I happen to like
shared components that other projects are allowed to use.  They save
time, they save space, and they cut down on dependancies - which is a
win-win for everybody.  The only problem occurs when you have conflicts
of personality.  I think we have one of those here and I think we need
to get past it.  Neither of you are intolerant people, from what I've
seen.  

However, let's say - for example - that a profile provider project is
feasible to cut down on work for both of you guys.  This is
hypothetical. :)  If that is possible, and you guys run into some issue
that you just can't get past on personal levels - well, that's why
coders a long time ago invented ifdef's :).  Seriously, everything is a
compiletime option with Free Software.  Or, if compiletime doesn't work
(end-users don't know what compiletime is) then simply build flexibility
models into the program.

I'm not personally certain that profile provision is distinct enough to
separate it from an authentication system.  Most external authentication
data for a webservice is itself profile data of sorts.  A password and
username are just token values in the end.  The same thing could be said
for a string or a stream in general.  Some people might argue that you
should treat identification with a great level of security than profile
data - I personally disagree, one should treat their profile data as
securely as they treat their authentication data.  There's another way
to phrase "Item A should be more secure than Item B..." -- That is to
say that "Item B should be less secure than Item A..." 

However, this isn't to say that FrePort and IDsec wouldn't have any
overlap.  I think that you guys are slowly heading towards very similar
products implemented largely in different languages.  Language barriers
will probably be your only major barrier to sharing code, sooner or
later.  That's just my gut feeling.

3) Trust is a bizarre subject.  I've often been at conflict with it. 
Yes, trust is largely an entity to entity issue.  However, the more
mechanisms that can be built into a product to make it easier or more
flexible to protecting somebody's data the better.  You're both actually
right in this argument.  And, in ways, you're both actually wrong - from
my perspective.  Just try to be a little bit more flexible.  :)  There's
a human reaction whenever someone is criticizing something that you
created - it's to be defensive.  The only way to get past the issue of
established trust and reconcile the argument is for both parties to
budge and admit that trust issues aren't entirely structural, and at the
same time, trust issues can be manipulated by the structure of a
program. 


4) The GNU GPL is important.  Try not to interface too often with
programs that aren't Free Software - because you'll find that you're
going to be embraced and extended over time.  This is just a landmine
that I see as potential if we depend on too many proprietary
dependancies or collaborate with too many proprietary programs.  It's
just something to keep in mind.

Besides that, keep up the good work and I'd personally say that
design-wise, both IDSec and FrePort have wonderful and diverse aspects
that you both should be proud of.  I consider them to be great additions
to the DotGNU collection of active proposals/projects.  Let's keep up
the good work. :)

        -Barry



Hans Zandbelt wrote:
> 
> Hi all,
> 
> I'd like to make up my personal intermediate balance concerning IDsec.
> I got upset by the following sentence in one of John's first mails:
> 
> > You and I established your indifference to the hiding of incidental
> > "sites visited metadata" in our long ago conversation. Please, do not
> > believe for a moment that your shouting me down then, gives you carte
> > blanche to do so now. I did not agree with you then, and I don't now,
> > and my reason is unchanged
> 
> This is certainly not true and I wanted to prove this to this list.
> This is an attempt to take the discussion one step forward, and to
> gain personal moral support for further development of IDsec.
> Let's leave the remote Profile Manager for further discussion in a
> next mail:
> 
> After our discussion on the local issues and the "PHP-proof" that I
> presented: can we agree that there is no fundamental flaw in the
> IDsec local Profile Manager scenario? (Merely practical problems that
> need to be worked out and that equally exists in other systems).
> 
> So John and others, have I been able to convince you partly yet? If
> not I would appreciate it if you speak up how and not wait for
> a few months and then bring up the old arguments telling me that I
> shouted you down last time.
> 
> Thanks,
> 
> Hans.
> 
> PS: this is by *no* means a vote for IDsec. I just want to get personal
>     confirmation at least from some people that I am on the right track,
>     along with the other virtual identity initiatives.
>