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.

Superpat and the third way

Pat Patterson leaps through the firmament to punctuate my recent discussion of minimal disclosure with this gotcha: 

But, but, but… how does the relying party know not to ask for givenname, surname and emailaddress the second (and subsequent) time round? It doesn't know that it's already collected those claims for that user, since it doesn't know who the user is yet…

In the case described by Pat, the site really does use a “registration” model like the one from BestBuy shown here. 

When registering you hand over your identity information, and subsequently you only “authenticate”. 

This is really the current model for how identity is handled by most web sites.  In other words the “Registration process” is completely separated from the “Returning user” process.

So the obvious answer to Pat's question is that when you press “create an account” above, you invoke an object tag that asks for the four attributes discussed earlier.  And if you press “Sign in”, you invoke an object tag that only asks for PPID and then associates with your stored information.  

In other words, there is no new problem and no new framework is required.

This doesn't prevent Pat from serving up a little irony:

If only there were some specification (perhaps part of some sort of framework) that, given a token from an authentication, allowed you to get the data you needed, subject, of course, to the user's permission. 

I guess it bothered Pat that I didn't include use of backend protocols as one of the options for reducing disclosure. 

I want to set this right.  I've said since the beginning that as I saw it, the PPID (or other authenticated identifier) delivered by an InfoCard could also be used to animate a back-end protocol such as he's refering to.  That's one of the reasons I thought everyone should be able to rally behind these proposals.

The third option

So let me add a third alternative to the two I gave yesterday (storing locally or asking the user to resubmit through infocard).  The relying party could authenticate the user using InfoCard and then contact the identity provider with the user's PPID and ask it for the information the user has already agreed should be released to it.  This could be done using the protocols referred to by Pat. 

My uberpoint is simple.  InfoCards are intended to be as neutral as possible in their technical assumptions (e.g. to be an identity platform) and can be used in many ways that make sense in different environments and use cases.

I don't personally agree that the back-end protocol route for obtaining attributes is either simpler or more secure than delivering the claims directly on an as-needed basis in the authentication token, but it is certainly possible and I'm sure it has its use cases.  I wonder if Pat's implementation of Information Cards, should there be one, will take this approach?  Interesting.

 

Resending of personal data with InfoCards

Eric Schultz writes with this question: 

I've been investigating CardSpace and the practicality of it's use for login on a new social networking site.

I have a question regarding the method through which data is transferred. I see that you can require certain claims from an InfoCard such as email, first and last name, zip code etc. When I look at the login code I see that the same claims are required again.

Does this mean that each time an InfoCard is sent all the personal data is resent? Isn't this dangerous for security/privacy? The potential for a server failure (malicious or not) caused by a buffer overflow, a coding mistake that outputs the details of session variables etc. seems rather risky in this scenario.

Perhaps I am being alarmist?

This is an area in which being “an alarmist” – perhaps I will rephrase it as being thoroughly pessimistic about what can go wrong – is the best starting point.  You questions are ones everyone should think about.

InfoCard and Minimal Disclosure

The simple answer is that there is nothing built into InfoCard concepts that requires a “relying party” to ask for attributes every time a user comes to its site.  Let's first look at the mechanics. 

The relying party controls what attributes it asks for by putting an OBJECT tag in the HTML page where the user opts to use an infocard.

The example shown here will bring up the infocard dialog and illuminate any cards that offer all four claims so the user can select one. 

If, next time, the relying party doesn't want to receive these claims, it just doesn't ask for them.  If it has stored them, it should be able to retrieve them when necessary by using  “privatepersonalidentifier” as a handle.  This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.

No theoretical bias 

In other words, the InfoCard system has no theoretical bias about what information should be asked for when.  Through the Laws of Identity we have tried to help people understand that they should only ask for what they need to complete a transaction and should only keep it for the length of time they absolutely must. 

In particular, there should be no hoarding of rainy-day information – information that “might come in handy” some day – but which is more likely to turn into a liability than into a benefit.

Do your risk analysis 

You'll need to do the conventional risk analysis and think about whether it is more dangerous to store the information or just ask for it on an “as-needed” basis and then forget it.  My personal sense is that it is more dangerous to store it than to use an on-demand approach. 

A central machine with the stored information that animates a successful internet business is a honeypot.  It could well be subject to insider attacks, and certainly, since it lives on the internet, will be subject to many attacks on the information it stores.  Why not avoid these problems completely?

Certainly, the on-demand approach has benefits in convincing customers and legal practitioners that, having held no identity information, you cannot be seen as being responsible for an identity meltdown.  To me this is very attractive, and something that has not been possible until now.

Conclusion

The examples Eric gives of things that can go wrong seem to me to apply even more strongly if you have stored information locally than if you ask for it on demand.

But as I said earlier, this just expresses my thinking – there is lots more to be written by Eric and hundreds of others as they develop applications. 

Meanwhile, InfoCard has no built-in assumptions around this and can be used in whatever way is appropriate to a given situation.

 

Podleaders Interview for those new to the Laws

Tom Raftery at http://www.podeladers.com/ interviewed me recently for his PodLeaders show (42 mins 15 secs).  Here is his description of what we talked about:

My guest on the show this week is Kim Cameron. Kim is Microsoft’s Identity Chief and as such is responsible for developing CardSpace – Microsoft’s successor to the much reviled Passport. Kim elucidated the Seven Laws of Identity and is developing CardSpace to conform to those laws. If he manages this, he will have changed fundamentally how Microsoft deals with people.

Kim is also responsible for Microsoft recently releasing 35 pieces of IP and promising to never charge for them.

Here are the questions I asked Kim and the times I asked them:

Kim, I introduced you as Microsoft’s Identity Chief, what is your official title in Microsoft? – 0:35

What does the Chief Architect of Identity do in Microsoft? – 01:02

Why is it necessary to have identity products in software? – 01:29

How do I know who I am dealing with on the internet? How is that problem being solved? – 03:56

And you as Microsoft’s Identity Architect are coming up with a way to resolve this called CardSpace… – 07:08

You were saying CardSpace is to be platform independent, I run a Mac, will it run on the Mac? – 15:26

You mentioned a couple of companies, are the offerings from these companies going to interoperate or are we going to have another version of the VHS/BetaMax wars? – 17:45

Audience questions
Rob Burke

Perhaps more than any of the other Vista-era technologies, in order to really catch on, CardSpace requires broad cross-platform adoption. Kim personally is doing a lot to showcase the use of CardSpace’s open standards. What does the broader effort to engage with other platforms and communities look like, and how is CardSpace being received? – 21:10

CardSpace uses an intuitive wallet-and-credit-card metaphor. One of the features of a wallet is that it’s portable – I several pieces of identity with me at all times. I tend to move between computers a lot. What provisions are there in CardSpace for helping me keep mobile (in a secure way)? – 25:07

What happens if your laptop containing your InfoCards gets lost and/or stolen? – 28:00


Dennis Howlett

What’s cooking on the identity managemnt front at MSFT? We’ve been hearing about this on and off for a while – we need progress if we’re not to be weighed down byt having to remember so many usernames and passwords for the servics we consume. – 30:35


My questions again:

Will there be a lot of re-engineering of web apps required to roll out these technologies? – 34:03

And finally you mentioned that this is the first version what can we expect in the next versions and when will they be released? – 39:58

Download the entire interview here
(19.3mb mp3)
Let me make one thing clear about Microsoft's Open Specification Promise: many people were involved, and Microsoft's legal people, along with their colleagues representing open source thinkers aned companies, deserve all the credit. 

Check out the other interviews on the site (I think I'm number 48).  Doug Kaye was number 47, and there are lots of good things to listen to while on the treadmill (physical or metaphorical).

 

Ping unveils Managed Card IP written in Java

Ashish Jain of Ping Identity seems to have broken another barrier by demonstrating a “managed card” identity provider written in Java.

In the world of InfoCards, we talk about two kinds of “identity provider”.  One is a “self-issued” card provider, through which individuals can make claims about themselves.  The other is a “managed” card provider, which supports claims made by one party about another party. 

Examples of managed card providers could include claims made by an employer about its employees; a financial institution about its customers; an enterprise about its customers; or a reputation service making claims about its users.  While the technology for posting tokens from an identity selector like Cardspace to a web site can be very light weight (RESTful), that for building managed card providers is more challenging.

Here's how Ashish puts it:

The Managed Card IdP as well as the RP server that we demonstrated at DIDW is now available for a test run. It’s still early access…so expect some issues. But if you do want to try early, give it a go. It should give you an idea of the things to come.

baby_beer400x299.jpeg

Please do the following (you need to have RC1 client installed on your machine).

  • Access the IdP Demo here.
  • Enter your information and click ‘Get Card’.
  • When the popup happens, click “open” to save it to the CardSpace Client. Alternatively, you can save it to the disk and double-click to install it. (You can change the extension from .crd to .xml if you are interested in looking at the contents).
  • Close the CardSpace Client.
  • Next go to the RP site here.
  • Click on the Managed Infocard Image.
  • Your CardSpace client should pop-up at this time and only the relevant card should be available for selection.
  • Select the card and it will challenge you to enter your IdP credentials. The server doesn’t perform any password validation at this time (as long as the username is correct).

And you should be logged in to the Relying party. The relying party page also displays the IdP as well as the RP message flow.

I tried it and it definitely worked for me.  I'll do a screen capture.

I don't know if the picture in Ashish's piece shows something he drank as a baby, but if so, a lot of other programmers may want to try some. 

 

DasBlog site InfoCard enabled

Of course Kim Cameron's Identity Blog has been InfoCard enabled for a while, and I've written about the process.  Now others are working (more on this later) to produce a WordPress InfoCard Plugin for everyone who wants to start accepting InfoCards.

Then a while ago I learned that Rob Richards had InfoCard-enabled his Serendipity-based blog and again published the code for others to examine.  

Now Kevin Hammond has done the same for DasBlog – though I'm not sure yet if I can leave comments using InfoCards:

Taking inspiration from Kim Cameron and how he CardSpace-enabled WordPress, I did the same with DasBlog 1.9.6264.0. casadehambone.com now supports logging into the administrative account using Windows CardSpace allowing me to throw the use of passwords to the wind!

The great thing is that it only took minor changes to three source files and the introduction of one new configuration option each to site.config and siteSecurity.config. I have a little more work before me to make configuration just a tad easier, but the great thing is that this works really well.

I owe special thanks to Clemens Vasters who suggested this morning that the proper “hack” to get this working was to build DasBlog with Visual Studio 2005 and the Visual Studio 2005 Web Application Project add-on. DasBlog built out-of-the-box without issue, making the integration of TokenProcessor.cs to decrypt the SAML token a piece of cake.

If you haven't looked at Windows CardSpace yet, head on over to cardspace.netfx3.com and start reading. Now that Windows Internet Explorer 7.0 is released and Release Candidate 1 of .NET Framework 3.0 is available, you'll find the mainstream barriers to adoption are quickly eroding.

I hope Kevin also publishes his code so others can learn from it.

Serious cardmaking

Kevin Hammond ups the ante on how to put a graphic on your infocard.  His reference to my card makes me blush – I just “borrowed” a graphic that had been assembled by one of the computer journals, not having any idea of how one would make it.  One day I'll find the time to play with the cool technology he is talking about.

There's a lesson here though.  When people start hand-tailor their cards, it becomes impossible for “phishing software” to successfully perform social engineering attacks that trick people into thinking a fake CardSpace interface is real.  The phisher has no idea of what kind of graphic or what kind of photo the user has created – so it just can't do a believable impersonation.  The result is that the user immediately recognizes something is very wrong.

I've been getting my feet wet with Windows CardSpace and my self-issued card. In watching Kim Cameron's demonstration of how he integrated CardSpace with WordPress, I saw his nifty looking card with his portrait on it. Right then and there I decided I too must have one. What do you think of the results? Here's how I did it.

I made a self portrait with my Canon EOS 20D and an EF 50mm f/1.8 II lens.  I extracted the headshot with Photoshop CS2’s Extract filter, did some complexion touch up and resized it to what you see here, about 60×64 at the shoulder. I created a new 120×80 image according to the guidance provided by Vittorio Bertocci in his great article about how images are mapped onto cards. From here, it's all a composite. There's a layer for the black rectangle across the bottom, a layer for the gradient background, a layer for my portrait, and a layer each for the text. It took some experimenting with fonts and text transformation to arrive at the setting you see here – by far the largest part of this entire exercise. My Layers palette is reproduced here for your reference. Frankly, I'm surprised by the result because I'm by no means a Photoshop guru. But I think I now have something cool to liven up casadehambone.com with!

Vista does one annoying little thing in the reflection it places on the top third of the card when it renders it within the Windows CardSpace UI. I can see how they're trying to be cool, but I think it detracts rather than adds to the overall experience.

Rob Richards and a new WS-Security / InfoCard code base

Over the last while I've been lucky enough to have some conversations with a php web services guru from the northeast called Rob Richards.  He asked some very good questions about self-issued identities, which I wrote up and will be posting, and also answered a number of my questions about PHP. 

Besides being prolific and modest he kind of won my heart through a posting called I asked for a beer,  The photo at right shows what he got instead – city people, that is a bear, not a dog – and the story reminds me of all kinds of personal episodes too crazy for me to even think about at this stage.

But that's not the point.  He's been quietly doing amazing work that again shows how close we are to getting ubiquity with progressively more robust identity technology. 

Here is a posting that refers to slides from some talks he did at PHP|2006 in Montreal. 

The first was called Advanced XML and Web Services (with accompanying code), while the second was a good overview of XML Security that is so up to date it even covers Information Cards in excellent detail.

But wait, folks.  That's not all.  There's also the code base.  And the fact that he has InfoCard-enabled his Serendipity blog.

For the XML Security session, what people are probably most interested is the code used to implement WS-Security and possibly Infocards using PHP.

Security Library – Base XML Security library implementing XMLENC and XMLDSig functionality.
WS-Security library – WS-Security library for use with SOAP. Currently only implements client functionality and is missing the ability to encrypt SOAP data.
Example Usage of WS-Security – An example of interacting with the Amazon Elastic Compute Cloud (Amazon EC2) SOAP Service. Easily re-factored for use with other services requiring WS-Security.
Infocard Library – Base library for processing infocards.
Infocard demonstration – Demonstration of processing a submitted Infocard. The result is a SAML token along with a function to view submitted assertions. The form has NOT been updated to work with the recent namespace change, so modify the requiredClaims for use with IE7 RC1, Vista RC1 or .NET 3.0 RC1.

These libraries and examples contain unmaintained, yet useable code. They were developed only for testing while designing an API for C based code and most likely any extensions developed to perform the functionality will differ from the code provided here. There are many optimizations that can be made to provide better performance, so feel free to make any modifications you like. I may provide updates in the way of bug fixes if needed and might extend them a bit more if so inspired (such as adding encryption to the soap client or possibly handling of ws-security on the server side), but if anyone wants to take the code and run with it, please let me know as I would gladly provide help (time permitting).

It's really interesting to hear Rob is working on ‘C’ code as well.

Whobar identity 2.0 technology now available as open source

Not only does Whobar support InfoCards and related identity technology, but check this out:

Sxip is pleased to release the Whobar code to the community.

Whobar makes it easy for users to register and login to a website using their choice of emerging identity protocols such as InfoCard, i-names, and OpenID. It enables developers to easily add support of all these emerging Identity 2.0 technologies to their site. The benefits of this for users is a common website login experience. For web developers, to streamline their user registration and login process so that they don’t need to store user passwords, nor users needing to remember yet another password, thereby improving site conversion ratios. Future releases will also allow users if they so choose, release data about themselves with a single click.

Given the interest shown at the recent DIDW and Future of Web Apps conferences from Phil Windley, Rafe Needleman, and others in the community, we’ve made the Whobar technology available as open source. Whobar is written in PHP, but works like a proxy, so that the web application can be in any language. However, we’ve also been contacted by several developers interested in contributing a port to C#/.NET so stay tuned for additional modules. If you’re interested in getting involved, please check out our contributing page.

Congratulations to the SXIP team.  When I saw this at the DIDW conference I thought it was amazing.  I'll do a video capture over the next few days so those who haven't downloaded Cardspace or a Chuck Mortimer / Ian Brown identity selector can see what it's all about.

New features added to Safari InfoCard plugin

Ian Brown continues to add features to his proof of concept InfoCards for Safari, and has software that will definitely get you into my blog to leave comments.  He points out that his identity selector still needs a number of features, but as Jon Udell has said, Ian's work is absolutely cool.  It's not taking anything away from Ian's accomplishment to say it should inform everyone's thinking about the fact that there is not a huge barrier to entry for this technology.  It can be deployed cross platform, and is eminently buildable.  To quote Ian: 

For the faint of heart, or for those running those other operating systems, here's a short screencast of the selector in action, authN'ing against Kim Cameron's RP

click to download movie

 

Download the plugin for the Power PC here.

Download the intel version here.