The plug-in you address is useless without an infrastructure behind it.
From my point of view, 99% of that infrastructure is already there:
it's web sites that customers interact with that require some
personal information on a regular basis, and require it in
the form of an HTTP(S) GET or POST. Most of the infrastructure
so far discussed here (while likely good, worthwhile,
necessary in the future, and neato) is completely
unnecessary for solving the single logon problem that most
web users would like solved today. Again, I understand
that the Big Goal is to solve much bigger problems.
I'm just talking about solving the very much smaller
problem I think most customers actually care about today:
single logon for all the web sites I browse to.
But we must define a protocol how user
data is requested because this doesn't exist until now. If websites
require
user name and password, they do it by displaying a form (somewhere in
the
html code) which is different on each site. You can not detect what
information the form is awaiting. We definitly need something (a
protocol)
that let us know, what we have to do.
"protocol" sounds somewhat sophisticated to me.
What exactly does the simplest possible useful solution
require? Well, it requires you (web page designer) to
tell me (Mr. Plugin) whether you want me to use GET
or POST, and it requires you to tell me what personal
information fields you're asking for. Let's make things
really nice for Mr. web page designer, and say that
you can also specify alternative names for our
"standard" fields. That's about it!
The main abstract work here is defining a schema
for the personal information. I really don't think there's
any chance of getting this perfect on the first try,
so I would vote for a very simple schema along with
making every provision for assuming that the
details and scope of the personal information may
change with successive versions.
A possible example:
Yeah, I think(!) that's exactly what I'm thinking.
The only problem I have with your example is that
you're replying in XML. Why? If you simply
let the web site specify a method (GET or POST),
a URL (to send the GET or POST to), and
any desired aliases for the standard
field names (e.g., I want you to put the
user's password in a field named "pass"),
then the web page designer does not have
to change any existing software that handles
logons or requests for personal information!
I understand the niceness of replying in XML
*for some future application*. But I guarantee
that I can get an order of magnitude more web
page designers to use a single logon system
that requires them to do no "programming" than
one that requires them to handle an XML
reply. Why not give them a simple solution
that works very easily with almost any logon
software they already have in place? You
could always supply an XML reply to any
caller that actually requests it, but I bet that
would be less than 5% of the actual usage
for years to come. Who really wants to write
more code to parse the XML into individual
fields and transform that into a call to existing
logon software, if the plugin can do all that
for you with virtually no effort on your part?
It really seems to me that it's possible to
make a single logon system that *any*
web page designer can take advantage
of with no more than 10 minutes of typing
(possibly 15 minutes of reading before that
to understand how it works). This certainly
does not do everything that .NET claims it
will do -- it just gives you some software that
can start displacing Passport in the market
place in the very near future (months instead
of years).
It also seems likely to me that this can be
done in parallel with the work on the Big Goals.
The main compatibility concern I can see
is agreeing to use the same schema, but
I can't see that the first version of the schema
need affect or be affected by the design of
the more complex system. In particular,
I don't think the simplest design possible
has any need to initially support whatever
detailed (and possibly quite complex) protocol
the eventual grand design will dictate.
Ron Burk
Windows Developer's Journal, www.wdj.com
_______________________________________________
Auth mailing list
address@hidden
http://dotgnu.org/mailman/listinfo/auth