% fortune -ae paul murphy

Identity and Documentation


Can't read that? Umm, how about this:

0000000 135414 176530 003653 151456 165646 137525 036745 155672
0000020 067306 126637 040063 003023 027511 063454 023452 007517
0000040 017271 134535 142030 013050 012277 125503 031065 051217
0000060 056731 050633 032407 107007 147613 146443 116261 044577


Well, you see that's a problem because I'm reasonably certain that the original document, which the lawyer who dictated it assured me would have a minimum forty year life, isn't electronically accessible to the people it went to either.

I picked this example in part because I happen to have it but mainly because it's a document about identity that was used to support authorizing my access to a "sensitive" applications environment - and that's the core of the issue I want to talk about this week: the "nexus" between identification, document management, and authorization.

If you're responsible for business data and authorize some list of people to have access to that data, then you want the system delivering that access to first ensure that anyone trying to get at the data is on that list of authorized users. That's obvious, right? but what isn't obvious is that this is a two step process in which it makes sense to impose a strong separation between the parts.

Step one is put a name on the list, and step two is to use that list to verify someone's right to access that data or application when he or she tries to login.

In practice the initial authorization usually involves a human being's interpretation of someone's real history with the organization, but the rights verification part is almost always done with a pseudonymous userid like pmurph.

Look at step one in the context of government security efforts like passport control and what you see is a massive problem in document integrity and accessibility management - thus the fact that the people who issue my Canadian passport almost certainly can't read my security clearance documentation suggests that the process may not be as well thought out and managed as some might wish.

Politically I subscribe to the view that less government, even if achieved through inefficiency, is better government. As a result you might reasonably expect me to applaud their inability to maintain document integrity and accessibility over both organizational boundaries and longer periods, but in fact I don't because enforcing a clear separation between the two steps in the process would offer an effective solution to the real problems government tries to addres via identity management without compromising anyone's privacy.

The identity management solutions being sold to governments today, whether expressed as national ID cards or as electronic passports, are all variations on corporate identity management solutions. In other words, they're aimed at step two -comparing an id being presented to an authorized list- with governments artificially gluing on step one -establishing authorization- simply by not recognizing the distinction.

Recognize the distinction and it becomes obvious that your passport, or national identity card, could become much more like a simple userid - and much less of a threat to privacy and your rights as a human being. Equally importantly, recognizing the separation would allow the processes of issuing and controlling these things to be greatly simplified and thus made more effective as controls against criminal and other inappropriate activities.

Doing that would require two specific technologies. The first of these would enable a standard approach to document storage and thus provide the informational basis for an efficient way to carry out the step one processes: authenticating someone's rights and placing the resulting authorization id on a list. The second would focus on the authorization token replacing identification documentation for step two.

That token would not carry identification information, and neither would the authorized list against which it gets compared when presented. The only information the customs agent, airline representative, or traffic cop gets when you present it is the information needed: you're one of the good guys, or you're not.

Of course if you're not, other questions become legitimate - but only once you initiate matters by attempting to do something you're not authorized to do, and that's where effectiveness in document management becomes important again because authorizations can be changed, or other appropriate actions taken, only if the right information is available and can be trusted.

In the short term this change would require a revolution in official thinking and isn't going to happen, but in the long term both the separation of authorization from identity and the required standardization in document management are inevitable -and information technology, the stuff you and I do, will lead the way.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues. Draft Blog Entries

% fortune -ae paul murphy

Identity Management and Documentation

monday: id card - basic nov22_05.html: homerization nov23_05.html: google and openoffice docs nov24_05.html: min docu solution nov25_05.htyml ?

I don't think it does - but governments and their agencies always do. A few years ago, for example, I was driving from Calgary to Edmonton at about 2:00 AM when a crazy in a large SUV came zooming up from behind at a rate considerably more illegal than what I was doing, turned on his high beams, and parked half a car length behind me even after a lane change. He didn't like my strategy of holding my brake lights on and slowing right down -but then he disappeared behind me, only to reappear doing it to someone else, and then someone else again in a recurring pattern of obviously intentional harrasement.

So I called the RCMP in Red Deer - but they weren't at all interested in the bad guy's plate number, vehicle type, or behavior: what they wanted was my phone number, home address, license number, and the correct spelling of my last name - all of which I'm quite sure he had already obtained via a caller id based file lookup.

"Procedure," of course, but stupid beyond belief. Unfortunately, governments are like that. They're all talking about things like issuing national identity cards (to go with the passports, social insurance, licensing, and other nationally certified identities they already lose track of) but none of them seem to be asking the obvious question: what difference would doing it "right" this time make?

In IT, identity management is fundamentally about authorization and authentication, but whether Joe Blow is known as Jane Doe or Harry Smith really doesn't make the slightest difference -so why would it make a difference in the national government context? The answer they give, of course, is that the name is a label for a lifetime behavioral record, so when the functionary sees Jane Doe on the identity card, he can pull up the right record to see what Jane has "been about" in her life to this point.

It's a good answer in that it seems reasonable and cuts off discussion: but it's reflexive rather than thought out and probably wrong on both moral and practical grounds. SZZ But that leads to a problem: in the vast majority of cases, Jane's record is none of the functionary's business. What the functionary needs to know is much simpler: is Jane authorized to enter the country? yes, or No. Get a discount on her driver's license? Yes, or No.

Look again at the solutions being proposed - everything from smart cards to RFID passports - and you'll see these are all generalizations of corporate identity solutions being sold as solutions to a problem they fundamentally don't fit. And the reason they don't fit isn't that there's anything wrong with the corporate solutions, it's the records retrieval agenda thats being glued on to fit the buyer's agenda that's the problem.

Western governments already track their citizens from birth certificate to death certificate -it's a reflex, not a thought out policy and both fundamentally inappropriate in a democracy and almost guaranteed to turn any attempted implementation into yet another nationally expensive -and continuing- failure.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.