[Auth]Server vs Clent side

[Scott]

Nick said:

I think client side software is pretty much useless. People don't like
plugins, and historically, plugin take-up is slower that technology take-up
on the serverside. As well as that, there are plenty of environments in
which they simply don't work.




I agree that plugins won't work in many situations, and that getting 
serverside install would be a good thing.  As far as a server side 
solution though, there has to be incentives for servers to install apps 
or provide a DotGNU page.
   Lets just say I have a monopoly on the desktop (95% of desktops are 
my OS)  and I state that this fall, I'll give everyone a Passport, then 
servers will install a passport page to be able to offer this product 
because 95% of my users can use it and would be able to 1click shop (or 
whatever the case may be) but if only 2% of users have a DotGNU key then 
do I really care to cater to that 2%?.  MS is working to tie the 
passport into hotmail and msn.com users right now, even before winXP has 
been rolled out as a way to put pressure on internet service vendors to 
adopt it.

the scary part of this is that 60% of servers are Apache open source 
products (I'm aproximating but as far as Open Source goes we have the 
webservers as a majority already) and that MS will likely offer close 
apps that run on top of this OR tie the package into MS server OS like 
Win2K. Now in order to offer up the Passport service the easiest way 
becomes to install Win2K, and once I have to pay for Win2K, that 
Linux/Apache combo price factor doesn't seem so appealing because I have 
to buy Win2K anyhow and in this way MS will attempt to wedge it's 
desktop monopoly into the server market. Even running an MS based apache 
Module, the app may not allow looking for auth anywhere but at a 
passport url.

If we create a Server side component, I think an Apache Module is a good 
place to start and hopefully working with the good poeple over at 
Apache, our DotGNU module could be shipped as one of the Modules that is 
included with the server (and perhaps even turned on) By Default. This 
is where we can use our strength in the server market to get a great 
critical Mass out the door. add to this that in the near future many 
will be upgrading to the new Apache 2.0.  Once we show that an 
alternative way of using a hailstorm app with a different way of 
Authentication, if MS Locks that DotGNU out of their server software 
with Close source, even though the standard they created states that you 
should be able to do otherwise, this is more ammo for the antitrust 
suits against them in progress now, they'd kind of HAVE to respect 
DotGNU or look real evil.

   A client side browser plugin has the benifit of giving the end user 
a choice right off the bat, and would allow a robo-form-filler as an 
alternative for sites that don't yet support passport like features. At 
the same time, it would be ready to act as a passport/DorGNU auth server 
when that option was available. and the client won't have to put all 
their data out on a remote server if tey want to keep it locally.