BBAuth and OpenID

From, here's a thoughtful piece by Verisign's Hans Granqvist on Yahoo's BBAuth:

Yahoo! released its Browser-based authentication (BBAuth) mechanism yesterday. It can be used to authenticate 3rd party webapp users to Yahoo!’s services, for example, photo sharing, email sharing.

Big deal, huh?

The kicker is this though. You can use BBAuth for simple single sign-on (SSO). Most 3rd party web app developers would love to have someone deal with the username and password issues. Not storing users’ passwords mean much less liability, much less programming, much less problem.

Now Yahoo! gives you a REST-based API to do just that.

It will be interesting to see how this plays out against OpenID.They are both very similar. Granted there is some skew: OpenID is completely open, both for consumers and providers of identity.

However, from my own experience, OpenID consumers (a.k.a. relying parties) seem to want only one thing, perhaps two or three:

  • have someone deal with your users’ passwords,
  • retrieve name and email address for a user

And now Yahoo! does the first, and the second is available. At the same time they’re making your app reachable to 257 million+ users. Here’s an example.

Seems a pretty big reason to implement it for the web app developer, especially since it is such an easy API you can integrate it in an hour or two.

And yet someone has added a sobering comment to Hans’ blog:

It will be interesting to see how long it takes for adoption to reach the point that no one thinks twice when a yahoo login pops up on another site. They'll be nice and ripe for password harvesting via fake yahoo login forms then. :)

Sadly, if I had written this comment I would not have included the happy face. Until the security concerns are addressed, despite Yahoo's very laudible openness, this is not a happy face moment.

But through Yahoo-issued InfoCards BBauth would avoid the loss of context that will otherwise lead to password harvesting.  It's a good concrete example of how the various things we're all working on are synergistic if we combine them.


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.

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.


Where is the digital you?

I don't think anyone could have expressed the big metasystem issues better than Red Hat's Pete Rowley does here:

There has been a lot of focus on user-centric identity in recent months, but let us not forget about the identity metasystem. The identity metasystem concept is important because it recognizes that even if it is desirable for there to be one protocol that everyone speaks, to get there from here requires a pragmatic acceptance that there will be more than one protocol in the meantime. While choice is a marvelous thing in many situations, it isn’t something that the vendor relishes at the protocol level. When the customer comes calling must you turn them away because they speak OpenID and your software speaks SAML? Recalling my blog regarding the Microsoft Open Specification Promise, multiple standards mean your bolts don’t fit your nuts unless you buy them both from the same vendor. The identity metasystem must provide the necessary adapters so that different systems produced by different vendors on different platforms can at least understand each other, even if they don’t speak the same language.

One might ask who will be building the parts that make the system a metasystem. Clearly, one vendor who is doing that is Microsoft with CardSpace. However, one vendor a metasystem doesn’t make. To make the identity metasystem a reality it must come from multiple vendors, it must be ubiquitous, and it must be in the DNA of the platform. This is why open source efforts such as the Higgins project are so important, because they provide the means to make the identity metasystem cross-platform, cross-vendor, and cross-identity context. This might be considered the primary focus of the OSIS project as a whole – to make the identity metasystem happen. Red Hat supports the efforts of these projects and any project that works to make the identity metasystem a reality.

The correct answer to the question “where is the digital you?”


It brings us back to Craig Burton's reggae tune: “I cry Ubiquity”.

Jamie Lewis on Open Specification Promise

The Burton Group's CEO, Jamie Lewis, discusses the OSP and what it means for the identity community: 

As has been widely reported, Microsoft announced its Open Specification Promise last week. A lot of folks have already posted about it (see here, here, and here ). But, given the overall importance of the announcement to the identity community, I wanted to make our thoughts on the subject known, and to give credit where it’s due. (Note: This entry is cross posted at both my blog and our new Identity and Privacy Strategies blog.)
In summary, Microsoft has decided to offer the Open Specification Promise (OSP) for the Web services protocols that support CardSpace in particular, and the InfoCards architecture in general. The OSP provides an alternative to Microsoft’s “reasonable and non discriminatory/royalty free” (RAND/RF) licensing agreement, which most open source developers didn’t like. As I understand it, the OSP essentially provides an assurance that Microsoft won’t sue anyone implementing the specifications covered by the document. So developers don’t even have to agree to a license; they can implement the covered specifications without fear of being sued. (With certain, mostly comprehensible exceptions.)

Before I comment on the OSP, however, let me first provide the disclaimer almost every technologist I talk with about licensing issues gives me: I’m not a lawyer, and so my comments should in no way be construed as having legal weight. (If you’d like to see an analysis of the OSP document from a legal perspective, see Andy Updegrove’s excellent post from last week.) But Microsoft’s announcement has more than legal ramifications. Microsoft’s move could have a significant impact on the market, and that’s where we come in.

In short, the OSP is a significant, positive step forward for both Microsoft and the community working to create a better identity infrastructure for the Internet. The people who have been tirelessly advocating the move within Microsoft deserve an enormous amount of credit for making it happen. (Kim Cameron deserves some special recognition at this point in what has been a long process.) At this, point, one of the most significant obstacles to widespread development around the InfoCard architecture has been removed, and that’s good news for everyone involved.

Some Background

I’ve been following the InfoCard effort for a long time with a great deal of interest, primarily because I’ve always thought it was a great idea. But I also had some concerns about how it would be received in the market, at least early on. Circa 2002, it was fair to say that, given Microsoft’s history, any idea the company put forward for addressing the identity problem—regardless of its merit—would likely meet large amounts of skepticism and, at least in some cases, outright resistance from many market players.

From the first time he ever spoke with me about the functionality we now know as CardSpace, for example, Kim has been consistently insistent about the need for and importance of cross-platform support. I certainly agree that a consistent user experience—regardless of the operating system and device a person chooses to use—is profoundly important to addressing the identity problem. But I’ll have to admit that I wondered many times if Microsoft would really let Kim do what he thought needed to be done. And as I talked with other folks about InfoCard as the concept began to take shape, I heard more than a few people express varying degrees of skepticism about Microsoft’s true intentions or Kim’s ability to convince the powers that be to move in a more open direction.

But by decidedly atypical and relentless means, Microsoft has done a great deal of what seemed nearly impossible only a few years ago, overcoming the skepticism and building good will. Consequently, there is a palpable and sincere desire on the part of a lot of people to implement the InfoCard technologies. And three or four years ago, many of these people wouldn’t have even considered working with Microsoft on a beer run, much less an identity system.

Still, licensing was a huge obstacle to seeing that good will and intention translated into demonstrable action and working code. With only a few exceptions, everyone I talked to over the last six months or so—from open source developers to commercial software companies—indicated that until the licensing issue had been put to bed, they really couldn’t (or wouldn’t) build anything. And they had a point. Were I in their shoes, I would insist on clear licensing terms as well.

Enter the OSP

With the OSP, then, Microsoft has taken what is for it a bold step, removing one of the most significant obstacles to widespread InfoCard development. The OSP makes it clear that Microsoft isn’t laying some elaborate and sinister trap for everyone, that it truly is offering something of significant value to the industry and a huge opportunity to developers looking to build better identity management systems.

Yes, there are still some details to work out (I’ll get to those in a moment). And yes, neither CardSpace nor InfoCard’s supporting system are slam dunks in today’s transitional market place. But the OSP is concrete evidence that even those with valid reasons to doubt Microsoft’s sincerity are running out of excuses for ignoring InfoCard. Without it, the overall InfoCard effort was stymied. With it, the InfoCard effort can move forward in the way Kim has always intended. And for that both Kim and Microsoft deserve recognition and gratitude.

About Those Remaining Issues Several folks have commented that it’s not just the specifications that matter, but the implementation details. And they’re right. (While I’ve heard similar things from a few people, most of these issues are summarized in the Higgins project’s draft response to the OSP.)

Microsoft has published an implementation guide for CardSpace, but the details it includes on how to implement the specifications covered by the OSP aren’t covered by the OSP. (You can find the guide, as well as other details on implementation, on MSDN.) In particular, there are schema and meta-data models that are crucial to getting what Paul Trevithick calls “functional equivalence” with CardSpace on other platforms. The CardSpace user interface is an equally important issue. While efforts like the Higgins Trust Framework may not copy the CardSpace UI down to every pixel, interoperable implementations must emulate the basic sequence of events in the CardSpace interface (what Kim Cameron has called “ceremony”) if we’re to get the common user experience to which Kim aspires. These implementation details must be covered by the same kind of promise.

But if Microsoft can accomplish what’s embodied in the OSP as it now stands, then it seems reasonable to assume that what remains is haggling over details, that the licensing issue is finally on a downhill path. In other words, the fat lady has sung, and we’re just waiting for the coda. And now the onus has shifted to those who have professed a willingness to implement InfoCard technologies and interoperate with Microsoft if the licensing details could be favorably resolved. Microsoft is living up to its end of the bargain, and now it’s your turn. Those who’ve already started development, without waiting on the licensing issues, have some advantage. My advice to those who have been waiting? Get busy.

Identityblog and your identity information

Matt, a reader who downloaded Ian Brown's early version of Information Cards for Safari, wrote to me with the following question:

I just signed up to your identity blog using the Safari CardSpace selector you mentioned on your blog.

I'm interested to know whether the (genuine) identity data in my CardSpace selector (populated out of my Address Book entry I think) is transmitted to you, if it is where it is stored, and what is done with it and to protect it.

Matt is unclear about what information he has sent to Identityblog because the Safari and Firefox user interfaces don't yet deal with displaying what subset of the information in a card is being asked for by the site he is visiting. 

That's because the current versions are very much prototypes and works in progress.  As Ian says on his blog:

This is currently still at the proof of concept stage, and is lacking most of the features found in the official CardSpace selector from Microsoft.

This being said, I have verified that the demo Firefox selector only releases required claims, and I'm pretty sure the Safari selector follows suit. 

The current Cardspace interface design was refined through ongoing “usability work” in which we encountered this kind of confusion and explored (and measured the efficacy of) different alternatives for avoiding it.

As a result, when you release any new information to a site within Cardspace you see a screen like this one:


It doesn't matter whether a user has filled out other fields in their chosen Information Card.  Only the fields asked for by the site will be presented for approval.  Then the user can decide whether to proceed or not.

On subsequent visits to a site, the information release screen is not shown by default.  The thinking is that once information has been released once, it forms part of the “contract” between the user and the site.  If we were to ask the user to “approve” the release time after time, the release page would become nothing more than a “click through page” – meaning the user wouldn't even “see” it.

As for what I store, my approach is to ask for as little information as I can. 

I request an email address so I can verify that you are not a spammer, and so you can change your infocard by using the email address as an “alternate authentication channel” (more on this in a future post).  I'm working with some friends on a version where we won't store the actual email address – we will use a hash of it instead so we can recognize you but not expose your address to possible breaches.

I also store what you've given me as a first and last name because WordPress uses that to show who has written posts and comments.  I will eventually change this so I only store your names once you have written a post or comment (i.e. done something ‘public’).


Mortimore publishes code for managed information cards

Amazing news from Chuck Mortimore at – source for java-based managed cards:

I've just checked in code that can create Managed Cards that import into CardSpace RC1.

To allow people to play around, I've also added a quick little web app, which creates cards for you. You can try this out at:

If you'd like to try it out, you can download the source from


InfoCards for Firefox users

From Chuck Mortimore at

It sounds like Craig Burton has been having trouble with the demo Cardspace Selector I put together for Firefox. I'm not sure what trouble he's been having, but I thought I'd toss up some quick instructions, and a screen cast.

Step 1) Make sure you're on Firefox 1.5 or greater.

Step 2) Make sure you've got J2SE 1.4x installed on your machine. The xmldap selector doesn't use any .net or Microsoft code…its a cross platform implementation written from scratch in Java. You can hit if you need to download a JDK

Step 3) Go to and download the Firefox extension. You may need to allow the popup blocker to trust my site. Restart firefox.

Step 4) Go to a Cardspace enabled site like xmldap, identityblog, or ping

Step 5) Click to login, create a card, and submit.

Note that you'll still get a warning saying: “Additional plugins are required to display all the media on this page” Ignore it…I haven't figured out how to make it go away yet. Please email me or comment if you know!

Craig and others – email me at cmort at if you have questions or issues!

When I tried it I was using an earlier version of Firefox and had no luck – so make sure you get onto Firefox 1.5 or later.

By the way, this is a must-see demo not only for its general coolness, but for the special coolness of its sound track.  It's really a wonderful, no-nonsense piece of work.

First Information Cards for Safari

click to download movie One of the best moments of the DIDW show, for me, came when Ian Brown, an old friend of Chuck Mortimore, showed us his Identity Selector for Safari.

If you don't know Chuck, he single-handedly wrote a Java-based InfoCard Identity Selector that runs inside Firefox on almost any platform.  He gave me a copy, helped me install it on my computer, and it all just works.

Later I'll do a screen capture of Chuck's work since i can run it on my own machine. 

But I don't currently have a Mac – so Ian succumbed to my goading and put together a little video so you could see what he's working on.

That's such good news.  As he says, “For the faint of heart, or for those running those other operating systems, here's a short screencast of the Safari identity selector in action, authN'ing against Kim Cameron's RP…”

Meanwhile, here's what he says about the actual plugin:

This is currently still at the proof of concept stage, and is lacking most of the features found in the official CardSpace selector from Microsoft. At present, only a single self-asserted card can be selected. The “selector” will currently pull the logged in account's personal information from the AddressBook application, and allow you to use that AddressBook entry as a self-asserted InfoCard with various RPs. It should work with existing installs of Safari, and with most relying parties.

The plug-in itself is a wrapper around Chuck Mortimore‘s Java implementation of an InfoCard token generator. For those of you out there using Firefox, check out Chuck's cross-platform Firefox InfoCard selector.

So download the Safari Plug-In below and give it a spin. Send me any feedback at igb at

I'll post new releases here as features are added and bugs are fixed.


Currently there are two versions, one for the new Intel-based Apple's, and one for the PowerPC-based machiines. At some point I'll figure out how to get XCode to generate a Universal Binary. (I suppose the PowerPC build might work on the Intel Macs, that's what Rosetta is all about right? But it hasn't been tested on the Intel arch, so YMMV.)

Intel version
PowerPC version


Installation is pretty simple. After downloading the ZIP file, extract the archive. You should now have a file called InfocardPlugin.bundle. Just copy that to the Library/Internet Plug-Ins directory under your home directory. restart Safari, and off you go.

Despite Ian's self-depricating style I think what he and Chuck are doing is amazing.  And it shows what can and will be done.  Meanwhile, Apple People, download Ian's plugin and leave comments on my blog.

Phil Windley at DIDW


Phil Windley at ZDNet has been blogging the DIDW conference, and captures a bit of it here:

This evening, at the reception for Digital ID World, someone asked me what I thought of the conference. I've been to every DIDW since it started (5 years now). I realized that the conversations and talks had changed from “won't it be cool when we…” to “this is what we did to…” That's a big change and shows just how far identity, as a concept separate from security, has come.

At the same time, I look around the show floor and other than the usual big names like Microsoft, Novell, and Oracle there are few repeat companies. Ping and a few others have been here from the start, but most seem to come and go. Part of that's because any company that gets successful gets bought by one of the big guys looking to build out their stack.

One of my favorite sessions today was Dave Nikolesjsin's presentation on citizen-centric identity. Nikolesjsin is the CIO for the Prov. of British Columbia. BC is making real progress building identity systems that have been proofed by in-person visits to government agencies. There are lots of lessons in what BC is doing–not just for other governments, but for any large organization.

The most significant announcement of DIDW was Microsoft's Open Specification Promise. For years, there's been an intellectual property cloud hanging over the OASIS specifications that form a large part of what makes Web services work. Unlike other standards bodies, OASIS doesn't require that technologies built into its specifications be IP-free.

Today's announcement is a huge step by one of the major contributors to the OASIS specifications. Microsoft irrevocably promises not to assert claims against people or companies who distribute products that conform to the specifications. Of course, like any legal agreement, there are terms and conditions. I'm sure some will be waiting to see what isn't there.

Since many of these specifications are at the heart of CardSpace, Microsoft's Internet-scale identity system, the announcement is especially important to other vendors working to interoperate with it. This is also important to Microsoft. If no one builds interoperable identity products for CardSpace, Microsoft will have failed to achieve true Internet-scale identity. Removing the legal threat is an important enabler.

More at Phil's blog here.