[Auth]The simplest thing that can possibly work

[Ron Burk]

> specifically what ron seems to want is
> just the XNS protocol without any web agencies (that host web agents on
> behalf
> of users).

No -- what I want is to succeed in the marketplace, and very
quickly. To do that, I don't want participating web sites to
have to install *any* new software whatsoever, and I don't want
them to have to learn anything that can't be described in
a *few* paragraphs that can be understood by the
average HTML flunky (unless they're trying to accomplish
something more complex than the normal "please give
your account name and password" or "please fill out
your billing/shipping information"). For what I want, XNS
is TDC (too damn complicated). I want to win.

HTTP was a crappy little protocol. HTML was a crappy little
markup language. They won by being simple and solving
a problem. Now, of course, people can build and sell
huge castles of complexity on these crappy little initial
successes. Would HTML have won if it had started out
as HTML 4.01, asking browsers to support (egads!)
ECMAScript, style sheets, and such? It's easier to
win if you start with a crappy little solution that's
simple and solves a problem. Build the complexity
after you get some market penetration. But start getting
that market penetration today!

I completely understand that Microsoft (and dotGNU) envision
grand schemes with much more capability than this.
However, the customer is not using those capabilities today.
Given the multi-million user installed base head start that
Passport has, the most critical thing for dotGNU to accomplish
is to ship something that attracts customers ASAP. When you
absolutely have to have exponential growth to succeed,
then a delay in getting started can critically affect the outcome.
Doesn't mean you can't be working on the grander schemes
at the same time.

> 1. You mention authenticating to a web server. For now, this is obviously the
> site to which they are connecting. Will the user ever be authenticating to a
> gatekeeper (presumably their ISP) in the future?

The answer is simply: I don't care. Get working today
the simplest possible solution that solves customer's
problems. I much prefer getting some real
customers and evolving with them so I know I'm not
out of touch with what they want.

> 2. What authentication method are you suggesting? I would like to avoid
> passwords. Is .NET using Kerberos? Perhaps we should think along these lines
> (Neuman-Stubblebine also). I know this is an implementation detail, but it's
> actually kind of important at this stage.

You're thinking way too complicated. I want to use whatever authentication
method the web site is *already using*. Place as few requirements on
existing web sites as possible! Virtually all web sites simply have you
transmit your account/logon via an HTTPS GET or POST. That's exactly
what I want the plug-in to do. Of the *slight* changes that the web site
would have to make, changing their software that currently responds
to that GET or POST should not be one of them. They should
only have to tweak the display portion of their (for example)
logon screen so that it includes enough information to invoke
the dotGNU plug-in if it is present on the client. The plug-in doesn't
have to know Kerberos or anything else -- it just has to be
able to perform a GET or a POST (which the Netscape plug-in
API already does the work for). Simple, simple, simple.

Passport has currently won the "who has the most clients" war.
Microsoft has huge leverage there. They have much less leverage
on the web site side. There is still time for an alternative to Passport
to catch up with the installed server-side base of Microsoft. The
key to doing this is to make it dead simple for the people who
create web sites. You have to make a solution that can be used
by even a web page flunky who has no ability to do anything
to the web server except upload data files into its URL space.
That's the way to catch and surpass the installed server-side
base of Passport and that, in turn, is the only hope there is of
eventually catching up with the client-side base. Once you have
a whole lot of sites informing customers that they support the
dotGNU single-logon system (and making it dead easy to get
the plug-in), then you have at least a chance of taking on
Passport.

The only reason Passport has not already won the server-side
installed base war is that it requires an SDK. A web page flunky
cannot single-handedly start using Passport -- they have to get
help/permission from an administrator. If dotGNU starts
out with similar requirements, good luck ever catching up. If you
want to do something grand, you better do something really
simple and useful ASAP to get your foot in the door, IMO.

Forget about making something cool enough to impress
other geeks. Forget about trying to attract the support of
ISPs. If you can create something that wins the hearts
(and logon pages) of web page flunkies, then you win.
Create a solution that they can't unilaterally decide to
use with no outside help/permission, and you have a
real tough slog with dubious chance of victory.

> 3. When you say "personal information", what are you thinking of? Data that
> normally gets stored in cookies?

I'm thinking of what customers *actually do today*.
This would doubtless grow over time (again, I like to get
customers and grow with them instead of trying to forecast
everything in advance). Here's the simplest information users
have to supply to web sites over and over: account name,
password, name, billing address, shipping address, credit
card numbers. Much more is possible, but this covers
95% of the personal information that real users *currently*
need from a single logon system. Again, what most real users
need today is pretty simple.

My viewpoint is probably affected by having spent some
time during the last few years helping real people
learn to use computers. This is where the remaining
growth in computer usage is -- they aren't making new
geeks very fast. It is a humbling experience to have
someone point out all the needless complexities and
idiotic contradictions in software that I simply could
not detect any more after years of usage. Just as
Microsoft has consistently overestimated programmers'
ability to move to new technology, I believe they are
overestimating users' abilities to embrace more
complex web technology. My Dad is never, never
going to use any Passport technology beyond the
simple single logon feature. In truth, he will never
even use that feature unless he buys a newer
computer that forces it on him. It's exactly
the same story with every other non-geek I
know who has started using computers in the
last few years. That's the reality I see in the
marketplace, and that's why I believe the really
simple solution is the most important to execute
right now.


Ron Burk
Windows Developer's Journal, www.wdj.com