Radovan Semančík's Weblog

The Web and especially OpenID has yet to learn important lesson: nothing is permanent. Will Norris mentions it in his post. To make his long story short, the problem is that OpenID relies on DNS and DNS names can be reassigned. With change of control of DNS name the control of associated OpenID identifier is changed as well. Therefore a user may be required to pay for a domain that he does not want any longer just to avoid losing control over the OpenID identifier. The root of the problem is that DNS is not really an identification mechanism, but rather an addressing mechanism. OpenID design does not account for that.

The purpose of address is to locate an object, therefore it contains information about object's location - directly or indirectly. Address must change if the location of the object changes. DNS is using a level of indirection to reduce the number of changes needed if object location changes, but it does not reduce them to zero. You may be forced to pay for a domain forever if you want to make DNS name a permanent identifier - assuming you can do that at all. For example the rules for sk top-level domain will force you to yield your domain in case someone registers a trademark that is the same as your existing domain name. Therefore making DNS name persistent may be quite costly. DNS domain is an address. Get over it.

The purpose of identifier is to distinguish the object from other similar objects. Well-designed identifiers does not need to change. The identifier may identify an object that does not exist any longer, but it should never identify a different object. Think of ANS.1 OIDs, ISBNs or similar identifiers. For identifiers to be efficient their assignment should be very cheap and maintenance must be extremely cheap or entirely free.

It is not wrong per se to use address in your system. But it is a mistake to use an address and assume that it has properties of identifier. It is a failure to assume that address will not change - almost as serious a mistake as assumption that identifier can always be resolved.

Technorati Tags: identity OpenID identifier address

Kim Cameron recently posted a paper "Proposal for a Common Identity Framework: A User-Centric Identity Metasystem". Although this paper is hard to read at places, it brings up some interesting points. It somehow formalizes the "Identity Metasystem" in form of a set of abstract services, which I understand as (possibly unconscious) attempt at creating a abstract architectural layer for identity services, one of the shearing layers in software architecture.

The paper suffers from inconsistent terminology and its use through the paper. If frequently fails to distinguish cyberspace entities and realspace entities. It also seems to assume a binary view of trust: something is either "in doubt" (in claims) or becomes a "fact". I consider this binary view to be one of the worst fallacies of most current identity architectures and systems.

However I believe that the worst drawback of the proposed architecture is that it does not reflect one of the most important requirement for Internet-scale distributed systems: the requirement to support positive Network Effect. If the network node can communicate with each other directly, the value of the network is proportional to the square of the number of nodes. However, if communication is limited to channels, the value of the network is significantly limited by the number of channels. The value of such channelized network grows much slower. In the identity space you can see an example of this in the PKI for qualified digital signatures. This PKI is being constructed for almost 10 years, received substantial investments both for research and implementation, it was frequently stated that there is a need for such a mechanism. And still the technology acceptance is very low. May the limitation to channel identification through the accredited certificate authority channels be one of the reasons for PKI failure?

The paper proposes or assumes similar channelization of the Identity Metasystem: the contractual agreements between claims providers. I don't believe it is feasible to consider contractual agreements between network nodes in Internet-scale systems. There are just too many connections, combinations of interactions. How many claims providers there could be on the Internet? 10? That's clear monopolization. 100? That's approximately one per country. I think that there will be much more of them. Probably one per an organization. That means millions. And that means millions of millions of contractual agreements. That's clearly unfeasible. There would need to be trusted third parties that will "bridge" gaps between organizational claims providers. And there we are back in the PKI world which haven't demonstrated any substantial success on the Internet during a decade of well-funded efforts.

I think that the primary problem is in the binary view of the "trust". The information in the cyberspace cannot be considered to be "facts", but rather an opinion of its author. No information is absolutely reliable and all the information (at least in cyberspace) is subjective. Therefore there may not be a strict need for a contract between parties, but rather a method of a proper risk management and information reliability evaluation. Any "identity" system needs to be firmly based on a "trust" infrastructure between nodes, between resources, cyberspace entities. And I don't think that a "trust" infrastructure based on a binary view would be feasible on the Internet scale.

Technorati Tags: identity metasystem trust PKI security

Users do not authenticate themselves to web applications. Users pass their password to their workstation (or any terminal device) that will pass it to the browser which will in turn pass it to the web application. The application does not interact with the user, it interacts with a browser software installed on a machine that is (maybe) used by human being. I have described that long ago in a persona model. Now Fulup Ar Foll mentions similar thing in this quite interesting interview. That's good. At least one more person is having the same idea. Maybe we are getting somewhere.

You may ask what is the difference? Authenticating user or user's computer or whatever? The user cannot be sure that his computer or mobile device is operating as expected. And well, let's admit that many people have no idea what that damed machine is doing. It is easy to make a mistake and send your password to a wrong site (phishing). It is difficult to defend against viruses. And we are damned lucky that vast majority of the viruses are pretty harmless things. Computer or mobile device can be stolen, ale your persona may be stolen as well. Just admit it, the device you are using to interact with the cyberspace is just not secure.

More and more important services are getting on-line. They assume that the entity that is providing credentials is really a human. But it may not be the case. It is much safer to think in terms of "digital persona" than "living person" when it comes to the design of authentication systems.

And that also means that the entire field that proudly calls itself "user-centric identity" is in fact a bunch of machine-centric solution.

During last few months there were quite simple but very effective phishing attempts at twitter, deviantART and maybe also other social sites. The phishers spoofed login page of twitter (or deviantART). They sent out a catchy messages along the lines of "funny blog about you" or "I have seen your photos on this blog". These messages contained link to the spoofed login page that phished user passwords. Phished credentials were used to spread the message further, creating an avalanche effect.

This approach was efficient because the messages were apparently coming from trusted friends. Why would a good of friend of mine send me to a phishing page? Because he was phished just a minute before! Simple, but efficient. My estimate is that a significant portion of users that were on-line fell in this trap. I was on-line on deviantART when this happened. As far as I know nobody of the people that I watch detected that the login page was spoofed. They have only detected the consequences: that someone is sending out strange messages using their account.

I have immediately noticed that the login page was spoofed. The spoofed page was slightly different than the normal login page. But the primary reason that I was alerted was that the page was out of context. I should be seeing a blog that stole my photos, not a login page. I haven't logged out and the session should not expire in such a short time. An immediate look at the URL bar confirmed my suspicion.

This specific phishing attempt was not very sophisticated. But if the phisher tries a more subtle tactics next time, I may become a victim as well. Such a tactic will probably display a login page in the correct context, where it is expected. Even the most cautious users may automatically enter the credentials without any suspicion (you just cannot watch URL bar all the time). Now it is quite difficult to construct a phishing message that would direct you to a login page in the right context. The correct context for entering a password is at the start of interaction with the site. But the world is changing ...

Using OAuth it is usual to enter your username and password almost any time during the interaction with a site. OAuth will normally redirect user to your trusted site that stores his data - to request an authorization to use the data. But that usually results in asking user to log in. It may be quite easy for a phisher to simulate that flow and to spoof the login page of the legitimate page. OAuth in fact trains users how to get phished easily by making the normal use case similar to the phishing case.

This problem is amplified when OAuth is combined with OpenID. It is not a big deal if a twitter password gets phished. But if a key to the OpenID kingdom is phished, that may be entirely different story. OAuth-OpenID combination is increasing the exposed surface as well as impact: there are more places that user may be phished and the phished credentials are more valuable.

I can understand that neither OAuth nor OpenID created the primary problem. But the use of OAuth and OpenID is amplifying existing problems. Therefore instead of increasing the privacy and security of users the use of these mechanisms may if fact have exactly the opposite effect.

There is a reputation discussion all over the blogsphere. The question is simple: What attributes should be influenced by reputation and what should not?

The answer is simple as well: The question just does not make sense. I will try to explain that, but it needs a bit of philosophical background.

Information is subjective. If I say I'm dependable, what I'm really doing is expressing my opinion about my dependability. When my customers say that I'm dependable, they are expressing their opinion about me. When my dear competition say it's not all that good about me, they are expressing their opinion. It is quite obvious that some abstract concept such as dependability cannot be objectively measured. And therefore it should be somehow (read: magically) determined by combining several values from several sources. That mechanism is now part of the "reputation" buzzword.

But what happens if I say I'm 195cm tall? My height is an objective fact. That should be somehow different from the abstract concept of dependability, shouldn't it? No, it shouldn't. If I say I'm 195cm tall I'm expressing my opinion about my height. How can you make sure that information is true? You can send someone here to measure my height, and he will get the same number. But if he publishes that on the Internet, it's just his opinion on my height. Both of us can lie and I may in fact be only 150cm tall. Or we can both use broken tape measure. Who knows? Who can be sure?

Any information is only as good as is the source it comes from. It does not matter if it is information about dependability or height. There may be objective facts, but information is always subjective. Even if it tells about objective facts.

Therefore all that havoc about reputation just doesn't make sense. The question is not "What attributes should be influenced by reputation?" The question is "How we are going to determine trustworthiness of any information?" Whether it is dependability or height, the mechanism should be the same.

Identity is mainstream.

Lot of ill-advised identity technologies are roaming around. Technologies that does not really solve anything and are just technology toys. Or technologies that solve just a routing of revenue stream, not the real problems of users. I wonder if evolution can handle that and how fast will these technological abominations die. There is couple of corpses already. And more will (hopefully) follow. I hope that evolution can eventually balance this.

Lots of self-established identity experts are appearing. People that think that identity is all about technology. Thinking that reading few identity stories in popular press is enough to become an expert. Believing that if they would follow the hype they will surely get the best of that identity thing, whatever that may be. They obviously does not have a bit of viable experience in the area. People that re-invent the invented just because few hours in the library can be saved by few months in the laboratory. People that implement useless work-around mechanisms instead of focusing on the core of the problem. People that deploy technology just because it comes in the box that has the right colors on it. I wonder if evolution can handle this as well. But I'm afraid it cannot. These guys are usually well disguised as serious engineers. We know all too well that camouflage is usually a good survival strategy.

Business as usual. Identity definitely is mainstream now. All the obvious symptoms are there.

I see that over and over again. Recently it has appeared here. So let's make it clear:

Identity is NOT about identification

Identity is all about sharing the data. Identifiers may or may not be part of that sharing. Identifiers are just ordinary piece of information with a purpose to link objects. It not special to "identity" in any way. If you see "identity" just as a identification you are missing the crucial point.

I believe that the "user-centric identity", federation, SOA-based "identity" mechanisms, social web and VRM are all the same. Not similar, but same. They all solve the problems of controlled data-sharing somehow related to people. Data sharing, that's what it is. And unless all the "identity" and VRM and "social" folks understand that they are in the same business, we will not get anywhere.

I like it how everybody pretends that they know what "identity" means ... while nobody really knows. There is no viable definition what "identity" means when it comes to the computers.

What does Internet Single Sign-On systems really solve? Is all this upset (caused especially by OpenID) good for anything? Let's summarize the benefits and drawbacks:

• Benefit: I do not need to remember many passwords. I just long in once and then any site I'll visit will recognize me.
• Drawback: My OpenID provider may not be recognized by all relying parties. Even if the situation now is in the naive state that everybody "trusts" everybody, it cannot be sustained. The providers will differentiate. Therefore I will need to maintain several accounts with several identity providers anyway.
• Benefit: Still better to have several accounts than thousands of them.
• Drawback: Even if I have SSO, I still need to click on "log me in using OpenID" link on a target site. Therefore the user experience is still the same as having a browser remember the password for me. And the browser still needs to remember your OpenID URL to have it "one click" experience.
• Improvement: This can be improved by some kind of identity provider auto-discovery and automatically log the user in. However, there are dangers ...
• Drawback: If a website can make my browser to automatically log me in, the same thing can be done by a script running in my browser. The impact of cross-site scripting exploits will get worse. Much worse. If my back would accept OpenID-based SSO with an option for automatic login, clever attacker can take all my money and I will not even notice that it happened. Phishing may get to the next level ... maybe we will get "phishing trawlers"?
• Benefit: Some SSO systems may transfer attributes from identity provider to relying party. That may be useful. I will not need to always make sure that my billing address that is remembered by an electronic shop is correct. I will not need to always look up my ZIP number (as I cannot remember it). That can be a real benefit.

My assessment is that Web SSO systems that just do SSO are useless. Absolutely useless. Dangerous even. I think that for this stuff to work reliably and securely the browser needs to understand the security protocols. The browser needs to present appropriate user interface, such interface that cannot be feinted by a script. And most of all: the SSO itself is a next-to-none benefit for users. Add attributes to that and it may gain some attractiveness.

Do not take this as an endorsement of CardSpace. While CardSpace may solve some of the above issues, it has its own set of problems. But I will keep that for later.

The European Court of Human Rights has ordered the Finnish government to pay out €34,000 because it failed to protect a citizen's personal data. One data protection expert said that the case creates a vital link between data security and human rights.

The Court made its ruling based on Article 8 of the European Convention on Human Rights, which guarantees every citizen the right to a private life. It said that it was uncontested that the confidentiality of medical records is a vital component of a private life.

The Court ruled that public bodies and governments will fall foul of that Convention if they fail to keep data private that should be kept private.

The woman in the case did not have to show a wilful publishing or release of data, it said. A failure to keep it secure was enough to breach the Convention.

(Source out-law.com via Emergent Chaos)

I wonder how is this going to change the economics of government data protection. I hope that this ruling can achieve what a horde of legislation, government-initiatives-in-good-faith and other (more "commercially-oriented") government initiatives failed to achieve.

And if my hopes will not be fulfilled, at least I know to whom should I appeal in case my privacy will be invaded. I'm glad that I live in Europe.

Not that long ago W3C TAG recommended to vote againts XRI Syntax and XRI Resolution specifications to become OASIS standards. The reason given by the W3C TAG was ridiculous:

We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.

Anyone with some common sense and the knowledge of both Web Architecture and XRI specs can clearly see that XRI specifications are as immature as Web Architecture is broken. Childish flamewars like this will not bring any good for any of them. Paul Madsen summarized that in his usual brilliant style.

While the follow-up explanation from W3C member Dave Orchard raises few good points, some thoughts are quite extreme:

Protocol independence appears to be a bug on the web, not a feature.

Statements like this one must alert any experienced software architect. Has the world (wide web) really went nuts?

I've realized I have plenty of these already. So one more does not really matter. And this one is almost as useless as my twitter, orkut, facebook and myspace accounts. Almost.

For all the fans of Buzzword 2.0

Recent gossip has it that HP and BMC are leaving the Identity Management arena. Interesting. It doesn't look like there is a business decline in the Identity Management segment. Rather it looks like a slow continual growth (disturbed only the the Identity Superheros that claim to solve all the problems). Then why are these two companies pulling back?

I can only speculate here. And my speculation is that the reasons may be related to the hidden complexity of Identity Management deployments. It is trivial to Identity Management software and do some basic configuration. But that's only the beginning of the real Enterprise Identity Management project. The real fun follows after that: using organizational structure, aligning the processes, building up roles, ...

The Identity Management project is a multi-year venture. It is not only the deployment of software. It is rather an architectural change. A paradigm shift. Whatever you slice the project to fit into a year's budget, you cannot change the very nature of it.

That may be the reason why usual quick-turnaround sell-install-invoice integration-wannabe project approaches fail. The IdM project executed in the proper way is not really a high-profit business opportunity for software vendors. Unless they sell expensive professional services along with the solution, which usually makes the cost unjustifiable and the results inconclusive. The reason is in motivation. Vendor's motivation is to sell the product, not to solve customer's problem. My opinion is that vendors by themselves cannot solve practical problems of Identity Management.

My solution? Find a proper partner for the project. Either a big consultation company or a small specialized company (Note: I have vested interest in this option). The big company may already know a lot about your system and can approach the problem from several angles. Therefore it can solve a lot of related problems, both technical and business. They have the manpower. But the cost is invariably high (or the solution invariably poor). Small specialized company will focus on a small set of problems, usually providing good results in a specific area. But the scope of the small company's solution is always limited.

... I wonder what will be the approach of IBM, Oracle, Sun and other IdM vendors. Will they make the same mistake?

Dear Americans.

It looks like you somehow neglected even the basic security best practice in your business lives. You are using SSN and mother's maiden names as (presumably secret) authentication credentials. You are using it for credit applications, opening bank accounts and all sorts of other activities that can affect your financial situation and/or reputation.

When you are creating a free e-mail or social network account, would you put SSN or mother's maiden name as a password? You would not! Why? Because it is so trivial to find these information out for anyone with a bit of motivation to do so. Yet your companies use these publicly available data to authenticate customers. And you still wonder that identity theft is flourishing?

Your very own Whitfield Diffie made it clear: "A secret that cannot be readily changed should be regarded as a vulnerability". Can readily you change your SSN or mother's maiden name?

You still fight against any kind of authentication mechanism that might make your life easier. Is password the best security mechanism you can imagine? I do not know of any bank in Slovakia that does not have two-factor authentication for Internet banking access. I do not know of any organization here that would give you any sensitive personal data while you present only a name and SSN. You cannot get a loan of any substantial value in Slovakia without showing up personally and presenting a valid ID card. I think that having an ID card protecting my money and reputation is a feature, not a loss of any of my liberties. Yes, the theft is still possible, as the authentication credentials or ID card can be stolen and modified or forged entirely. But that's not an easy process and the theft is therefore quite limited.

You still talk about the lack of privacy and the rise of identity theft but you are failing to introduce any effective legislation. We have the EU directive on personal data protection, which regulates the collection and especially the use of personal information. The directive is far from perfect, but even in its current form is better than what you have - almost nothing. On the other hand you make what you can to make identity theft easier: you allow anyone to get a credit report of anyone other (by paying some small amount of money), you make the databases containing personal data public. You even have (legal) business built on the concept of harvesting that data for anyone to easily use (if he can pay for it).

The technology will not solve these problems. No amount of OpenID, CardSpace, SAML or any other marketing brochures and presentations can solve the problems in society and in legislation. Please correct the problem at its root and do not try to cover it by technology.

Do you care what's happening recently (or not that recently)?

Microsoft has acquired Stefan Brands ... uh, sorry ... Credentica. And since that you can notice increased frequency of words U-Prove and anonymous credentials in Kim Cameron's blog.

SXIP was acquired by Ping Identity. I hope that step will not lead Ping astray. Oh BTW, talking about Ping: If you missed the Great Identity Battle of Thousands Against Few, go check it out. It is worth it.

Kim Cameron and Dave Kearns are arguing about the meaning of word metadirectory. The argument is long and not really interesting. Let's skip that.

Some bloggers are discussing the Identity Hub and Identity Bus concepts. Or would it be better to say buzzwords? It has all the symptoms: nobody really knows what does it mean, it sounds great and it does not really works. Hmmm, we are creating buzzwords. Maybe that means Identity is transitioning from the Geek Phase to the Hype Phase?

OpenID is gaining acceptance. That's the most unfortunate but not unexpected trend.

A plastic foil that can be used to impersonate a German minister was published. I think that's a great demonstration of the limitations of biometrics that seems to be quite obvious to a few but almost invisible to the majority (including decision-makers).

An excellent (and short) summarization of Identity projects was published by Jeff Bohren. I haven't heard anything more appropriate in years. My one of my colleagues working on IdM projects had a remark that he zcould add a few more sub-stages.

European Identity Conference is just about to happen in Munich. Although there are few big names and it happens almost around the corner from my home, I feel no motivation to go there.

... well, yet another month in our little Identity Town.

For a while I've got the impression that I was the only one that can see problems in OpenID. And I'm happy that it is not true. I just was out of the blogsphere for too long. In last days I've tried to catch up on the recent (approx. last year) blog posts ...

Stefan Brands post "The problem(s) with OpenID" lists a lot of problems of OpenID. It is a bit aggressive and it it looks to me that he is unnecessarily hard in some cases. He also provides marketing bits for Credentica inside the post, which I do not like. But generally I must agree with Stefan as I have the same feeling about OpenID security and privacy features.

David Recordon tries to respond in his "Stefan Chooses to Take the "Fox News" Approach to OpenID Blogging" post. He accuses Stefan of spreading FUD, but he does not provide much himself. David's post is written in the open-source marketing style which I happen to hate. I must agree that David has some points (e.g. referring to OpenID work in progress), but he does not have the solution or the answers to all Stefans concerns for the matter.

And then there is Kim Cameron. In his post titled "We need a spectrum" we tries to justify OpenID existence as a simple protocol for Internet SSO. I do agree that a trivial protocol is needed, at least for migration to some real solution. But it does not justify why it has to be OpenID in its current state.

My conclusion about OpenID is still the same. OpenID design is broken. Fundamentally. That's the bad news. The even worse news is that it will probably gain acceptance anyway. Some market demand is there and if there will be no viable alternatives (at "almost free" price level), OpenID can succeed. But it will be marketing success, not a technical one. We have seen that happen too many times in history (with Microsoft being the most obvious example).

But there is a good news as well. I think that OpenID can be fixed to provide simple (but sufficiently reliable) SSO system for low-value applications. But it will require substantial work (read: "complete re-work"). My recommendation for OpenID guys is to stop marketing nonsense and go back to drawing boards.

I quite wonder when Estonians will try to use OpenID for e-government. However foolish it may be, I think that they will try. They do this kind of things.