Tag Archives: Information Card

It is the life cycle that matters

Phil Hunt of Oracle makes a very good point about OpenID, Information Cards, and Passwords:

It all sounds wonderful. But Kim skips over the problem of how did he get that card? How was he originally authenticated when the card was issued?

Is the information card periodically refreshed or re-authenticated? If it lasts forever, what happens if the information is lost or copied? What happens if someone else is using his workstation? What happens when the Kim switches workstations? For example, Kim decides to check his CNNPolitics profile from a friend’s house? He’ll likely have obtain a new card. I suspect that will involve some form of authentication with his managed card provider. It is clear, while InfoCards may reduce the need for authentication and passwords it does not eliminate them.

Like Phil, I am also a big fan of Information Cards. OpenID, not so much. I would like to see something reduce the reliance on passwords regardless which technology ultimately gets adopted. But currently I don’t see either technology reducing the use of passwords for authentication for anything other than throw away use, like authentication to leave a comment on a blog.

The way provider support the entire life-cycle of the identity seems to always involve passwords at some point, regardless of support for OpenID, Information Cards, or even for that matter, SAML.


OpenID, Information Cards, and Passwords

The recent article by Randall Stross in the NYT is getting a lot of attention in the identisphere. Kim Cameron writes about it here, Axel Nennker writes about it here, and Dave Kearns writes about it here.

While this is a very good article about the issues involved in OpenID, Information Cards, and Passwords, there are a couple points, good and bad, that I would like to highlight:

I once felt ashamed about failing to follow best practices for password selection – but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them.

That would be the case even if we had done a better job of listening to instructions. Surveys show that we’ve remained stubbornly fond of perennial favorites like “password,” “123456” and “LetMeIn.” The underlying problem, however, isn’t their simplicity. It’s the log-on procedure itself, in which we land on a Web page, which may or may not be what it says it is, and type in a string of characters to authenticate our identity (or have our password manager insert the expected string on our behalf).

I couldn’t agree more. Perhaps no bit of outdated computer advice is more regularly given out than this. Experts continually tell us that to be safe we need overly complex passwords. All this does is force the user into bad security practices.

But there is another side to this that the article doesn’t mention. It doesn’t matter how secure the authentication is if the subsequent web session is not secure. If the session can be hijacked post authentication using cross-site scripting attacks or plain old packet sniffing, the authentication mechanism doesn’t matter.

The author makes some good points about OpenID, but I feel missing the mark with this:

Support for OpenID is conspicuously limited, however. Each of the big powers supposedly backing OpenID is glad to create an OpenID identity for visitors, which can be used at its site, but it isn’t willing to rely upon the OpenID credentials issued by others. You can’t use Microsoft-issued OpenID at Yahoo, nor Yahoo’s at Microsoft.

Why not? Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised. They do not want to take on the liability for mischief originating at someone else’s site.

I would argue that liability has little to do with it. The big OpenID providers don’t act as relying parties because they are fighting each other to be the dominant identity provider. They see being the identity provider as the key to drive more traffic to their site, which brings more advertising revenue. It’s a land grab pure and simple.

On Information Cards the author does make a point I have made on many occasions in the past, using Self-Issue Cards is really authenticating the computer and not the user:

BUT perhaps information cards in certain situations are convenient to a fault, permitting anyone who happens by a PC that is momentarily unattended in an office setting to click quickly through a sign-on at a Web site holding sensitive information. This need not pose a problem, however.

“Users on shared systems can easily set up a simple PIN code to protect any card from use by other users,” Mr. Cameron said.

Of course the users can PIN protect their self-issued cards. But history has shown that most wont.

Problem between keyboard and seat

Axel Nennker points out that the supposed “Cardspace Hack” is still floating around the old media. He allows the issue is not really a Cardspace security hole, but a problem between the keyboards and seats at Ruhr University Bochum:

A while ago two students, Xuan Chen and Christoph Löhr, from Ruhr University Bochum claimed to have “broken” CardSpace. There were some blog reactions to this claim. The authoritative one of course is from Kim.

Today I browsed through a magazine lying on the desk of a colleague of mine. This magazine with the promising title “IT-Security” repeats the false claim and reports that the students proved that CardSpace has severe security flaws… Well, when you switch off all security mechanism then, yes, there are security flaws (The security researcher in front of the computer).

Sort of what developers like me call an ID10T error.

Update: speaking of ID10T errors, I originally mistyped Axel’s name as Alex. My apologies.

Interesting times in InfoCard land

Burton Catalyst is going on this week and as usual there are more identity happenings that a poor blogger like me can keep up with. Unfortunately I am not attending this year which makes it even harder to keep up (this first one I have missed in a while).

One big news item was the announcement of the Information Card Foundation. You can read about it here, here, here, here, and here.

Another big item was the announcement about Microsoft HealthVault supporting not only Information Card authentication, but OpenID authentication as well. The decision to limit HealthVault OpenID authentication to a white list of just two providers has some (like Paul Madsen) hot under the collar.

Interesting times.

Cartoon Identity Selectors

I was watching my oldest plan Disney Toon Town, which is an MMOG for young kids. If you are a subscriber you get to have up to 6 six different avatars that you can choose from when entering the game world.

It occurs to me that this is really an identity selector. I have a feeling that Cardspace or other identity selectors will be an easy transition for them when they are ready.

Information Card Miscellany

Mike Jones is keeping a list of Information Card enabled sites. Mike also has an announcement about the new version of Cardspace being available.

Kim Cameron has some thoughts about Display Tokens and what compromises are needed for an effective Identity Metasystem.

Phil Hunt makes much of the Cardspace disclaimers here. I’m not sure what Phil’s point is here, but he seems to think he has found some sort of smoking gun. He has some further thoughts here and refers to Kim’s entry about Display Tokens.

Paul Madsen ventures into the strange world of German Fashion hoping for an Information Card experience and doesn’t get the one he wanted.

(Mirrored from TalkBMC)

Funny, I don’t feel crashed

Dave Kearns thinks I have missed the mark in my comments on Phil Hunts post. Perhaps I did not express myself well enough. I will have another go at it for Dave’s benefit.

When I said:

First party claims such as personal info can and should be made directly by the consumer who owns them. Information Cards provide a convenient way to do that. I see no compelling business case for a third party to make first party claims in a B2C scenario. 

I was referring to the same kind of personal information that the RP already trusts me to enter directly on a web site, or over the phone. The trust is implicit in the business relationship I am establishing. Involving a third party in this information exchange seems over complicated and without added value. I certainly don’t see why either the consumer or the SP would be willing to pay to involve a third party.

The statement that such claims are worthless without third party validation is risible at best. If that was the case then internet commerce wouldn’t exist. If I give Amazon my shipping address, they don’t need to have a third party validate it. I have no reason to give them an invalid address because then the business relationship I am paying to establish wouldn’t function. Specifically Amazon couldn’t ship me my purchased goods.

Perhaps someone could build a business as a third party personal information provider. Paul Madsen made the very good point that such a service could be valuable for providing that information while the consumer is offline. Perhaps, but I still don’t see a viable business case there. If someone could point me to such a service that is making money as a third party provider of personal information (things you would normally be trusted to enter on a web form) I will gladly admit I am wrong.

Now third party attributes are another story. From a business standpoint their value lies in the fact that they must be asserted by a third party. But keep in mind that the same information may be either a first or third party attribute depending on context. A site that wants my age for personalization purposes would accept it as a first party attribute. A site that wants my age to determine if I am legally old enough for an offered service would need it as a third party attribute.

Which leads to the Identity Oracle. If what makes an Identity Oracle different that an Attribute provider is that it can provide answers without divulging the underlying data, then there are serious issues that are not being discussed. When I said:

The mistake is saying an identity oracle can divulge whether your credit is good enough for the purposes of the transaction without divulging your credit score itself. I don’t believe that is possible in practice. If you say ‘Jeff’s credit score is as good as %90 of the people who have not defaulted on a loan of that amount’, then you have for practical purposes divulged Jeff’s credit score.

I was talking about information leakage. Let me give a more concrete example. Suppose a SP asks an Identity Oracle if Jeff qualifies for a specific loan and gets a yes answer. Technically the Identity Oracle has not divulged Jeff’s credit score. But suppose the loan amount would typically require AA rating? Then the SP knows Jeff’s credit score is between 720 and 850. While not technically the same as knowing the exact value, it’s functionally the same given how credit scores work.

Likewise if the SP asks if Jeff qualifies for a loan that virtually everyone without bad credit qualifies for, and the Identity Oracle says no, then the SP knows Jeff has a credit score less than 500. Again, that is functionally the same as knowing the value.

Does anyone really think that an Identity Oracle saying Jeff’s credit score is 720-850 has any more effective privacy associated with it than saying its 753? I should hope not.

So of course Dave gives the age counter-example. Everyone gives the age example. I am sick of the age example because it is an outlier case that distracts from the real issues, but all right, I’ll play along. Suppose the SP asks the Oracle if Jeff is allowed to buy alcohol. Then suppose the same SP asks if Jeff can vote. If the respective answers are No and Yes. The SP would then know that Jeff is between 18 and 21, effectively as good as knowing Jeff’s age.

Let me give you a chilling example. Suppose a potential employer asks an Identity Oracle if Jeff can purchase firearms in the state of FL. If the Identity Oracle says no, then since Jeff would have already disclosed his age and lack of criminal record, the employer then would suspect that it is because Jeff has a history of mental illness and would probably decline to hire Jeff.

Er… I’m strictly speaking hypothetically here.

This kind of information leakage is a huge privacy risk that is being ignored in the Identity Oracle discussion.

(Mirrored from TalkBMC)