Preaching to the converted again, but we all know that the critical flaw in the Identity push is that there isn't One True Identity. If we assume Identity is One and True in our designs, our systems or our society, this will come back to haunt us.
Now, in response to wide-scale evidence of failure of Identity-centric systems, there are emerging signs of people starting to realise that this is one of the foundations of America's Crisis of Identity. Here's one from an influential report by The Royal Academy of Engineering:
One of the issues that Dilemmas of Privacy and Surveillance - challenges of technological change looks at is how we can buy ordinary goods and services without having to prove who we are. For many electronic transactions, a name or identity is not needed; just assurance that we are old enough or that we have the money to pay. In short, authorisation, not identification should be all that is required. Services for travel and shopping can be designed to maintain privacy by allowing people to buy goods and use public transport anonymously. "It should be possible to sign up for a loyalty card without having to register it to a particular individual - consumers should be able to decide what information is collected about them," says Professor Nigel Gilbert, Chairman of the Academy working group that produced the report. "We have supermarkets collecting data on our shopping habits and also offering life insurance services. What will they be able to do in 20 years' time, knowing how many donuts we have bought?"
One of the technical people who know this -- that names and identity are no good for systems design -- is Gunnar Peterson. He points to someone called Mike who jumped on the Bandwagon:
Over the last few weeks, I’ve made an effort to become an OpenID power user. OK, ok, so maybe I’m just responding to the sound and the fury over this deceptively simple technology. But OpenID caught my imagination because it’s ostensibly something I get to own for myself—not something handed to me by the federal-industrial complex.
So, centralised, big-company naming schemes are bad, right? Therefore we need an open source, decentralised, every-ones-in-control alternative, right?
But don’t get me wrong: OpenID isn’t the problem here.
Bite the bullet. Copying the bad guy won't work.
OpenID simply calls into sharp focus something I’ve believed for years. It’s a kind of axiom, so I’d like to give it a name. I’ll call it, “identifiers.axiom.neunmike’s.axiomproxy.info”—that way you can easily refer to it unambiguously from anywhere. Here it is:There are no identifiers, only attributesNames are slippery. Most people have many more than one legal name, none of which are unique. They also have several dozen nicknames. There’s no practical way to get any of these every-day-use names onto a global namespace. And what’s a name after all but a synthetic attribute—a foreign key that we hope the receiving party stores somewhere so we can remember them later? Names are invaluable communication aids, but they have little to do with recognition, which is what’s at issue in most identity management contexts. Biologically, creatures don’t recognize others based on names but rather the confluence of attributes appearing within a certain context.
Right. And the unavoidable conclusion is that names don't cut it. Names are wrong for the job. What is right for the job is ... something else, but let's settle for that simple message.
"Names are no good." We need a catchy meme to invade the mindspace of the public on this one. Mike suggests:
Lao Tzu (who goes by several dozen names) had a pretty good post on this idea over 2000 years ago. In a section called “Ineffability,” he writes:The Way that can be told of is not an Unvarying Way;
The names that can be named are not unvarying names.
It was from the Nameless that Heaven and Earth sprang;
The named is but the mother that rears the ten thousand creatures, each after its kind. (chap. 1, tr. Waley)
Not that it is encouraging to know that this bug has been in existance for as long as history recorded names ... So the new European project of collecting info so as to breach nyms and find our One True Identity should come as no surprise:
In privacy-conscious Europe, some governments seek stricter rules on online anonymityFebruary 23, 2007 - 4:20AM
The cloak of online anonymity could be lifted in parts of Europe as some governments seek to make it easier to identify people who use fake names to set up e-mail accounts and Web sites.
The German and Dutch governments have taken the lead, writing proposals that would make the use of false or fake information illegal in opening a Web-based e-mail account and require phone companies to save detailed records, including when customers make calls, where and to whom.
The measures, none of which have yet become law, would not outlaw having false or misleading names on e-mail or other Internet addresses _ only providing false information to Internet service providers.
The aim, analysts say, is to make it easier for law enforcement officials to get information when they investigate crimes or terrorist attacks.
The Dutch! Tell me it ain't so! On the good news front, there is no truth to the rumour that privacy activists will be out of a job due to lack of interest.
Posted by iang at April 2, 2007 07:09 PM | TrackBackso can some of this be merged into a comprehensive paradigm for the public ... which also has some spill over from a number of other recent threads
so in this (and other) thread:
http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm26.htm#49 Governance of anonymous financial services
i claimed that the work on x9.59 financial standard protocol in the mid-90s ... attempted to take into account some sort of EU directive about financial transactions at point-of-sale should be as anonymous as cash.
the x9a10 financial standard working group, in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... resulting in x9.59
http://www.garlic.com/~lynn/x959.html#x959
we claimed that x9.59 was privacy agnostic ... the only thing exposed at retail point-of-sale was an account number. It was then up to various jurisdictions whether there was any association/binding for the account number. In many jurisdications there are "know you customer" requirements that at some point requires a binding between an account number and an individual ... at least for credit & debit transactions. "stored-value" account numbers are still allowed to be anonomous in many jurisdications ... all of these can be supported by a common x9.59 protocol.
for even more drift
http://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks makes the news
http://www.garlic.com/~lynn/aadsm26.htm#50 DNSSEC to be strangled at birth
http://www.garlic.com/~lynn/2007q.html#58 Can SSL sessions be compromised
http://www.garlic.com/~lynn/2007q.html#60 Can SSL sessions be compromized
part of the issue is that how an entity is referred to (identification) and and what trust, privileges and permissions might be granted that entity are totally different operations. It may be possible to have a single, unique method of referring to an entity ... but that would never carry with it the sense of trust/privileges/permissions which are nominaly extremely context sensitive. This has been one of the places that "digital certificates" have frequently strayed into dangerous waters ... attempting to bolix up identification, authentication, trust, privileges, and permissions into one big mash.
so for slightly more drift, a scenario is to take address books, bookmarks, pgp key management, certificate management, etc ... and merge them all into a single (context specific) contact metaphor
rather than having to educate the public about what pgp keys are and certificates are ... they become a trust attribute related to contact. the downside is this somewhat commoditizes the whole PKI/certificate paradigm for the public. It is no longer a unique high-priced operation, it is significantly simplified as a contact attribute/characteristic (The CA is a "contact" and it can be trusted to provide some kinds of trusted information about other contacts).
(email) pgp key lookup and (URL) public key lookup at domain name system can appear as a single operation ... checking/validating the trust of a contact ... just another characteristic/attribute of contact.
the simplification is to take a single metaphor that the public is already used to dealing with and merging all the myriad of disparate operations into that single metaphor.
the claim can be made that trust hierarchy metaphors don't go over well with the public because it doesn't match how most of the public deal with the world.
however, it is fairly well established that the public can deal with the world within a contact metaphor ... where trust could then become an attribute within the contact metaphor (however, this may drastically minimize the heights that some institutions try to raise the status of trust to an extremely expensive independent paradigm).
the issue here is that the current SSL deployment fails to account for the large gap that exists in the publics' mind between webservers they think they are talking to and the URL that is used to contact those webservers (and SSL only provides a check on whether the webserver being talked to and the URL used to talk to the webserver are consistent).
contacts can provide a methaphor for the public ... that spans the gap. then there are two symbols that might be displayed for a URL ... one is its "trust" level symbol (from the contact repository) and the other is the padlock ... which is purely related to whether the transmission is being encrypted over the internet (i.e. the trust of the site and whether there is countermeasure for evesdropping are two independent characteristics).
Using consistent paradigm for all kinds of contacts ... then could also mean that there be a consistent metaphor/representation for trust and encryption across URLs, email, instant messages, etc.
contacts might include globally unique identifier ... but also have local, context specific trust, permissions, privileges, etc.
Posted by: Lynn Wheeler at April 8, 2007 05:47 AMLynn,
possibly, the notion of using a contact metaphor has been explored with the Bookmarks metaphor. The Petname concept has found some ease of implementation by merging with the Bookmarks in web browsers. And while Petnames are hard to describe, Bookmarks are easy.
When a user adds a bookmark, she names it how she wants. This becomes a petname to a resource, a local, user-defined-and-known private name. By adding a little crypto trickery (hash of the public key of the server) to the bookmarks database, then we create a secure petname and this can be used by a plugin to positively identify a repeat visit.
The concept works and works well (Petname Toolbar is a minimalist design, Trustbar also develops it further, and later generation toolbars have incorporated the idea). It requires a slight user training. One can criticise this on the basis that users don't do anything, and can't be trained at all; or one can say this is the best bang for buck that is currently available, for those who can be trained, if we assume that user information has to be tapped in some sense as a better or useful relationship.
Posted by: Iang at April 8, 2007 06:58 AMre:
http://www.garlic.com/~lynn/aadsm26.htm#51
contacts (with address books) have frequently added several additional optional information. making single consistent implementation for all activity might simplify the web experience ... driving all from a single interface/metaphor.
some address books already have automatic adding email addresses ... but without additional information ... however the additional fields are there. so an equivalent might do something equivalent for URLs ... possibly starting only with ones that claim HTTPS. then additional fields might be optionally selected.
in some ways this might be viewed as analogous operation to IE domains ... but instead of being driven off the (security) domain metaphor (and specifying URLs for each domain) ... it is driven off a (single) contact metaphor ... selecting what optional information gets specified for a URL.
optional information could be policy collections ... analogous to IE domains ... and/or specific permissions.
the difference is that it changes from a security metaphor to a (single, consistent) contact metaphor.
Getting a bank's URL loaded into contacts list with various online banking related attributes ... then can start to close the existing (SSL) gap between the server that a user thinks they are talking to and the URL.
This would make web-based banking operate somewhat more like the financial packages (quicken, money, etc) ... where registration of the financial institution for banking is required (even tho under the covers the financial packages may be using SSL for encryption).
Also more analogous to operation of earlier online banking operations that had installed software with the necessary contact information for doing direct dialed operation.
In the mid-90s, there were a couple of financial institution presentations that mentioned that existing online banking software required the financial institution to directly support something like 50-60 different flavors of modem drivers (different modem products, different operating systems, etc) as well as have call-center support for dailin operation.
Transition of online banking (or other online operations) to "Internet" was enormous savings for the institution since it effectively outsourced all the online gorp to an external organization ... and the external organization was able to amortize the online connectivity across a broad range of (additional) offerings/services to the consumer.
This consolidating of a large number of offerings/services was an enormous cost savings to individual institutions and enormous benefit to the consumer ... but also created a large ambiquity about who the consumer was dealing with at any specific point in time (and SSL doesn't actually provide complete end-to-end coverage eliminating all of that ambiquity).
The consumer direct registering of attributes for specific contact ... would somewhat close the gap (left by SSL). It also removes some of the disintermediation(?) that was introduced by the internet and 3rd party CAs between the consumer and the institutions that they were dealing with (compared to earlier "direct" online software packages)
The problem is that could also be viewed as eliminating the excuse for 3rd party CAs charging institutions for digital certificates ... since all that could be subsumed by user specifically loading institution contact information (and SSL changed to directly use loaded public key in the contact information).
Posted by: Lynn Wheeler at April 8, 2007 12:10 PMre:
http://www.garlic.com/~lynn/aadsm26.htm#51
http://www.garlic.com/~lynn/aadsm26.htm#52
to even further extend the topic drift ... in the 90s, i gave a couple conference talks as well as a graduate student seminar at ISI (USC) that included the IETF editors organization.
It basically was that there had been a lot of protocols migrated from circuit-based infrastructure to Internet (packet) operation ... w/o taking into account that there were a lot of implicit characteristics of the end-to-end circuit operation that were lost in the transition to packet operation.
When we were called in to consult with a small client/server startup about doing payment transactions on their server (with some technology they had called SSL ... and since has frequently come to be called electronic commerse), we had "sign-off" on the server to payment gateway implementation (I somewhat facetiously joke is the original SOA implementation).
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
One of the things we specified was extensive "compensating procedures" (and added business critical dataprocessing features) as part of moving financial transaction operation from circuit-based operation to packet-based operation. We also tried to suggest that some similar stuff should be implemented in the browser to server interface ... however we would get back responses like "that is too complicated" ... and since we only had sign-off on the server/gateway implementation we couldn't force it.
some recent posts mentioning the topic:
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
http://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?
http://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market
for other drift ... at the time I was doing some work with the RFC editor related to RFC index and consistency of information in STD1. That RFC index work continues and is at
http://www.garlic.com/~lynn/rfcietff.htm
recent article
IBM's Higgins project: anonymous authentication for all
http://arstechnica.com/news.ars/post/20070411-ibms-higgins-project-offers-anonymous-internet-logins.html
comments in another fora after an earlier item in Jan.
http://www.garlic.com/~lynn/aadsm26.htm#24 IBM donates new privacy tool to open-source Higgins