AW: AW: [Auth]Re - [Auth} A simple server-side authentication scheme

[Carsten Kuckuk]

Norbert,

>> [.NET]

So far, .NET is nothing more than a collection of specifications, some beta
grade implementations, and a lot of misinformation and buzzwords. This is
typical MS behaviour: First they announce something so that competitors stop
developing their products, and potential customers wait for MS products, and
then Microsoft starts development - if at all. Is anybody of you old enough
to remember the Cairo announcements? The object file system?

>> [Modified HTTP protocol]

They already did that with SOAP. There is no necessity to introduce SOAP as
a protocol on its own, as all it does is transfer an XML document over an
HTTP connection and specifying the semantics of this document, namely an ORB
request. XML-RPC solves the same problem. So does CORBA. Or DCE-RPC.

>>>>>
   As a side effect of Microsoft's efforts in this area (if they
   are successful), something really scary happens:  All of the
   world's authentication data will pass through Microsoft's
   "passport" servers.
<<<<<

That's the really scary part: They claim to have rights that only a
sovereign state has - to issue a passport, to naturalize people or expedite
people from the Internet at their own will, and to ask for taxes (service
fees for passport).

>>>>>
[..]  Essentially the idea was to build a powerful Free
Software system that provides all the benefits of .NET with one
big difference:  Instead of having a single company (Microsoft)
at the center of the .NET universe, we wanted to build a system
without centralized storage of authentication data.  This
thought eventually matured to become the basic architecture
which is outlined at http://dotgnu.org/arch.htm
<<<<<

So dotGNU has the implicit assumption that the requirements that led to .NET
are valid, not to be questioned, and that the design of the overall .NET
architecture is such an excellent design that it is worth copying. For me
.NET is a huge collection of different thhings, projects, interfaces,
protocols, programming languages, that I have not fully understood yet to
the degree where I can determine what's good and what's bad. For example, I
like the general idea of a single sign-on, but I hate it to be controlled by
one company. I see a demand for services offered via the internet, but I
doubt that new protocols have to be introduced. I even doubt that a common
runtime system has to be introduced to achieve this. I strongly believe that
defining the right interfaces and publishing rules for how services and
clients interact with each other is enough. It is secondary if services get
implemented in Java, C#, C++, Fortran or Assembler, as long as I can reach
them via a well-defined protocol like for example HTTP.

>>>>>
So now the DotGNU project must proceed on two tracks.  One track
(to which this list is devoted) for doing something quick that
will prevent Microsoft from monopolizing authentication services.
And another track for building a system that will outclass
Microsoft's .NET - the ARCH list is devoted to that.
<<<<<

I agree with the first goal, but I have my problems with the second - as
stated above.

>>>>>
DotGNU is not primarily a GNU project, but rather it is
primarily a project of FreeDevelopers, see http://freedevelopers.net

The goal of FreeDevelopers is to develop Free Software and
market it in such a way that the developers can get paid for
their work.
<<<<<

I was not aware of that. I was under the impression that DotGnu is a group
of developers working on a GPL'ed software system that would compete with
.NET, and would be without any direct financial interests.

>>>>>
That's something that Ximian is doing with the Mono project.

The plan for DotGNU is to provide emulation so that Microsoft's
bytecode can be executed in a "DotGNU Secure Execution
Environment", but not more.
<<<<<

Programmers who work on free software are very rare. The Mono project makes
some developers spend their valuable time on creating a simple copy of MS's
technology. They do not seem to understand that (1) this actually supports
Microsoft's goals and they do it for free (2) they will always chase MS as
they have to implement whatever MS decides. They will never lead. (3) They
are not available for other projects like for example Apache, Linux, PHP.
It's tempting to start such a project, members will feel like "We against
the rest of the world". But in the end it'S a waste of time. If you want
something that looks and feels and behaves like .NET, why don't you just buy
.NET?

>>>>>
Recently a Mono developer tried to convince the ARCH mailing
list that Microsoft has actually included some significant
innovations in their stuff.  Would you be able to (without
spending much time on it) check his claims for accuracy, and
whether they're really relevant?
<<<<<

I am still reading the ECMA documents, so I am in no way qualified to
authoritatively respond to his claims in a way a lawyer could, but here are
some points:
(1) When you read the Java Virtual Machine specification it's so clearly
written that you understand everything the first time. Everything is simple.
The introductory part of the CLI is so badly written that I had to re-read
every other paragraph and had to think for a very long time in order to
understand what they mean. And they distinguish between a lot of cases. When
it comes to security, simplicity is good, and complexity is bad. With such a
difficult to read spec it's next to impossible to spot security problems.
(2) Unnecissarily built-in Java-incompatibility 1: Identifiers. On the VM
level, .NET identifiers are case-insensitive whereas JVM identifiers are
case-sensitive. In practice this means that you can switch from Java to
.NET, but not back.
(3) Unnecissarily built-in Java-incompatibility 2: If a class implements two
interfaces I1, I2 and these interfaces happen to both declare a method m
with the same name and parameters, then a .NET class has two different
implementations I1:m and I2:m whereas in the JVM there would only be one
implementation of m that is shared between both interfaces. Again, you can
migrate from Java to .NET, but not back from .NET to Java.
(4) Unnecissarily built-in Java-incompatibility 3: Events and Properties are
just superfluous. They should have been introduced as classes of the
framework. Again, you can migrate from Java to .NET, but not back from .NET
to Java when these constructs are used.
(5) Unnecissarily built-in Java-incompatibility 4: Boxed types are
superfluous and should have been implemented as classes in the framework.
The only reason for their introduction that I can think of is to again make
it impossible to migrate from .NET to Java.
(6) Unnecissarily built-in Java-incompatibility 5: Value types (like
integers and doubles) have finalizers! Again, you can migrate from Java to
.NET , but not back.
(7) Here's a serious design flaw that they copied from Java: Serialization
allows you to create objects without running a constructor, and setting
members to values that are unchecked.

And this is only scratching the surface. The claim that .NET offers more
languages than the JVM is true, but just because nobody bothered to write a
Basic, Fortran, or Pascal compiler for the Sun JVM. For a computer science
student it would be a two month project to do that. [Maybe I should just do
that?!]

Anyway: I have invested a substantial amount of time in just reading about
.NET and haven't gained anything substantial from it. [Compare this for
example with what you have just learned by reading the paragraphs of the
Gelernter Manifesto dealing with cyberbodies.]

>>>>>
Now that I have your attention please allow me to quickly ask
(even though it's off-topic for this list), what kind of
bytecode spec should DotGNU use?  So far the following options
have been seriously proposed:
<<<<<

Why should you reinvent the wheel? GCC has a Java front-end, a Java
back-end, and a Java bytecode interpreter incorporated into the libraries.
And all is available under LGPL. I'd build on top of it. But have you asked
yourself if you really need a bytecode interpreter? Aren't you mixing
requirements with solutions? Is Bytecode-Interpretation a requirement or is
it part of MS's solution?

> > Please take the time and visit
> > http://www.edge.org/3rd_culture/gelernter/gelernter_p1.html
> > and read David Gelernter's "The Second Coming - A Manifesto".
>
> Read it :-)

And? What do you think of it? Isn't a system that implements some of his
ideas of more use to humanity than just a copy of .NET?

>> [cyberbodies]
>>
>> Ok, I understand better now what you mean.  Most is this is
>> quite outside the scope of the DotGNU project though.

Not really. Cyberbodies contain the information necessary to authentiate
yourself. Cyberbodies need to be stored somewhere. The computer that you use
in order to acces your cyberbody becomes the authentication server when it
accesses one of the web services that it has to authorize you for.

>> Only if you give them an incentive to set this up.  What is the
>> incentive?

Option 1: They could charge for storing profile data. This could be a
healthy busines model which is important. "We store 5K of profile data for
USD 5 per year"
Option 2: For the common good. Each web site could host for example 50
profiles for free. This doesn't add much to the traffic, and the used
database space is neglectible.

>> How will these servers be useful?  (What felt needs do they meet?)

You could go to an internet cafe, access your profile, and would have a full
workstation at your disposal. I could start working on a document here at my
work computer, go home, log in there, continue working on it, fly to New
York for a vacation, go into the internet cafe at Times Square, and work on
it again. You would always have access to your personal data and services
whereever you are, and with redundant storage, you would never have to worry
about losing your data. Compare that to what you have to do nowadays: Store
files on floppies, make backups, remember passwords, worry about other
people braking into your system, worry about a head crash. This would all be
gone.



Carsten Kuckuk