Re: [Auth]The simplest thing that can possibly work

[Jeremy Petzold]

Do you think that you could write up a proposal as to how we would implement 
this? we need people to start submiting details as to how we should go about 
developing and deploying this system (how it will work, protocols to use, 
parts, base platform, advantages, ect). that way we can start bringing it all 
together and begin work. remember, we only have about 2 years to get the system 
out the door after that it will be an uphill battle against .NET.

-Jeremy 


On Sun, 15 July 2001, Ron Burk wrote:

> 
> 
> >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
> 
> _______________________________________________
> Auth mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/auth

Regards,

Jeremy
Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com