[Auth]server-side processes

[Ron Burk]

 > I havent thought much about what would be necessary
 > server side though..  in the simplest case we could use
 > POST/GET to get in an the target would be the main window.
 > are there cases where we would need a server side
 > process?

I've sort of got extreme blinders on, thinking only about the
kind of really simple single logon that, by rights, should
have been some kind of w3c standard years ago.
For that application, I think(?) the only server side
processes needed already exist.

My logic is: if you've got a server that would benefit from
participating in a single logon system, then you already have
some kind of logon. You pretty much had to have implemented
it as a POST or a GET (which I think a Netscape-style plugin
can do on the fly). What exactly your server is doing with it,
we don't know or have to care (must be accessing some kind
of database, but that's not our business). All we have to care about is
that you can easily create a web page that will instruct our
plugin to transmit back to you whatever POST or GET you
already accept, except with the personal information filled in
by the plugin instead of a human.

If the system is just a repository for personal information,
along with a specification for how the web server accesses
it, I can't think of any other requirements that need to be
placed on the server (but I sure could be wrong).

As someone already pointed out, there has to be some agreement
on names and structure of data. That seems like the main area
where a server-side process might have to be tweaked (but not
much, and not much deeper than tinkering with a web page,
and possibly adding an auxiliary data file). A certain amount
of surveying of web forms might be in order, if I'm understanding
the direction correctly (e.g., does each line of street
address need to be broken into a separate field? do we
have to support formatting certain items, such as credit
card #s or phone numbers in different ways to make existing
forms happy? etc.). Might be the sort of problem that a
request-for-comment phase is good at solving.

There's also some basic-but-important database
design on the client side. One user can have
multiple credit cards (I'm pretty sure). A credit
card can only have one billing address (I'm not
quite as sure). One user has only one "real" name
(I think), but each credit card a single user has
may have a different name associated with it
(I'm real sure -- mine do!). Somebody's
probably got some neat software for laying
out the database design graphically.

Weird idea: I wonder if there's a use for a client-side utility
that lets me help the plugin automatically pump personal
information into a web site that does not yet choose to
support the dotgnu single logon system. Probably a
feature for geeks only, and yet I'm strangely attracted
to it :-).

Likewise strange thought: this could be viewed as a kind
of cookie system, in which the user (not the server) controls
the cookie data, and in which the cookie data is securely
encrypted (unlike browser cookies). Is there some cool
thing servers could do if we allowed them to store
arbitrary cookies in the user's personal encrypted database?

It's-time-for-bed-weird-thought: Will I somehow be able to
use this system to automatically fill out those boring online
questionaires you have to answer to get free subscriptions
to trade publications?

Ron Burk
Windows Developer's Journal, www.wdj.com