Category: Information Cards

Dick Hardt on CardSpace and OpenID

Here is Dick Hardt, CEO of SXIP, explaining our joint announcement on OpenID and CardSpace to people in the community who may worry that Starship Microsoft is about to land on OpenID and squish it. 

This morning Microsoft announced they would support OpenID in future identity server products. Although this is a huge endorsement for OpenID, there will likely be many people that are fearful of what Microsoft’s involvement may do to OpenID.

At ActiveState I worked with Microsoft to bring Perl and Python technology to the Windows platform. This was a win for Perl and Python programmers that wanted to use their tools on the Windows platform. It was also a win for the community at large, as a fair amount of the threading and Unicode support that is in Perl today was funded by Microsoft. Just as I bridged the Microsoft and Open Source worlds back in the 90s,

I look forward to bridging the Microsoft and OpenID worlds today. The team at Microsoft get what we are doing in OpenID, and want to enable their technology to take advantage of the reach of OpenID, as well as enable the OpenID community to take advantage of CardSpace technology. This looks like a win-win for everybody.

Dick's previous Perl work really is a good example of what came about when we “defactionalized” our industry and got momentum going.  The “identity gang” phenomenon has been a good example of the same thing since day one, and this concrete announcement takes things in an even more positive direction.

Let me say something about potential squishing. It just won't happen.  One of the best things about OpenID is its organic quality, and the last thing we want to do is interfere with that.  

My big ask was to add a way to request credentials based on phishing-resistant authentication.  The main idea was to ensure the system is built to handle the dangers that would come with its own success.  As it is more widely adopted, and used for more purposes, OpenID credentials will inevitably become a “honeypot”.  But through the collaboration going on here, and other similar initiatives, we can make sure we'll have the means in place to protect our users even before they are in danger. This in turn is key to preventing a loss of confidence in identity systems and the internet in general.

In the early 1980’s, James Martin said, “Every successful system will attract usage to the point that it becomes unsuccessful”.  He was referring to systems that gobbled up mainframe resources by attracting users until they became bogged down and unusable, but over the years I've thought of his maxim in many contexts.  I think one outcome of today's announcement will be to provide an exception, and that's worth celebrating.

 

Scott Kveton on InfoCard / OpenID convergence

Here's a post by Scott Kveton, CEO of JanRain, that sums up a meeting we had during the week.  JanRain is one of the driving forces behind OpenID, and produces the libraries that a lot of people are integrating into their websites and blogs.  JanRain also operates MyOpenId, an identity service that works with OpenID software.

You want to know about the JanRain World Headquarters?  Energy radiates from everywhere.  Beside our conference table was a very impressive can of Bad Idea Repellant, which seems to have done its job.

For what it's worth, I really liked these people.  They are real engineers.  They are committed to getting an identity layer in place. 

I explained my concerns about the current OpenID proposal and  phishing, and they not only ACKed; they had ideas about how to move quickly to change things.  

Against this background it was clear how CardSpace could be one important way of strengthening their system and integrating it with others.  Meanwhile, I conveyed my enthusiasm for the great simplicity of their proposal. 

We talked about public (omnidirectional) and private (unidirectional) identifiers and we all agreed that both were necessary in different contexts.  We talked about how OpenID managed Cards could provide CardSpace with strong new capabilities around public personas for web services.

Then the conversation got pretty technical, and I showed a profile of WS-Trust that didn't involve use of a SOAP stack or anything complicated.  But over to Scott:

Mike Jones and Kim Cameron from Microsoft came in for a visit today to the JanRain World Headquarters (if you’ve ever visited here, you’d understand why that’s funny).

The JanRain engineers were interested in learning more about CardSpace. We’ve heard about it, seen Kim talk and even read his proposal on a way to integrate OpenID and CardSpace. However, we didn’t know enough about the technology to comment on it either way. Also, we wanted to hear more than just marketing hype and hand waving; we wanted some code. Kim and Mike did not disappoint … 🙂

CardSpace is an identity meta-system that you use to manage InfoCards. InfoCards are like the cards in your wallet except these cards you present to sites that you want to visit to identify yourself with. I really believe that Mike and Kim have their hearts in the right place and the technology looks solid. It looks like Microsoft has learned a lot since their last foray into identity. I think OpenID and CardSpace could really compliment each other quite nicely as well as help address the phishing concerns that have become so prevalent.

The CardSpace InfoCard manager is an interface that comes up when the user is presented with a site that supports InfoCard login. Instead of giving the user a login form in the browser that might be phished, the user is presented with a dialog that allows them to deliver an InfoCard for the site they are trying to login to. This dialog is single-modal; you are locked out of doing anything else unless you complete the task at hand. This follows along with what Mike Beltzner shared on the OpenID general list and the difficulties in fighting phishing:

I can also sum things up for you even more succinctly:

– users are task oriented, driving to complete the goal the quickest way possible
– users pay more attention to the content area than the browser chrome
– users don’t understand how easy it is to spoof a website

Kim went through several code examples where we could see how it all worked. Forget SOAP, forget complicated. There is no hook back to the mothership with this technology. As a matter of fact, OpenID and CardSpace could work together quite easily.

CardSpace is really good at handling the issues around phishing and personal privacy. But what if I don’t want to be private about certain things? I like that I can identify myself as me to lots and lots of different sites and I don’t mind if people correlate that data. As a matter of fact, I like it. Wouldn’t it be nice to have an OpenID tied to my InfoCard then? One of the greatest reasons OpenID is succeeding is that its a destination. Its a unique place on the Internet where you can learn more about who I am. Coupled with microformats you start to see some interesting possibilities. CardSpace doesn’t do the public side very well and both Kim and Mike admitted this. This is an interesting possibility for OpenID IMHO. Not only that, it could be done without any changes to sites that already support OpenID. You’d get the benefits of OpenID’s strengths while leveraging the anti-phishing and privacy mojo that CardSpace has.

We already have some great technology for changing the chrome in Firefox and discussions are on-going with Mozilla about how we can integrate this further and have it truly baked in (hopefully they’ll look at Dmitry’s thoughts on this). We’ve got the CardSpace code that is now shipping on Vista and available for Windows XP. We’ve got lots of options for fighting phishing and protecting privacy with more on the way. All of these solutions play to each technologies strengths and actually just might be what we need to get to the identity holy land.

 

How to get a branded InfoCard?

A lot of people have asked me, “But how does a user GET a managed Information Card?”  They are referring, if you are new to this discussion, to obtaining the digital equivalent to the cards in your wallet.

I sometimes hum and ha because there are so many ways you can potentially design this user experience.  I explain that technically, the user could just click a button on a web page, for example, to download and install a card.  She might need to enter a one-time password to make sure the card ended up in the hands of the right person.  And so on.

But now that production web sites are being built that accept InfoCards, we should be able to stop arm-waving and study actual screen shots to see what works best.  We'll be able to contrast and compare real user experiences.

Vittorio Bertocci, a colleague who blogs at vibro.net, is one of the people who has thought about this problem a lot.  He has worked with the giant European Etailer, Otto, on a really slick and powerful smart client that solves the problem.  Otto and Vittorio are really on top of their technology.  It's just a day or two after Vista and they have already deployed their first CardSpace application – using branded Otto cards. 

Here's what they've come up with.  I know there are a whole bunch of screen shots, but bear in mind that this is a “registration” process that only occurs once.  I'll hand it over to Vittorio…

The Otto Store is a smartclient which enables users to browse and experience in a rich way a view of Otto's products catalog.  Those functions are available to everyone who downloads and installs the application (it is in German only, but it is very intuitive and a true pleasure for the eye). The client also allows purchase of products directly from the application: this function, however, is available only for Otto customers. For being able to buy, you need to be registered with http://www.otto.de/.

That said: while buying on http://www.otto.de/ implies using username and password, the new smart client uses Otto managed cards. The client offers a seamless provisioning experience, thanks to which Otto customers can obtain and associate to their account an Otto managed card backed by a self issued card of their choice.
Let's get a closer look through the screens sequence.

Above you see the main screen of the application. You can play with it, I'll leave the sequence for adding items in the shopping cart to your playful explorations (hint: once you're chosen what to buy, you can reach the shopping cart area via the icon on the right end.

Above you see the shopping cart screen. You can check out by pressing the button circled in red.

Now we start talking business! On the left you are offered the chance of transfering the shopping cart to the otto.de web store, where you can finalize the purchase in “traditional” way. If you click the circled button on the right, though, you will be able to do go on with the purchase without leaving the smartclient and securing the whole thing via CardSpace. We click this button.

This screen asks you if you already own an Otto card or if you need to get one. I know what you are thinking: can't the app figure that out on its own? The answer is a resounding NO. The card collection is off limit for everybody but the interactive user: the application HAS to ask. Anyway, we don't have one Otto card yet so the question is immaterial. Let's go ahead and get one. We click on the circled button on the left.

This screen explains to the (German-speaking) user what is CardSpace. It also explains what is going to happen in the provisioning process: the user will choose one of his/her personal card, and the client will give back a newly created Otto managed card. We go ahead by clicking the circled button.

Well, that's end of line for non-Otto customers. This screen allows the user to 1) insert credentials (customer number and birthdate) to prove that they are Otto customers and 2) protect the message containing the above information with a self issued card. This is naturally obtained via my beloved WS-Security and seamless WCF-CardSpace integration. Inserting the credentials and pushing the button in the red circle will start the CardSpace experience:

The first thing you get is the “trust dialog” (I think it has a proper name, but I can't recall it right now). Here you can see that Otto has a Verisign EV certificate, which is great. I definitely believe it deserves my trust, so I'm going ahead and chosing to send my card.

 

Here there's my usual card collection. I'm going to send my “Main Card”: let's see which claims the service requires by clicking “Preview”.

Above you can see details about my self issued card. Specifically, we see that the only claim requested is the PPID. That makes sense: the self issued card will be used for generating the Otto managed card so the PPID comes in handy. Furthermore, it makes sense that no demographic info are requested: those have been acquired already, through a different channel. What we are being requested is almost a bare token, the seond authentication factor that will support our use of our future Otto managed card. Let's click “Send” and perform our ws-secure call.

The call was successful: the credentials were recognized, the token associated to self issued card parsed: as a result, the server generated my very own managed card and sent it back to you. Here's there is something to think about: since this is a rich client application, we can give to the user a seamless provisioning experience. I clicked “Send” in the former step, and I find myself in the Import screen without any intermediate step. How? The bits of the managed card (the famous .CRD file) are sent as a result of the WS call: then the rich client can “launch” it, opening the cardspace import experience (remember, there are NO APIs for accessing the card store: everything must be explicitly decided by the interactive user). What really happens is that the cardspace experience closes (when you hit send) and reopens (when they client receives the new card) without any actions required in the middle. If the same process would have happened in a browser application, this would not be achievable. If the card is generated in a web page, the card bits will probably be supplied as a link to a CRD card: when the user follows the link, it will be prompted by the browser for choosing if he/she wants to save the file or open it. It's a simple choice, but it's still a choice.
Back on the matter at hand: I'm all proud with my brand new Otto card, and I certainly click on “Install” without further ado. The screen changes to a view of my card collection, which I will spare you here, with its new citizen. You can close it and get back to the application.

The application senses that we successfully imported the managed card (another thing that would be harder with web applications). The provisioning phase is over, we won;t have to go through this again when we'll come back to the store in the future.
At this point we can click on the circled button and give to our new Otto Card a test drive: that will finally secure the call that will start the checkout process.

Here's we have my new card collection: as expected, the Otto card is the only card I can use here. Let's preview it:

Here's the set of claims in the Otto card: I have no hard time to admit that apart from “Strasse” and “Kundennummer” I have no idea of what those names mean :).
I may click on “Retrieve” and get the values, but at the time of writing there's no display token support yet: nothing to be worried about in term of functionality, you still get the token that will be used for securing the call: click the circled button for making the token available to WCF for securing the call.
Please note: if you are behind a firewall you may experience some difficulties a this point. If you have problems retrieving the token, try the application from home and that should fix it.

That's it! We used our Otto managed card, the backend recognized us and opened the session: from this moment on we can proceed as usual. Please note that we just authenticated, we didn't make any form of payment yet: the necessary information about that will be gathered in the next steps.
Also note that it was enough to choose the Otto managed card for performing the call, we weren't prompted for further authentication: that is because we backed the Otto card with a personal card that is not password protected. The identity selector was able to use the associated personal card directly, but if it would have been password protected the selector would have prompted the user to enter it before using the managed card.

It definitely takes longer to explain it than to make it. In fact, the experience is incredibly smooth (including the card provisioning!).

Kim, here's some energy for fueling the Identity Big Bang. How about that? 🙂

That's great, Vittorio.  I hear it. 

By the way, Vittorio is a really open person so if you have questions or ideas, contact him.

 

I-names and CardSpace

Here are some smart comments by =Andy.Dale of ooTao on how Information Card identity selectors like CardSpace and Higgins should work with XDI and i-names.  Andy has played an important role in introducing OpenID to ISPs and his comments bear directly on the convergence theme we've been discussing:

I wrote this missive in an email thread about using CardSpace with i-names I thought I should share it with you too:

IMHO the use cases that i-names support are a super set of the use cases that cardSpace supports… All of the digital identity usecases where someone else's wants to refer to me they need to use a globally unique identifier to identify me. Now I could keep giving people (services) my email but I'd much rather give my i-name. When a party has my i-name they can bootstrap ANY functionality that I provide. This is very different from cardSpace.

CardSpace is REALLY good at doing authentication (on Vista clients). Here's where I'm going to go out on that limb… I-names aren't bound to any specific authentication mechanism, they can be used in SAML they can be used in OpenID, but they can be used in any number of other schemes as well. A managed i-card with a signed assertion from the i-broker that this i-name has been validated as belonging to this card holder seems to me to be just as valid a mechanism to authenticate an i-name as any.

Use case:

I go to Evite (the i-name enabled Evite) and say I want to invite =joe to my party. NOTE: CardSpace has no mechanism for me to identify ‘Joe’; I HAVE to know a global identifier for him. Now Evite can look up =Joe's invitation SEP (could be his contact service, an email or other). Later =Joe wants to look at his invitation at Evite so he goes to the site and logs in with the convenence of the cardSpace paradigm. I don't think that using cardSpace authentication diminishes the value of the i-name in doing what it is good at doing.

So once cardSpace/higgins is broadly available we are going to need to define an attribute type so that an RP can ask for an i-name (or should it ask for an xri?). We are also going to have to provide the list of parties that should be trusted to assert i-name ownership (self asserted ‘this is my i-name’ should NOT be trusted); presumably XDI.org could publish that list.

So in summary… I think that people NEED i-names; they are just too useful in too many usecases. I DONT think that authentication mechanism is a good place to focus on the value of i-names, I would go as far as to say that this is one of the biggest mistakes that we in the i-name community have made. Once you have authenticated that the principle is the valid user of i-name that's where the value starts, not stops. So authenticate by whatever means the RP wants, and then look at all the cool services that can happen.

By the way, I've been using my =Kim.Cameron i-name for a couple of years now – ever since I started this blog.  It has been a life-saver.  It has been my email conduit to my readers and allowed me to interact personally with many people all over the world – without ONE piece of spam.  

So I would be a fool not to be a big supporter.  And more broadly, I'm a fan of =Drummond.Reed‘s thinking about identifiers.  He and his associates have thought more deeply about what identifiers need to be than anyone else in the world.

 

New InfoCard Profile documents available

Arun Nanda, Mike Jones, and others both at Microsoft and Ping have been working very hard for a long time now to make sure the profile we used to build our prototypes, and then our product, was being fully shared with everyone else who wanted to interoperate.  This has also involved an ongoing attempt to make sure the profile was clear enough to be useful.

Today I'm posting new versions that I think are a lot clearer (let me know!)  First, here is A Guide to Supporting Information Cards within Web Applications and Browsers as of the Information Card Profile V1.0.  I think anyone adding InfoCards to their site will find this document useful.

In addition I'm putting up two documents intended for people who really want to get into the details of how to implement the underlying toolkits and platforms.  Don't feel compelled to read them if you aren't doing this type of work!  They are part of the process of working with our colleagues in OSIS, Higgins, etc – those building Identity Selectors and the system software that powers managed card providers and claims transformers.  The papers will also be of interest to academics and people who really like to get way down into how things work.   You should begin with A Guide to Interoperating with the Infomation Card Profile V1.0.  I'll post the second document (the normative technical reference) in a couple of days.

I'm beginning by putting these docs up here so everyone in the identity community can get access to them ASAP.  Ultimately, they will appear in many other places, including MSDN.

 

Drummond Reed on CardSpace and OpenID

Amongst other things, Drummond is CTO of Cordance and co-chair of the OASIS XRI and XDI Technical Committees.  He's playing an important role in getting new identity ideas into the Internet Service Provider world.  Here he responds to my first convergence post:

Earlier this month Kim Cameron starting blogging about some of the phishing concerns he’s had about OpenID that he and Mike Jones have shared with myself and other members of the OpenID community privately since Digital ID World last September. Given that anti-phishing protection is one of the greatest strengths of CardSpace, one of Kim’s and Mike’s suggestions has been for OpenID providers to start accepting CardSpace cards for customer authentication.

Today Kim blogged his proposed solution for integrating OpenID and InfoCard in detail. He does a wonderful job of it, making it very clear how using CardSpace and OpenID together can be a win/win for both. With Windows Vista shipping to consumers at the end of the month, and the CardSpace upgrade now available to XP users, this is a very practical solution to increasing OpenID security that I expect all XDI.org-accredited i-brokers (who all provide OpenID authentication service for i-name holders) to implement as soon as they can.

Kim closes his post by saying, “That said, I have another proposal [for integrating OpenID and CardSpace] as well.” That’s good, and I await it eagerly, because I too believe the integration can go much deeper, just as it can for OpenID and SAML. The heart of it is individuals and organizations being able to assert their own resolvable, privacy-protected digital identifiers. That’s the foundation of the OpenID framework, and the job for which we’ve been designing XRI i-names and i-numbers for the past five years. Microsoft’s current default CardSpace schema does not yet natively support XRIs as digital identifiers, but adding them could increase their power and utility and be another big step towards convergence on a unified Internet identity layer.

I'm going to clone myself so I can find more time to write up my second proposal.  Meanwhile, just a small clarification.  Drummond talks about the “default CardSpace schema”.  He's really talking about the “default Self-Issued Card schema.” 

CardSpace itself handles tokens of any type, containing claims of any type.  There are no limitations on your schema if you create a managed card.  I'll make that clearer in my next post. 

Further, we tried to keep the “bootstrap” Self-Issued Card provider down to a minimal set of initial schema choices – precisely to leave room for a managed card ecology.  But one of those initial claims is a URL…  I thought an i-name or i-numbers would be able to go there.  Is more needed?

 

Dmitry Shechtman's Undevelopment Blog

So much is happening in the identity discussion it's hard to keep up with it.  Through the miracles of ping-back I came across The Undevelopment Blog by Dmitry Shechtman, and this posting on a new proposal called Identity Manager: 

It seems like the OpenID community is currently bothered with the following two questions:

  1. OpenID facilitates phishing. What can be done about this?
  2. FireFox 3.0 will have CardSpace and OpenID support. What does that mean?

I addressed the OpenID phishing problem even before it became wildly discussed. Unfortunately, the method wasn’t foolproof, to say the least. Several other suggestions have been brought up, but none seemed to solve the problem without making OpenID unusable.

Kim Cameron of Microsoft has been repeatedly promising to elaborate on how CardSpace and OpenID could converge. Although he has yet to keep his promise, we can make an educated guess. We recently saw the FireFox extension Identity Selector act as an in-browser OpenID-to-InfoCard bridge. That is definitely something CardSpace folks would love to see as a standard browser feature, since it would effectively turn an OpenID into nothing more than a fairly insecure InfoCard.

Of course, OpenID could simply dismiss CardSpace (I was trying to get into the average kool-aid drinker’s shoes). Or it could very well learn from it. The CardSpace UI seems very intuitive:

  • A Sign In button on a website
  • An identity selection dialog
  • Seamless secure login

This is exactly what OpenID needs in order to become both widely used and insusceptible to phishing. And since CardSpace planned support is now a reality, why shouldn’t OpenID be integrated? This is no trivial requirement, but one that can be met with some additions to the browser logic.

The combination of UI and business logic outlined in this proposal is dubbed Identity Manager. The proposal uses informal language (should, must, be and do are used interchangeably); handle with care.

Whenever a web page presents an OpenID sign in option, the OpenID field and the Sign In button are replaced by a single OpenID Sign In button. Moreover, separate OpenID Sign In and CardSpace Sign In buttons are replaced with a Secure Sign In button.

Once such a button is pushed, an Identity Manager window is presented with a list of the user’s identities — OpenIDs, InfoCards or both, depending on what the relying party accepts. The user must be able to decline; we treat this case as trivial. The user must be able to make a persistent selection (e.g. a checkbox with the text Always use this ID for example.com).

(Dmitry's piece continues here…)

I would never characterize OpenID as “nothing more than a fairly insecure infocard”. It is a system where the root of trust is defined to be control over the content at a URL.  Folks, this is innovative.  I like it as what I call an “underlying identity system” that should live within the identity metasystem.  Given its theoretical starting point in terms of trust, OpenID has the security characteristics, good and bad, of the Internet which it harnesses in the name of identity.  That makes it very exciting, especially for bottoms up use cases involving public personna.

But “exciting” doesn't mean “good for every purpose.”  OpenID won't replace all other forms of digital identity!

Is it necessary to explain further?

I'm fine with blog comments being associated with my URL.  But I don't want access to my bank account to be gated by nothing more than the ability to set the header in what a system thinks is https://www.identityblog.com (I'm thinking here about all the potential attacks on DNS as well as the ways in which third parties could gain unauthorized access to my page). 

My site is hosted by the good people at http://www.textdrive.com.  As administrators of the shared systems there, they could certainly, for example, gain access to my pages. 

Are their employees bonded?  Do they practice strict separation of duties for access to web pages?  Do they have HR practices that will protect them from organized crime?  I don't think so!  And if they did,  wouldn't they turn into the world's most bureaucratic mess as a web hosting service?  Their flexibility and personal touch is what makes them so good.  I like them just as they are, thank you very much.

So it all comes back to the Laws of Identity.  There will be a pluralism of providers and technologies, optimal in different use cases.  And, as the potential phishing attacks demonstrate, there remains the requirement of giving users a consistent and controlled experience across these multiple systems.

My conclusion?

Combine CardSpace (insert your favorite replacement identity selector here) with OpenID and you have the best of both worlds.  You have the web-based identity system.  You have a consistent anti-phishing user experience.  And you have continuity between OpenID and other underlying systems in a metasystem.  Wouldn't we all want this?

As Dmitry reports, I have promised to share my own technical ideas about how to move forward but haven't come through on my promise yet.  So I'm going to do that now.  One idea is very simple (and effective) – I'll start with that.  The second is in many ways more interesting (at least to me) but I need to explain a bit more about managed cards before I get to it.

 

State of the market or chance to get things right?

Eric Norlin of Digital Identity World comments on my concerns (note:  concerns are not allegations) about the need for client-side anti-spoofing components: 

Every now and then a technical disagreement betrays the state of a marketplace. That phenomenon is currently happening in the user-centric identity trenches.

The players are Kim Cameron (InfoCards/CardSpace) of Microsoft on one side and Dick Hardt (OpenID) of Sxip Identity on the other.  The issue: Kim's recent allegations that OpenID will make identity *less* secure and possibly result in security breaches that will set the user-centric identity work back in the minds of users.

The debate highlights where we are with user-centric identity.

The technical details all focus around the need (or lack of need) for client-side identity selectors with Kim arguing that its necessary to prevent spoofing, and Dick arguing that the spoofing security threat is acknowledged and defensible via OpenID. But the technical details (and argument) are not the most interesting thing.

Arguments like this, as all engineers know, are common in the world of the engineering. The reason is simple: the “engineer's mind” (versus the “marketer's mind”) naturally seeks the “perfect solution.” That's the blessing of the engineer's mind. It is, of course, also the curse.

As any student of technology history knows, the “perfect solution” has rarely won the battle of the marketplace. Instead, the solution that solved the problem set using “the principle of good enough”, and *also* attained a critical mass of adoption has won. Does that result in further problems to be solved? Of course it does! That, my friends, is the cycle of innovation.

The current debate between Kim and Dick actually serves to show us where the user-centric identity market actually is. Several years ago, two groups were competing around federation standards (the Liberty Alliance and Microsoft/IBM's WS-* standards). For what seemed like forever, they held obscure debates about the details of the standards. Eventually, the market moved forward (seemingly without either group's help), and now today we find ourselves witnessing a new Liberty Alliance President saying that the “gloves are off” and they'd like to find ways to converge with the WS-* standards.

That simple, recent analogy shows us where we are with user-centric identity. We're on the verge of the market beginning to really adopt some technology. These conversations don't reach this level unless those involved see this potential.

In the meantime, the engineers will continue to debate the details, and that's good for all of us.

I want people to understand I'm not against OpenID, and I don't see this as something that should turn into a war, marketing or other.  We should do everything we can to make OpenID as secure as possible, and that includes integrating it with InfoCards wherever this is possible.

 

 

Separating apples from oranges

Dick Hardt of Sxip posted a reply to my recent comments on the fears I have about attacks on OpenID:

My good friend Kim Cameron posted the following misinformation on OpenID:

InfoCards change the current model in which the user can be controlled by an evil site. OpenID doesn’t. 

If a user ends up at an evil site today, it can pose as a good site known to the user by scooping the good site’s skin so the user is fooled into entering her username and password.

An evil site proxying a web based OpenID Provider is a known security threat in OpenID. There are a number of ways of thwarting this attack, and given that the user has a close relationship with their OP, not difficult to deploy. Similar to the advantages that CardSpace has with a client side implementation, Sxipper is a Firefox plug-in that provides an OpenID user with the same client side protections as CardSpace. OpenID is a protocol, similar at a high level to WS-* — so this is somewhat of an apples an oranges comparison. CardSpace could support OpenID and protect the user.

I’d like to see OpenID and InfoCard technologies come together more. I’ll be presenting a plan for that over the next little while.

I’m looking forward to seeing your thoughts Kim! Perhaps supporting OpenID in Cardspace?

I'm not just talking about (realtime) proxying.  I'm talking about social engineering attacks in general.  Where is the misinformation in my description of these attacks?  

Dick reassures us that use of the protocol to help convince uers to reveal their credential is a known attack.  Should this make me feel better?  I don't think so. 

I also don't think the mitigations I've heard about are too convincing – with a couple of exceptions. 

One of those is the mitigation devised by Dick himself – called Sxipper.  This is a plugin for the browser which, as I understand it, take control away from the evil party.  If all OpenID implementations were to add this feature it would be a big step forward!

But in that case, if we want to separate apples from oranges, let's not say that InfoCards require a client component and OpenID doesn't.  Let's say that to offer reasonable protection, InfoCards require a client component and so does OpenID.  That would, as Dick proposes, properly separate discussion of protocols from the overall delivery of an identity solution.

Use of a hardware token at the OpenID site also mitigates the social engineering attack, though not the man in the middle attack.

More later about how Cardspace and OpenID can converge further.

Bill Barnes is CardCarrying

Bill  Barnes is more responsible for crafting the Cardspace user experience than anyone on our team.  Now, he's not only working on next generation Cardspace, but tackling the user experience issues that arise when integrating InfoCards into web sites (e.g. “how to build a relying party?”.  Of course, this is an on-going project and – great news – he'll be using his new CardCarrying blog to express his thinking and develop ideas.  For those interested in InfoCards, this is a “must-subscribe”.  Here's his take on what he's doing: 

Information Cards are a new approach to digital identity. So new that I’ve noticed an interesting phenomenon – in the hundred or so times I’ve presented our idea, to audiences of all kinds, it always takes the better part of an hour to convey. Sometimes more. And I’m a good speaker.

This shouldn't be surprising. They’re new, and one would expect the concepts to take a while to sink in. I remember the first time I saw the World Wide Web, then just a few months old. I just didn’t get it. My friend did a very admirable job as visionary, but it didn’t click. Same thing with TiVo. Again, I’m not dumb, not that dumb anyway, but new ideas take a while to filter in.

And Information Cards have it worse. They’re not just new, they’re different, and different is harder. You don’t just have to learn, you have to unlearn. This helps explain why security experts often take the longest to grasp what we’re doing – we’re forcing them to go back to first principles, and for many of them that’s a long way back. But even my mom has to unlearn passwords, and that won’t happen instantly.

I love to talk, I do. So I don’t mind speaking for the better part of an hour if that’s what it takes to get someone up to speed. But I have two jobs. My busy schedule simply won’t allow me to teach Information Cards to every man, woman, and child on the Internet today. How are we going to educate them? More to the point, how will website X, which thinks supporting Information Cards will garner more customers from increased security and convenience, educate them?

The good news is, not everyone needs to understand the end-to-end meta-architecture. They just need to understand what they need to make it work. One of the reasons we adopted the Card metaphor was that it brings with it some intuition. Hopefully, then, a given website won’t have to do very much explanation.

Here’s what I think they need to know, in language that I am continuing to develop. My hope is that, with these few key concepts under their belt, the flow of the website plus the user experience of their identity selector, be it Windows CardSpace or a competitor, will be clear enough to take them the rest of the way. So, without further ado:

Information Cards are like digital versions of the cards in your wallet. You can make personal cards for signing in to websites – they are like passwords but are much harder to steal. Personal cards are stored on your computer, and you can use a single card to sign into multiple websites.

You can also download managed cards from organizations like banks, associations, and businesses. When you want to prove something about yourself to a website, for instance “I am a member of club X” or “I work for company Y”, show that website a managed card. A managed card is stored on your computer, but the information it conveys is not.

These are the key points I think people need to understand. And the second part, managed cards, isn’t necessary if your site doesn’t take managed cards, and that’s most of them out of the gate. So really it’s one paragraph, three sentences, four or five concepts.

Don’t get me wrong, I think four or five concepts is a lot, and I don’t expect everyone to get it right away. I think inevitably what will happen is that a small group of geeks will learn these concepts deeply, and start to evangelize them in the blogosphere, in media, and to their parents. A good analogy here is RSS. My experience in that hardly anyone outside the technorati knows what it is yet, and very few people will bootstrap themselves simply by seeing that magic orange square. Conversions happen one at a time, from one satisfied (and informed) customer to another. My mom will use Information Cards because I tell her why she should.

I have heard some other great ideas about educating people. More on these later. Meanwhile, let me know how you would educate a user at your website on what Information Cards are, and why they should use them at your website. Would you use my language or a variant thereof? Share the love.

Oh, one more thing. I’m not speaking in an official capacity here, but I don’t think it’s reasonable to expect Microsoft or anyone else to mount a giant P.R. education campaign on Information Cards, any more than you would expect them or anyone else to convince you to use RSS. If it’s really a good technology (and I think it is) it will succeed because it is in everyone’s benefit when it is used. So I think everyone shares the educational burden. So get teaching.