Re: [Auth]I claim simplest design of all time!

[Albert Scherbinsky]

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
standard.

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
companies. :)

This does not preclude someone writing one and applying the
GPL to it.

Albert

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