[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Auth]I claim simplest design of all time!
From: |
Ron Burk |
Subject: |
[Auth]I claim simplest design of all time! |
Date: |
Wed, 18 Jul 2001 17:10:44 -0700 |
Perhaps such an article could also be published in Windows
Developers Journal?
I don't work there any more, but I possibly am of some
use in getting press in some developer media venues.
I have written a proposal sheet for the simplest solution I can imagine,
which is extendible enough for future use.
I was determined not to beat this horse again, but this got me going.
The simplest solution *is* extendible because it assumes
nothing about the future except that you will need standard
names for data fields like "Name", "Account", "Password",
and so on. Does anyone doubt that assumption?
If you're willing to go with that assumption, then read on.
Ok, now I've stripped the simplest possible design even
more -- no client software! Or rather, no dotGNU folks
have to write any ANY SOFTWARE WHATSOEVER!
(I know, it's like I'm a used car salesman trapped inside a
programmer's body :-)
I'm still operating on the level of strategy and market forces,
and when someone pointed out the vendors of "form filler"
software, that got me started thinking (see "Co-opetition"
and that ilk for books that have warped my mind). I started
trying to see various ways those folks fit into the picture,
and then today I realized that they should be cooperators, not
competitors. So, here we go:
The Absolute Simplest Design of Maximal Use to dotGNU's Goals
===================================================
Assumptions:
a) dotGNU needs exponential growth that starts Real Soon
to have any hope of catching up with Passport.
b) dotGNU will have to define or endorse a data schema at
some point so that, for example, your software can
ask my software for my "Shipping Address" -- they both
have to agree on the names of things.
c) Having a dotGNU-branded solution to the *current*
single logon needs of end users and web page flunkies
up and running on thousands of web sites and in use
by many thousands of end users by the end of the year
would be *extremely* helpful in selling more complex
dotGNU solutions to these same sets of players later.
Proposal:
a) Begin immediately defining the first version of a schema
for personal data (name, address, credit card #, etc.).
This work presumably has to be done in any case.
b) Work closely with all the current vendors of "form filler"
software in developing this schema (which would be a
good idea anyway, because they probably know much
more about what kinds of fields web sites actually use
than anyone here). Their motivation is to support
this standard so their software works better and has
some hope of surviving if Passport usage continues to
spread. They, not dotGNU, will supply the client-side
software -- they've already done 98% of the work!
c) In addition to this schema, define a MIME type that allows
web sites to specify requests for data fields from the
schema. This MIME type will look a whole lot like the
schema itself, except it also lets a web page flunkie
specify a set of requested fields, and how those fields
should be transmitted to their web site.
To elaborate on (c), here's a basic flavor example. As a web
page flunky, my web site administrator gave me a CGI program
I am required to use for logons. It is at URL "/cgi-bin/logon.asp",
and it expects an HTTPS POST containing two fields: "MyName"
and "SecretPassword". Assume that dotGNU's names for
these fields have been defined to be "Name" and "Password".
My current logon web page (the one containing a form
that will be POSTed to /cgi-bin/logon.asp) is at "/logon.htm".
To support the dotGNU single logon standard, I create
a data file at "/logon.gnu" that contains the request for
logon information, it might look like this (example only --
don't hold me to details!):
<dotGNU-Request>
<method>POST</method>
<URL>https://www.mysite.com/cgi-bin/logon.asp</URL>
<Name>MyName</Name>
<Password>SecretPassword</Password>
</dotGNU-Request>
Given this file, I now modify "/logon.htm" so that it
contains this somewhere:
<embed src="/logon.gnu" height="1" width="1" />
I'm done! No coding, no certificates, no third-party servers,
no installation of software, I probably don't have to
get permission from anybody in the corporate hierarchy,
and so on and so forth. My web site now supports
automatic logon for any client software that supports
the dotGNU standard. (I'm actually fudging here,
as I haven't worked out whether <embed> is
the right mechanism or not. If nothing else,
a button labelled "dotGNU Logon" that links
directly to the .gnu URL would work.)
Now, if a user who has any dotGNU-compatible
form-filler installed goes to the page at "/logon.htm",
that software (which has registered itself to handle the
".gnu" extension/MIME type) will take over. It will fetch
the file at "/logon.gnu", parse its extremely simple format,
and discover that the web site wants to get a POST
sent to "/cgi-bin/logon.asp" with field names of "SecretPassword"
and "MyName" that are set to the appropriate fields
from the user's private database of personal information.
Advantages:
a) dotGNU folks have to write no software
(NO SOFTWARE!). (I confess, this is probably
actually a disadvantage for people who care
more about coding something neat than winning
in the marketplace.)
b) It could not get any simpler than this, therefore,
it could not get to market any sooner.
c) dotGNU folks do not have to worry about UI
design -- let users choose from among several
competing (and already existing!) offerings. Nor
do they have to worry about coding an encrypted
database -- that work's already done.
d) It solves very real problems for end users, vendors of
form-filler software, and web-page flunkies. It uses only
existing technology that all the players are very
comfortable with, making it an easier sell for
everyone.
e) It is always easier to do effective PR for products
that are simple and easy to understand. This would be
much easier to do effective PR for than more complex
future schemes.
f) It is entirely compatible with future dotGNU efforts,
and entirely extendible. If you create a dotGNU
authorization server, all your server has to do is support
the very simple MIME type for requesting data, and
anyone using this "product" would be able to go there
and copy their personal information into your server
with the press of a button. In fact, it makes a whole
body of existing personal information (users of existing
form-filler software) compatible with future dotGNU
efforts.
g) Most of the the work for the client-side software is
already done AND ALREADY HAS CUSTOMERS.
h) Several vendors who already have relationships with
customers will be doing the work of selling to end users.
i) It is simple enough that it will attract web page flunkies
like a magnet -- they love stuff like this that provides
functionality but requires no programming or hassle.
j) You involve vendors of form-filler software with the
dotGNU effort, and they may be useful allies for
future efforts.
k) Most of this is work you have to do anyway, no
matter what architecture is eventually selected.
l) There probably never were any legal pitfalls in
the simple ideas I've put forward, but there
sure aren't any in this one -- dotGNU isn't actually
making any software!
Ron Burk
Windows Developer's Journal, www.wdj.com
- [Auth]I claim simplest design of all time!,
Ron Burk <=