Following up on my recent post about the DHS recommending a commercial data aggregator to create a new database for the data access requirements of the Real ID Act, it appears that it may not be as dire as original reported by Unreal ID. Specifically, Unreal ID claimed that the DHS recommendation was to:

[h]ave a private data aggregator act as the central database. This is the plan advocated by DHS. The plan calls for the outsourcing of all drivers license and ID card checks to a private corporation, who would then charge the states for each check performed. DHS head Michael Chertoff personally ordered this option to be chosen, according to a senior administration source.

A Wired story takes some issue with this, and provides text of the recommendations Unreal ID was operating from. This is pretty useful. While this entire component of Real ID is awful, it's not quite as bad as I surmised and wrote about previously. Let's look at the suggestions as they exist in this text (whether this is the actual text of the recommendations or not):

First, the States could simply be left to make whatever arrangements they choose among themselves. This approach would maximize State flexibility but could prove burdensome and chaotic in implementation.

There is no doubt that this would prove "burdensome and chaotic." Of course, that's one of the pluses. Imagine the states opening up their databases in ways that made using that access completely unworkable. They'd give up on this unnecessary requirement and it would go away. It's no surprise that DHS would dislike this one; it should be clear that the intention was never really to allow states full access to the databases of other states, but rather to make access easier for federal agencies by standardizing access. Why would Jim Sensenbrenner care about giving all the states access, when it's something they've never pursued?

The language is a bit confusing for this second item, and that's somewhat disturbing. It's disturbing because it's not clear just how it works in conjunction with the third recommendation. I'll explain more below:

Second, the States could create a "federated" or "decentralized" system, in which each State continues to maintain its own records but the interface among databases is standardized. This might be implemented as a "pointer" index that allows States to determine where to find relevant records about applicants. This system would be similar to DOT's Commercial Driver's License Information System (CDLIS).

The third possibility, listed below, does have distinguishing characteristics, but some of the language of this possibility is unclear. It appears to blend federated data and decentralized data. There's no reason states couldn't standardize interfaces to their data without providing some central federation service that provides pointers to the data. That sounds like it comes suspiciously close to the clearinghouse discussed below. Instead, the data could simply be decentralized with standardized access methods used across the states.

Both possibilities sound horrid. The pointer database suggests a database of identifying information -- quick, tell me what other than SSN could be sensibly used as the pointer -- that provides ready access to go gather anything a wily user wants to get out of the system. The "chaotic and burdensome" approach sounds much better. This sounds like a data protection nightmare. After all, this pointer index would, as a matter of course, contain enough information to identify a person. Getting that data would expose a hundreds of millions of identities.

Of course, it would also make it easier for the TIA replacement to find the data.

Finally, there's the third possibility, the "clearinghouse" solution. Here's how it appears in the Wired document:

Third, the States could utilize an intermediary, or clearinghouse, to assemble necessary information about a particular applicant. This approach would require only one entry of information by a State DMV, and one transmission of all verifiable information to the clearinghouse. The clearinghouse would not store data about applicants; instead, it would determine which databases and systems to search and then would provide the relevant information once the data is assembled about that applicant. For example, the clearinghouse would communicate with SSA to verify the applicant's Social Security number (submitting the applicant's full legal name, date of birth and Social Security number provided by the applicant), submit applicant data through EVVE, submit applicant data to USCIS' SAVE program as applicable, and check whether the applicant is licensed in another state through queries to individual States. Once all these lines of data were verified, the clearinghouse would return the full, verified response back to the State DMV. In none of these approaches would a large permanent multistate collection of individual records be created. The "federated" and clearinghouse alternatives are focused on the infrastructure among systems, and would not act as a substitute for the databases that hold the actual information (i.e., the databases would not "dump" into the clearinghouse).

Note that the description is very clear that there would not be "a large permanent multistate collection of individual records" here. Of course, that's patently untrue, because the pointer index of the federation would, in fact, have a gigantic collection of individual records. It would have to, if the goal is to find all records, for example, that pertain to my license and potential licenses I might have had elsewhere, which is really the sole reason to create this monstrosity in the first place (excepting the ulterior motives I suspect are at this requirement's heart.)

It's easy to see why this solution looks like such a good sell. A rogue user from some random state is going to have a much more difficult time acting independently to harvest huge numbers of records from the other states; that risk is greatest when only the individual states will be tracking access, such as in the federated or "burdensome and chaotic" solutions. What's more, this one might be seen as attractive because it doesn't have to store anything, outside of the time that it's assembling these nice little records packages for the state DMVs. However, there's something far more sinister here.

From a data leakage perspective, it's going to be far more difficult to track American citizens if the records of movement are stored in requests between states. First, states would have to give it up. Second, the feds would have to be able to make use of the morass of various audit records. Oh, but that beautiful clearinghouse. It's going to know exactly where I am, when I requested a license or otherwise had business with the DMV. It will quickly put the federal government on a path to track movements of Americans (further on the path than it already is.) The data may come and go, but those logs will be rife with rich information to be mined, intruding into the private comings and goings of Americans.

No, this third option doesn't create a new database. Instead, it creates a new tracking system without the encumbrances of a new database.

The concluding paragraph of the text provided by Wired is someone comical:

In developing such a system, DHS expects that the all appropriate privacy and security mechanisms will be included to reduce the risk of unauthorized access, misuse, fraud, and identity theft. Although DHS considers the third option to have the highest probability of timely and effective implementation, DHS will not require States to adopt one of these approaches as part of these regulations. DHS will consult actively with States and other stakeholders with a view to assisting the States in choosing the alternative that is most likely to reduce the costs of meeting the verification requirement. DHS will be examining ways in which DHS may assist States in most effectively meeting the requirements of the REAL ID Act. This may involve assistance through federal procurements or grants. Any such assistance will likely be provided separately from this NPRM, but DHS welcomes comments on the alternatives and on methods by which it may assist the States in reducing the burden of complying with the requirements of the REAL ID Act.

(emphasis added.) Of course, it's rich enough to read about DHS expecting "all appropriate privacy and security mechanisms" to be included, given their repeated failing ratings for computer security and data protection, when they're even capable of filing their reports. However, the suggestion that they won't be requiring one of these to be selected is something of a joke. After all, does anyone believe that DHS will fund any option a state may choose?

Over at Homeland Stupidity, Michael Hampton has followed up his previous post to put these recommendations in context, concluding:

Don’t be too surprised in a few months when it’s announced that AAMVA got the contract after a lengthy wait, required for the sake of appearances and bureaucracy. After all, they’re already maintaining a similar, but much smaller, database for the states, which holds data on every commercial driver license holder in the country. This is the blueprint on which the national identity database will be built.

It does, oddly, sound a whole lot like the third possibility.