[Auth]technical details

[Ron Burk]

> I have also updated my examples to take into account the
> feedback on the list.

* Possibly useful to allow the web site to supply the value of a
   data field in its "request". Idea is that sophisticated web sites
   could make initial sign-up highly transparent by handing the
   client his new account name (and/or other information that
   is generated by the web site -- some sites will assign you a
   password, and that option becomes more appealing when
   there's a framework in which the customer never has to see
   or type the password). This is for web sites that can dynamically
   generate the appropriate .gnu file.

   Another case is when the web site already has your credit
   card information on file, and they just want to confirm whether
   or not it's still accurate.

* There's a semantic difficulty in the fact that you've started
   describing a database, besides an interface for requesting
   information. The former is both more difficult, and may unnecessarily
   constrain vendors, who already have their database designed.
   For example, the typical web site just wants to ask for "Credit Card".
   But the personal information database will want to allow for
   multiple credit cards, each of which the user can assign a mnemonic
   name (a name not at all visible in the information request space).
   Same story with addresses, and even names.

* I think(!) I understand the motivation for making a hierarchical
   namespace of field names. However, I would feel better if the
   web site could still just use a flat namespace. Most web sites
   just want "Password", for example. Most web sites don't
   necessarily want to specify what kind of "address" you should
   give them. The major exception being when they want to specify
   that the address should be identical to the billing address for
   a given credit card.

* Speaking of having the web server supply data to the client,
   perhaps its useful to allow inclusion of a comment field,
   for the client software to optionally use to describe why the
   web server is asking for this.

The request interface seems to be rapidly getting to the
point where the vendors of the actual client software need
to be involved (the folks who already have complete databases
implemented, and must be sold on the idea for it to succeed).

> Let us say the web site redirects the client software
> to the following URL:
>    x-dotgnu://localhost/<request-info>
> the browser will invoke the installed x-dotgnu
> protocol handler to handle the URL and will display
> any content output by the protocol handler.

Interesting technique (meaning, I bet I can find a
use for it on some project or another :-). Thanks for
the additional description.

Ron Burk
HighTechInfo.com, www.hightechinfo.com