Comments: To live in interesting times - open Identity systems

The first part of the post is most probably known to readers of this blog: the second part is a question.

Imagine that a law is passed that makes it compulsory for the key to your house to be the same as the key to your car; thus, at a stroke, the key has become more valuable, since it enables access to more property. The law makers continue by making it compulsory for the key that gives you access to your house and car, now has to be the same key that allows access to your bank account. The value of the key massively increases; since, if it is stolen, the thief has access to your house, car, and bank account. Readers of this blog will realise that the key in the preceding description is an analogy of identity and that the scenario depicts the first of the two ss's (Stupidity and Sovereignty) of identity politics. The other S, sovereignty, being that the state demands the right to issue all keys. (We can wax on about pass laws, an arbitrary means of discrimination and the incredible evil that lurks therein but lets not ...).

Instead, I want to ask a question pertaining to the first, S, viz stupidity. If the threatened legislation comes to pass, will the legislative body accept all liabilities of loss from identity theft? Obviously, not ... but, are they painting themselves into a corner where they may end up being forced to accept the consequences of jeopardising the property of those that are on the receiving end of these laws? (I'm thinking along the lines of tort laws etc ... Or is this just wishful thinking nonsense?).

Posted by Darren at May 21, 2005 08:26 AM

there is a somewhat related issue that could be raised regarding person-centric tokens vis-a-vis institutional-centric issued tokens. the current infrastructure tends to be institutional-centric and there is a different, unique token (actually potentially several) per institution. periodically these are referred to as identity tokens ... but being institutionally-centric they more often actually are autentication tokens (a one-to-one mapping for a specific domain).

the opposite extreme is if institutional-centric tokens take off and you are issued one or more in lieu of every pin/password, every physical key, and every magstripe card ... that you currently possesss or utilize. this potentially results in at least scores of tokens per individual (if not hundreds).

sort of the opposite would be person-centric token paradogm. a person would have one or more tokens that they own ... and they would have the discression to register the token of their choice with institutions as the authentication token for interactions with that institution (transactions, access, open the door, etc).

most institutional interactions are looking for a one-to-one mapping for authentication purposes (are you the authorized individual for performing transactions on a specific account ... or are you an authorized person allowed to open a specific door).

a lot of confusion occurs when identification is mistaken for authentication. authentication wants to know if you are authorized to do something .... w/o needing to actually pick out what person from possibly millions you might actually happen to be (identification). i can assert that i authorized to use a certain account or open a certain door and provide authentication information to back up that assertion. that doesn't require me to identity myself ... just to authenticate myself.

this was one of the mistakes of the x.509 identity certificates from the early 90s. part of the issue was that certification authorities weren't confident that they could predict what information about you that might be required by some unknown, random relying-party at some point in the future. so there was a tendency to believe that x.509 identity certificates should be grossly overloaded with excessive amounts of personal information.

some number of institutions in the mid-90s came to the realization that x.509 identity certificiates, grossly overloaded with excessive amounts of personal information represented significant liability and privacy issues. at that point you saw some retrenchment into relying-party-only certificates ... basically containing some sort of index or key that could be used to lookup a specific record in a database (aka an account number or a userid) ... which was, in turn bound to a public key. however, a typical relying-party interaction involved some sort of digitally signed message that also contained the record index. It was at this point that you could demonstrate that relying-party-only certificates were redundant and superfluous since the relying-party could retrieve the indicated record and utilize the onfile public key for verifying the digital signature w/o ever having to resort to use of the digital certificate.

numerous past postings on relying-party-only certificates

a couple past postings on person/institutional centric issues: maximize best case, worst case, or average case? (TCPA) Maximum RAM and ROM for smartcards Security via hardware?

Posted by Lynn Wheeler at May 21, 2005 10:33 AM

Hello iang,

did you see all the recent press on microsofts move into the identity market?,1995,1817451,00.asp

its very bizarre, and read like it was some sort of philosophical bantering, but seemed to have no substance whatsoever. In other words, after reading through all their PR I came away with no information and no real clear idea about how they are going to implement whatever it is they are promoting.

A friend tells me this is the first move to combine .passprt with the credit card and a big rollout of subscription based software which I guess is something like inet2's hub structure. So in the future one could subscribe to word and use it online for a monthly fee and the id system would be all intermingled with the operating system.

i can't believe i am writing these words. That scares the crap out of me.

This is all one needs to know:

I don't know, but I get this strange feeling this departure will somehow cripple microsoft.

Posted by Gordon at May 21, 2005 07:56 PM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x55b30e720b48) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.