Category: Identity

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.

 

Ping will show OpenID / CardSpace integration

According to this post, Ashish Jain at Ping has a new prototype of how CardSpace / OpenID integration will work in their evolving product.  It seems to be a continuation of the work they've already done with SAML / CardSpace integration – only now, the OpenID protocol has been added to the metasystem mix.

Come to think of it, isn't Dick Hardt's Whobar pretty close to having this capability as well?  So I think a number of us have wanted to integrate this work for some time, but recently it has become more obvious what the advantages are.

Anyway, if you haven't read Ashish's piece:

Kim posted a pretty good description of how CardSpace and OpenID can interact. This has been talked about for a while and Kim did a great job of describing it.

CardSpace OpenID Integration

In short, I agree. In fact, if you want to see a demo of what Kim describes, please stop by Ping Identity’s booth next week at the RSA Conference and you will get to see exactly that. An OpenID IdP Server that uses CardSpace for runtime authentication.

It’s not done by any means. There are still some unresolved items. For instance, If the user already has a profile registered with the OP, at runtime should the server use the persisted attributes or the claims as provided by the card? And the support for multiple cards. But you will get the idea.

I still have a few questions though. AFAIK OpenID Authentication 2.0 considers authentication out of scope.. So….to prevent phishing and to build user’s confidence, I can use CardSpace. Or anything on the likes of PassMark’s mutual auth. To provide more confidence to the RP, I can use OTP, device finger printing, biometric, certificates, KBA whatever. However there doesn’t seem to be the SAML AuthnContext equivalent to convey this to the RP. Therefore RP has no way to determine the type of OP authentication or if the authentication ever happened.

Even if there is way to communicate the authentication type, there is no trust or relationship between the OP and the RP. So….RP (who as a service provider has everything to loose) has no reason to believe that the OP isn’t lying and may have to employ their own safety measures.

I’m still coming up the curve so I may be wrong, but something seems missing. I’ll keep looking.

Ashish makes an interesting point about conveying the authentication type in the protocol.  I certainly agree with him.

I also like his question about trust.  It's one others have asked and which I scratched my head about at first.  So I'll put in my two cents worth.

In all identity protocols, you have an authority that makes claims about a subject, and the relying party decides whether or not to believe them.  As computer nerds we have called that “trust”, though in real business environments it's usually more a matter of reducing risk to the point that, on balance, it's better to do a transaction than not to do it.

But what is “the trust” (risk analysis) based on?  Usually on business relationships.  For example, we trust a bank to make assertions of various sorts.  And we trust a partner or customer to make other assertions.  So the trust is rooted in our experience – in a relationship.

This is where OpenID does something different: the authority is simply the behavior of the internet, and the trust only pertains to an identifier (one could layer other capabilities on top of this).

Basic Tenets

  1. Every person has a URL to which they lay claim.
  2. Every URL has an identity provider that “speaks for” it.

When I go to a relying party I tell it which URL I claim.  Then it sends me to the identity provider that speaks for that URL to get a token saying I really control it.

I give that token to the relying party, which then contacts the identity provider to verify the token is valid (the actual protocol includes optimizations).

To believe the claim, the Relying Party (RP) needs to trust that the URL has not been tampered with (an evil party could alter it to say an evil identity provider speaks for it).  The RP also has to believe it really contacted the URL when finding out who spoke for it (I could have been misdirected through a DNS attack).  And it needs to believe it really contacted the identity provider when getting token validation (again trusting DNS).  The last two issues can be mitigated by using https, but that complicates it, and even then, the system has different characteristics than one based on cryptographic tokens.

All in all, the closest analogy is to using an email address as an identifier by asking what email address you own, sending you the email, and getting you to click a link showing you own the email.  In this case the relying party depends on the underlying mail system, DNS, and all that.  OpenID replaces email with web URLs.  So it's a lot more direct.

Proving control 

How does an identity service know you really control some URL?  Many approaches are possible.  Let me give the example of Yahoo's system (it's not OpenID but uses the same general idea). You log into their identity provider and it gives you a key (a couple of lines or random gook).  You must then paste the key into your html page and press a button back at Yahoo.  This causes their system to open your page and see if the key is there. If so, the service deems that you own the URL.  Having done this you can get rid of the key and the Yahoo identity provider is willing to “speak for” your control of the URL.  The whole process just takes five minutes.

 

Scary phishing video from gnucitizen

Here's a must-see that punctuates our current conversation with – are you ready? – drama and numerous other arts.

Beyond the fact that it's just plain cool – and scary – as a production, it underlines one of the main points we need to get across.  The evolution of the virtual world will be blocked until we can make it as safe as the physical one. 

As Pam says, “this video really captures the panic involved in being hacked…”.  That's for sure.

Integrating OpenID and Infocard – Part 1

Let's start by taking a step-by-step look at the basic OpenID protocol to see how the phishing attack works.  (Click on the diagrams to see them on a more readable scale.)

The system consists of three parties – the relying party (or RP) which wants an ID in order to provide services to the user;  the user – running a browser;  and the Identity Provider (OpenID affectionados call it an OP – presumably because the phrase Open Identity Identity Provider smacks of the Department of Redundancy Department.   None the less I'll stick with the term IP since I want to discuss this in a broader context).

OpenID can employ a few possible messages and patterns, but I'll just deal with the one which is of concern to me.  An interaction starts with the user telling the RP what her URL is (1).  The RP consults the URL content to determine where the user's IP is located (not shown).  Then it redirects the user to her IP to pick up an authentication token, as shown in (2) and (3).  To do the authentication, the IP has to be sure that it's the user who is making the request.  So it presents her with an authentication screen, typically asking for a username and password in (4).  If they are entered correctly, the IP mints a token to send to the RP as shown in (5) and (6).  If the IP and RP already know each other, this is the end of the authentication part of the protocol.  If not, the back channel is used as well.

The attack works as shown in the next diagram.  The user unwittingly goes to an evil site (through conventional phishing or even by following a search engine).  The user sends the evil RP her URL (1) and it consults the URL's content to determine the location of her IP (not shown).  But instead of redirecting the user to the legitimate IP, it redirects her to the Evil Scooper site as shown in (2) an (3).  The Evil Scooper contacts the legitimate IP and pulls down an exact replica of its login experience (it can even simply become a “man in the middle”) as shown in (4).  Convinced she is talking to her IP, the user posts her credentials (username and password) which can now be used by the Evil Scooper to get tokens from the legitimate IP.  These tokens can then be used to gain access to any legitimate RP (not shown – too gory).

The problem here is that redirection to the home site is under the control of the evil party, and the user gives that party enough information to sink her.  Further, the whole process can be fully automated.

We can eliminate this attack if the user employs Cardspace (or some other identity selector) to log in to the Identity Provider.  One way to do this is through use of a self-issued card.  Let's look at what this does to the attacker.

Everything looks the same until step (4), where the user would normally enter her username and password.  With self-issued cards, username and password aren't used and can't be revealed no matter how much the user is tricked.  There is nothing to steal.  The central “honeypot credentials” cannot be pried out of the user. The system employs public key cryptography and generates different keys for every site the user visits.  So an Evil Scooper can scoop as much as it wants but nothing of value will be revealed to it.

I'll point out that this is a lot stronger as a solution than just configuring a web browser to know the IP's address.  I won't go into the many potential attacks on the web browser, although I wish people would start thinking about those, too.  What I am saying is the solution I am proposing benefits from cryptogrphy, and that is a good thing, not a bad thing. 

There are other advantages as well.  Not the least of these is that the user comes to see authentication as being a consistent experience whether going to an OpenID identity provider or to an identity provider using some other technology. 

So is this just like saying, “you can fix OpenID if you replace it with Cardspace”?  Absolutely not.  In this proposal, the relying parties continue to use OpenID in its current form, so we have a very nice lightweight solution.  Meanwhile Cardspace is used at the identity provider to keep credentials from being stolen.  So the best aspects of OpenID are retained.

How hard would it be for OpenID producers to go in this direction? 

Trivial.  OpenID software providers would just have to hook support for self-issued cards into their “OP” authentication.  More and more software is coming out that will make this easy, and if anyone has trouble just let me know.

Clearly not everyone will use Infocards on day one.  But if OpenID embraces the  alternative I am proposing, people who want to use selectors will have the option to protect themselves.  It will give those of us really concerned about phishing and security the opportunity to work with people so they can understand the benefits of Information Cards – especially when they want, as they inevitably will, to start protecting things of greater value.

So my ask is simple.  Build Infocard compatibility into OpenID identity providers.  This would help promote Infocards on the one hand, and result in enhanced safety for OpenID on the other.  How can that be anything other than a WIN/WIN?  I know there are already a number of people in the milieux who want to do this.

I think it would really help and is eminently doable.

This said, I have another proposal as well.  I'll get to it over then next few days.

Ben Laurie and the “Kittens” phishing attack.

Here's a post about potential OpenID phishing problems by Ben Laurie, long-time security avocate who played an important role in getting SSL into open source.  He's now at Google.  Don't misinterpret his intentions despite his characteristically colorful introductory sentence – in a subsequent piece he makes it clear that he too wants to find solutions to these problems.

OpenID announced the release of a new draft of OpenID Authentication 2.0 today. I’m reluctantly forced to come to the conclusion that the OpenID people don’t care about phishing, since they’ve defined a standard that has to be the worst I’ve ever seen from a phishing point of view.

OK, so what’s the problem? If I’m a phisher my goal is to be able to log in to some website, the Real Website, as you, the Innocent Victim. In order to do this, I persuade you to go to a website I control that looks like the Real Website. When you log in, thinking it is the Real Website, I get your username and password, and I can then proceed to empty your Paypal account, write myself cheques from your bank account, or whatever fiendish plan I have today.

So, why does OpenID make this worse? Because in the standard case, I (the phisher) have to make my website look like the Real Website and persuade you to go to it somehow – i.e. con you into thinking I am the real Paypal, and your account really has been frozen (or is that phrozen?) and you really do need to log in to unphreeze it.

But in the OpenID case I just persuade you to go anywhere at all, say my lovely site of kitten photos, and get you to log in using your OpenID. Following the protocol, I find out where your provider is (i.e. the site you log in to to prove you really own that OpenID), but instead of sending you there (because, yes, OpenID works by having the site you’re logging in to send you to your provider) I send you to my fake provider, which then just proxies the real provider, stealing your login as it does. I don’t have to persuade you that I’m anything special, just someone who wants you to use OpenID, as the designers hope will become commonplace, and I don’t have to know your provider in advance.

So, I can steal login credentials on a massive basis without any tailoring or pretence at all! All I need is good photos of kittens.

I had hoped that by constantly bringing this up the OpenID people might take some step to deal with the issue, but they continue to insist on punting on it entirely:

The manner in which the end user authenticates to their OP [OpenID provider] and any policies surrounding such authentication is out of scope for this document.

which means, in practice, people will authenticate using passwords in forms, as usual. Which means, in turn, that phishing will be trivial.

Like me, Ben was struck with how readily the system currently lends itself to automation of phishing attacks.  His second post on the subject is also interesting.

 

We need severe crypto

Someone just pointed out this super strong message from the Energy Field that is Marc Canter (founder of Macromedia and Broadband Mechanics):

Kim Cameron sets the record straight: State of the market or chance to get things right?  And he has nothing against OpenID.  But Kim is the god head and groks this shit better than any of us – so please listen to him!  ID is a hell of a lot more than SSO or authentication and if we’re to stop phishing, and spoofing and ID theft – we need severe crypto, locked down, secure ID systems.

No one can say Marc doesn't speak in thunder bolts.  This is better summary of what I've been trying to say than I can manage (I would have elided the “god head” part!)

 

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.

 

Identity Crisis Podcast

Identity Crisis If you haven't read Jim Harper's book, Identity Crisis: How Identification Is Overused and Missunderstood I urge you to do so as soon as you can.

I was initially a bit skeptical about this book because – I hope my more politically inclined friends will forgive me – it was published by what I assume is a political “think tank”.  I worried it might reflect some kind of ideology, rather than being a dispassionate examination of reality.

But in this case I was wrong, wrong, wrong. 

Jim Harper really understands identification.  And he is better than anyone at explaining what identification systems won't do for us – or our institutions. He carefully explains why many of the proposed uses of identification are irrational – delivering results that are quite unrelated to what they are purported to do.  In my view, getting this message out is just as important as explaining what identity will do.  In fact it is a prerequisite for the identity big-bang.  There are two sides to this equation an we need to understand them both.

He directly takes on the myth that if only we knew what peoples’ identifiers were, “we would be safe”.  Metaphorically, he is asking what kind of plane we would rather fly in – one where the passengers’ identifiers have been checked against a database or one where they and their luggage have been screened for explosives and guns? 

I think he will convey to “lay people” why a so-called “blacklist” is one of the weakest forms of protection, showing that all you have to do is impersonate anyone not on it to sneak through the cracks.

The book is full of important discussions.  It has chapters like “Use identification less” and “Use authorization more.”  I have only one criticism of the book.  I would like to see us separate the notion of identity, on the one hand, and individual identification (or identifiers) on the other.  We need return to the original meaning of identity: the fact of being who or what a person or thing is.

As a simple example, suppose I'm a service provider building a chat room for children, and want to limit participation to children who are between 12 and 15.  Let me contrast two ways of doing this. 

In the first, all the children are given an identifier.  To get into the room, they present their identifier and prove they are the person to whom that identifier was given.  Then the chatroom system does a lookup in some public system linking identifier and age to make the access control decision.

In the second, the children are given a “digital claim” that they are of some age, and a way to prove they are the person to whom that “claim” was given.  The chatroom system just queries the claim to see if it meets its criteria.  There is no reference to any public or even private identifier.

My point is that the first mechanism involves use of an identifier.  The second still involves identity – in the sense of being what a person is – but the identification, so rightly put into question by Jim's book, has been put into the trashcan where it belongs.

The use of an identifier in our first example breaks the second Law of Identity (Data Minimization – release no more data than necessary). It breaks the third Law too (Fewest Parties – since it discloses use of information to a central database unnecessary to the transaction).   Finally, it breaks the Fourth Law (using an omnidirectional identifier when none is required).

The book was written before “claims-based thinking” began to gain mindshare, and so it's missing as a category in Jim's discussion of advanced identity technologies.  But we've talked extensively about these issues and we have concluded that we have no theoretical difference – in fact the alignment between his work and the Laws of Identity struck us both as remarkable given that we come at these issues from such different starting points. 

Jim's book is wonderful reading.  It should help newcomers better understand the Laws of Identity.  And this week the Cato Institute in Washington held an event at which Jim spoke, along with James Lewis, Director and Senior Fellow, Technology and Public Policy Program Center for Strategic and International Studies; and Jay Stanley, Public Education Director, Technology and Liberty Project American Civil Liberties Union.

Download the podcast or watch the video here.