[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Auth]I claim simplest design of all time!
Re: [Auth]I claim simplest design of all time!
Wed, 18 Jul 2001 20:50:49 -0400
I like it. ( I've been lurking on the list till now, but
this sounds good. :)
What is really needed then is marketing assistance in the
form of a nice web page that promotes the vendors of form
filling software giving end users a place to find the client
software and a list of web sites that use the dotGNU
So, how do you convince the vendors to cooperate? One
strategy might be to find a large web site that is willing
to adopt the dotGNU standard, then this represents a large
pool of potential customers for the form filling software
This does not preclude someone writing one and applying the
GPL to it.
Ron Burk wrote:
> >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
> 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.
> 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!):
> 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.
> 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
> 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
> 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 mailing list