[Auth]I claim simplest design of all time!

[Ron Burk]

> 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