Consumer-Centric Form-Fill and Sign-On
A few weeks ago, in the midst of the debate
over the Liberty Alliance 1.0 specification, Russ Jones
of Glenbrook
Partners asked me, hypothetically, "Doug, design
a system that makes it easy to fill out forms with personal
information and works consistently across cell phones,
PDAs, game consoles, PCs, and Unix workstations."
I particularly liked Russ' challenge because it's entirely consumer serving. He didn't ask for a system for merchants to increase their revenues via affinity programs or through the exchange of confidential information. In fact, I think that's what's fundamentally wrong with the Passport/Liberty/Magic Carpet systems. They claim to be for the benefit of the consumer, whereas in fact that's at best secondary to their merchant-centric objectives. But enough of the soapbox--on to Russ' challenge.
I'll restate Russ' original requirements* and add a few more:- Automated personal-profile form completion.*
- Automated creation and recording of unique, hard-to-predict passwords.
- Automated/transparent login to services once an account has been established.
- Works from any platform or device.*
- No unsynchronized multiple copies of profile data.
- State-of-the art encryption of data while stored
and in transit.
"Something-you-have and something-you-know" authentication. - No one (!) other than the consumer has access to his personal data for any reason whatsoever. (This isn't about identity federation. It's about consumer convenience, and protection of privacy.)
Let's postpone the details, and dive right into two examples:
Scenario 1: Automated Form Fill-In
You're surfing the Web from your WiFi-connected
laptop and encounter one of those ominous requests for
personal information. The form is so long, you have
to scroll your browser's window. Besides, you're only
marginally interested in what the site has to offer;
you're tired, hungry, grumpy, and you really don't want
to come up with yet another unique password you'll have
to save somewhere.
But wait! You've got a magic application, integrated with Internet Explorer, that solves everything. You simply click on the Fill Forms button in the special IE toolbar, and magically, all of the fields are correctly populated including the generation of a unique, hard-to-guess password. You look over the form, decide that since your date-of-birth isn't required, you won't provide it after all. You click the Submit button. Done. One hundred keystrokes have been replaced by two clicks of a mouse. And that unique password has been automatically saved for the next time you want to log into the site.
Here's what happened behind the scenes. Using HTTP, the form-filler application retrieved your encrypted personal profile from the same server that hosts your web site. The application decrypted the profile using the private key stored on your laptop and locked with your PIN. If this was your first recent use of the application, it prompted you for that PIN. (It's security via "something-I-have and something-I-know.")
A profile is just a flat XML file. Yours is stored on your web server, but your mother--who doesn't have a web server--stores her profile with her cell-phone provider, a service bundled into her monthly charge. Your brother uses his bank, which offers the service for free as an incentive for him not to switch banks. No matter where your profile is stored, however, you're the only one that can read or modify it. It's encrypted such that it can only be decrypted using a private key and a PIN. There's no need for asymmetric public-key cryptography in this situation, since the data is being both stored and retrieved by the same entity. Your mother's cell-phone company can't access her profile, nor can your brother's bank read or modify his.
Scenario 2: Automated Secure Login
Later that day, you need to check the balance of your
personal bank account from your cell phone. You select
Bank of America from a list of sites and press the OK
button. If you haven't recently performed a sign-on
operation, the phone prompts you for your PIN. The system
then retrieves your personal profile from the same server
you accessed earlier from your laptop. The phone decrypts
your profile using a local copy of your private key.
Next, in the background (i.e., invisible to you), your phone retrieves the BofA login screen, fills in the username and password fields, and simulates clicking of the OK button. Next you see the post-login screen containing your account information. With only two clicks, and perhaps supplying a PIN, you have your bank balance. The authentication process was invisible to you. You never had to deal with a username or a password. You can reach an authenticated screen as easily as you can reach one that's public. Checking your brokerage account is only two clicks away: Select the site from the list, click the OK button, and you're there.
Software
The proposed solution has two components:
1. An application that has been implemented on all platforms.
2. A single stored copy of the profile, retrievable
and modifiable from any platform.
The client-resident software I have in mind (or something close to it) already exists in applications such as RoboForm, a Web-form filler and password manager. All that's required is that RoboForm or comparable applications store their data on a centralized service or portable device as described below.
(Note: If you haven't tried RoboForm or something similar, you really should. It has changed the way I interact with authenticated web sites. Other than being a satisfied customer--I paid $29.95 for the Pro version--I have no association with Siber Systems, the company that offers RoboForm.)
For AI RoboForm to meet Russ' challenge, two things are needed:
- It must be ported to a wide variety of client platforms.
- It must be capable of storing and retrieving profile data via the Internet.
Storage
There are, in fact, at least two possibilities for the
storage of profiles. They can even be combined (synchronized).
The first is the on-line database, accessible from all
platforms, as described in the scenarios.
Profiles storage can be a service provided by anyone.
No coordination or standardization is required, except
that the data must be compatible with the application
described above. It would be possible to standardize
the format of the data and its method of storage and
retrieval in order that different client-side applications
and data stores could interoperate, but that's not strictly
necessary. So long as you can get software for all of
your client platforms, and that software is compatible
with your data store, the requirements are met.
Profile storage could be a commercial service. It could
be provided as an incentive to create and maintain other
relationships, such as with cell-phone vendors or banks.
Or you might choose to store your profile on your own
server. After all, it's just an encrypted flat XML file
that can be uploaded and retrieved using authenticated
HTTP. Nothing more is required.
A second possibility for profile storage is in portable devices such as SmartCards or USB tokens. These will work so long as all of your client platforms have interfaces to your selected storage device. Plug the Flash-ROM key fob into the USB port, or push the SmartCard into the reader, enter the PIN, and the data is accessible, for reading and writing, to your application. (In fact, RoboForm already works with USB disks.)
If a compatible interface isn't available on all client platforms, it's possible to synchronize the portable and centralized stores via the client software so that users can have a choice of either method. Although if you have access to a centralized system, I wonder whether there's real value in the portable option. Remember, this is all about convenient form filling and sign-on to Internet-connected systems. In other words, by definition, the client will always have access to the Internet at the time it needs to perform sign-on operations.
Standardization
When I first mentioned this idea to him, Scott
Loftesness (also of Glenbrook Partners) referred
me to RFC2706,
the Electronic Commerce Modeling Language (ECML). This
is a very simple specification that standardizes the
names, data types and maximum lengths assigned to fields
in HTML forms. It seemed like a good idea, and one that
would aid the adoption of automated form filling and
sign-on.
But that was before I tried RoboForm. I've now been to dozens of web sites, and used RoboForm to complete scores of on-line forms. It has done so with 100% accuracy. It's smart enough to figure out which profile element to use for each HTML form field. I'm sure it will eventually encounter a form it can't get right, but so far it hasn't. So while ECML is a good idea, empirical experience with RoboForm has convinced me that ECML isn't a prerequisite to the adoption of this technology.
Likewise, there's the question of the standardization of profile data and the methods used to save and retrieve it. Again, I'm of mixed feelings. Without such standardization, the "runs on all platforms" requirement will imply that a single vendor (or a consortium) must develop compatible client software for all of the platforms (PDAs, desktops, laptops, cell phones, etc.) you use. It sounds unlikely. But given the relative simplicity of the software, and the availability of platform-independent development kits (particularly for cell phones) it's not unreasonable for developers like Siber Systems to support all of the important devices. Of course, standards would make it possible to support even unimportant and uncommon devices, so I'd like to eventually see such standards. I'm just not sure we need the standards in advance. Someone like Siber Systems could develop the technology, and thereby create ad-hoc standards.
Perspective
I'm not proposing this solution as an alternative to
the plans of the Liberty Alliance. But I do have to
ask, what does the Liberty Alliance offer to the consumer
that isn't supplied at least as well by a scheme such
as described here?
Some people who replied to my On
Liberty essay pointed to the value of Liberty's
ability to revoke multiple logins in a single step.
But that's only necessary because of the risk I pointed
out in which a Bad Guy who gets into one site can, through
Liberty's Circles of Trust, get into others. I'm curious
to hear the arguments that support the much more elaborate
mechanisms proposed by the Liberty Alliance and others.
Doug Kaye, 30 September 2002