Sunday, May 06, 2007

Identity Pyramid, Slicing, reprise

I can only apologise for the general lack of a coherent message in my earlier post. I'll try again?

Why a pyramid? Well, at the top (or the bottom if you feel that identity in the digital domain is a hideously unstable and precariously balanced monster about to come crashing down on the poor denizens of e-wherever), we putatively have a means of identity that reliably proves you are who you claim to be, and, unless you are a mendacious statist control freak, there would only be an occasional requirement for this. At the other end (whichever you have chosen it to be) there is a regular and bulk requirement for non-identity (or minimal identity) tokens such as bus and event tickets (and the UV stamps night-clubs {used?} to mark you with so you could get back in without paying twice).

Why slicing? Because every organisation or system will have a variety of requirements for identification, verification & provisioning - this will require, if it is properly thought through (which it rarely, if ever, is), different levels of identity proof at different times.

We currently do not have, and I do not suspect we ever will, an effective strong identity solution, although government issued (or just backed) biometric solutions come somewhere vaguely near. (One reason that they will never come close is the inevitable weakness, or even corruption, at the point of issue. Aside from the general inability of governments everywhere, but particularly in the UK, to make complex technology projects function.) And any lower (or higher) layer solution that relies on some form of stronger ID at the point of initial issue will inherit the weaknesses of that identity solution (i.e. if I open a bank account with a fake passport, you cannot rely on my credit card as providing any form of identity guarantee. Not that you should any way - all you, or anybody else, should be relying on my credit card for is that the issuing bank will pay you. This is, in essence but slightly different form, the problem with the US SSN - an identifier being used outwith its design scope. Even if the designers got the security and practicality compromises properly matched, your misuse or abuse of the system introduces new vulnerabilities or just increases the attack surface.)

Another problem with strong identity systems is that the cost of implementing them even partially correctly is so high that, in order to justify the expenditure, they are evangelised into processes that don't need anything like that level of proof or, in fact, do not need any personal identification at all. And if the personal identification data is retained, stored and data-mined, you have just breezed in to what might be an egregious privacy breach.

Weak identity systems can be very effective. Take the purchase of alcohol. Does the vendor need to know your name? But have you ever seen a proof-of-age system which didn't have the kid's name on the card? A card with your photo, some anti-counterfeiting measures (and remember that the most likely attacker here is not some highly sophisticated criminal gang, it is a 16 year-old bloke) and "Over 18" or "Over 21" on it would actually be more than sufficient. And, of course, you can replace the photo with any other verification technology: signature (although, for some people, that could divulge your name), fingerprint, iris verification, DNA scan etc. All without your name on the card. (Ed notes: Of course, if you don't consider the criminal gang or other well-funded attacker, you will get dark side or, at least, significantly grey businesses churning out forged copies of your Boozer-Card TM by the bucket-load and flogging them online to the alcohol deprived but adolescent. :)

The message I am trying to get across, however ineptly, is that proper consideration needs to be given to the actual identification requirements within any system. If this doesn't happen at the outset, fraudulent abuse, waste of resource and breach of privacy are inevitable consequences of poorly designed identity processes - no matter how competent the specific implementation may be.

S-E

No comments:

 
HTTP Error 403: You are not authorised to access the file "\real_name_and_address.html" on this server.

(c) 'Surreptitious Evil' 2006 - 2013.