Bandit and Higgins hit interop milestone

I was so snowed under trying to work against time for the OpenID annoucement at RSA that I missed blogging another imporant milestone that has been reached by the identity community.  This report on progress in the Higgins and Bandit side of the house is great news for everyone:

The Bandit and Eclipse Higgins Projects today announced the achievement of a key milestone in the development of open source identity services. Based on working code from the two projects and the larger community of open source developers, the teams have created a reference application that showcases open source identity services that are interoperable with Microsoft’s Windows* CardSpace* identity management system and enable Liberty Alliance-based identity federation via Novell® Access Manager. This reference application is a first-of-its-kind open source identity system that features interoperability with leading platforms and protocols. This ground-breaking work will be demonstrated at the upcoming RSA Conference in San Francisco.

“There are two basic requirements for translating the potential of recent identity infrastructure developments into real-world benefits for users: interoperability and a consistent means of developing identity-aware applications,” said Jamie Lewis, CEO and research chair of Burton Group. “First, vendors must deliver on their promise to enable interoperability between different identity systems serving different needs. Second, developers need a consistent means of creating applications that leverage identity while masking many of the underlying differences in those systems from the programmer. The Bandit and Eclipse Higgins interoperability demonstration shows progress on the path toward these goals. And the fact that they are open source software projects increases the potential that the identity infrastructure will emerge as a common, open system for the Internet.”

The Bandit and Higgins projects are developing open source identity services to help individuals and organizations by providing a consistent approach to managing digital identity information regardless of the underlying technology. This reference application leverages the information card metaphor that allows an individual to use different digital identity ‘I-Cards’ to gain access to online sites and services. This is the metaphor used in the Window’s CardSpace identity management system that ships with the Vista* operating system.

“Windows CardSpace is an implementation of Microsoft’s vision of an identity metasystem, which we have promoted as a model for identity interoperability,” said Kim Cameron, architect for identity and access at Microsoft. “It’s rewarding to see the Bandit and Higgins projects, as well as the larger open source community, embracing this concept and delivering on the promise of identity interoperability.”

The open source technology developed by Bandit and Higgins enables initial integration between a non-Liberty Alliance identity system and a Liberty Alliance-based federated identity system provided by Novell Access Manager. Specifically, these technologies enable Novell Access Manager to authenticate a user via a Microsoft infocard (CardSpace) and consume identity information from an external identity system. It will further show that identity information from Novell Access Manager can be used within an infocard system. This is a significant step forward in the integration of separate identity systems to deliver a seamless experience for the user as demonstrated by the reference application.

“The Liberty Alliance project fully supports the development of open source identity services that advance the deployment of Liberty-enabled federation and Web Services as part of the broader Internet identity layer,” said Brett McDowell, executive director of the Liberty Alliance. “The open source community’s embrace of Liberty Alliance protocols is validation of the benefits this technology provides, and we salute the Bandit and Higgins teams for their role in making the technology more broadly accessible.”

Higgins is an open source software project that is developing an extensible, platform-independent, identity protocol-independent software framework to support existing and new applications that give users more convenience, privacy and control over their identity information. The reference application leverages several parts of Higgins including an identity abstraction layer called the Identity Attribute Service (IdAS). To support a dynamic environment where sources of identity information may change, it is necessary to provide a common means to access identity and attribute information from across multiple identity repositories. The IdAS virtualizes identity sources and provides a unified view of identity information. Different identity stores or identity management systems can connect to the IdAS via “context providers” and thus provide interoperability among multiple systems.

“Many groups have been working towards the goals of Internet identity interoperability,” said Paul Trevithick, technology lead for the Higgins project. “This milestone represents a major step in having multiple open source projects work together to support multi-protocol interoperability.”

The Bandit project, sponsored by Novell, is focused on delivering a consistent approach to enterprise identity management challenges, including secure access and compliance reporting. The Bandit team’s contributions to the reference application include the development of multiple “context providers” that plug into the Higgins Identity Attribute Service (IdAS) abstraction layer to provide access to identity information across disparate identity stores. It also showcases the role engine and audit reporting capabilities in development by the Bandit community.

“The development of this reference application would not have been possible without the collaboration and contribution of the wider Internet identity community,” said Dale Olds, Bandit project lead and distinguished engineer for Novell. “This is the first of many milestones we are working towards as both the Bandit and Higgins communities strive to enable interoperable, open source identity services.”

So congratulations to Bandit, Higgins and everyone else who made this happen – this is great stuff, and the identity big bang is one step closer for it.

Creating test certificates

Once you have a Certificate Authority, you have a factory for producing certificates.  This will let you mint test certificates for your InfoCard relying party (they will also work should you want to experiment with being a managed card provider).

The gotcha is that before they will work on a machine, they have to be hand-installed.  Why?  They have not been issued by the widely distributed trust root authorities shipped with Window,  Macs, and Linux.  Thus they don't work “out of the box”.  That's why you need for the installation step.

The result is that while perfect for testing and experimentation, these certs won't work as production certs in the real world.   There you'll have to go to a commercial provider.  But this won't break the bank.  My identityblog cert costs quite a bit less $2.00 per month.

We'll deal with this issues in another part of this guide.  For now, let's turn to using your factory to create a test cert.

Create a Certificate Request for your machine

Change directory to the “openssl/democa” directory you made earlier.  Run “makereq” to generate a machine SSL key and corresponding certificate request. This time the system will ask for a passphrase to protect the SSL key for which the cert is being requested. In other words, this is a different key, cert and passphrase combination than you used with the Certificate Authority.

When running the script, enter a simple DNS name as the CN (hostname) field.  In my case, for example, I used as the CN. Don't use the http:// prefix or nothing works!

makereq screenshot

After running the script, the machine's private key will be written to democa/keys/privkey.pem. Meanwhile a certificate request will be placed in democa/requests/cert.csr.

Create your Certificate

Next, run “makecert” – which puts the certificate request from the last step into the Certificate Authority (i.e. factory) to produce a certificate. You'll be asked for the CA's passphrase:

makecert screenshot

When this is complete, the cert has been created, and is in “democa/certs/cert.crt”.

If you want to use the cert within IIS

If you want to use the cert in IIS, run “makep12” and get ready for a final conflagration of passprases. This script combines your private key and cert into a single “.p12” file that can be installed as a windows machine cert. To do so it performs a format translation. You will have to supply the machine key's passphrase to decode the “.pem” formatted file so the translation can proceed. Then you will be asked for an export passphrase (the one used to protect it in the new p12 format). I always use the same passphrase – who cares what format the information is in?

makep12 screenshot

“makep12” puts the combined Windows key/certificate file in “democa/keys/iiscert.p12”

Now your openssl machine key is in “democa/keys/privkey.pem”. Your machine cert is in “democa/certs/cert.crt”. Your IIS key/cert combination, if you made one, is in “democa/keys/iiscert.p12”.

Moving the files into the “keys” directory

To use my sample managed card code, create a “keys” directory under your http server's root directory. Move the privkey.pem you just created into “keys/host.key”. Move the cert you just created into “keys/host.crt”. Create a file called “keys/host.pwd” and put the machine key's passphrase into that file. Then the scripts I provide should work with your newly created keys and cert.

Follow instructions elsewhere in this guide if you want to install the combined p12 key into Windows and IIS.

What if you want more certificates?

You've got a certificate factory now, and can make as many certs as you like by going back to the “Create a certificate request” step and running through the process again.


Creating a Certificate Authority for Test Certificates

You can use any Certificate Authority (CA) to create test certificates.  This description is intended for people who don't have a CA.  It tells you how to create test certificates that can be used when developing CardSpace relying parties and managed card services.  Since CardSpace is part of a wider WS-Trust and InfoCard ecology, the same certificates will work with other software being developed within the cross-platform identity metasystem.

This recipe uses OpenSSL since it is available on virtually every platform and well suited to a test environment.  I'm assuming people with Microsoft Certificate Server already know how to produce certificates.  Later in this series I'll explain how to produce and install high assurance certs.

My goal is to get you past certificate issues with the least muss and fuss.  You should turn to other resources if you want an in-depth background on X509 or a description of how OpenSSL works.

Download OpenSSL and DemoCA

First, you need openssl binaries.  A number of linux distributions have them preinstalled.  If your OS doesn't, visit  If possible find the binary distribution so you don't have to compile anything.  Distributions are posted here.  OpenSSL for Windows is available here.

Once you have your binaries installed, download DemoCA ZIP, which I have produced to accompany this tutorial.  Create a directory which is a sibling of the openssl/bin directory – for example. openssl/democa.  Extract the files from the zip into the directory.  If you are not on Windows you'll have to convert the batch files to scripts of some sort, but this will be totally trivial.

NOTE:  Click to enlarge the images below if you want to see what the scripts output to the screen.  But base yourself on the DemoCA scripts, not just what you see here.

Create a Certificate Authority 

The Certificate Authority is a factory for certificates.  You put a “certificate request” into the factory and out comes a certificate attested to by the factory.  So the first thing you need is the Certificate Authority, which has its own certificate and private key.  

From within the directory you just created, run “createca” and answer the prompts with suitable values (use the defaults I give as a guide).

Create CA screenshot Click screenshot
to enlarge it.


This places your CA certificate in democa/cacert.crt, and stores the corresponding private key in “democa/private/cakey.pem.  The private key is protected by the pass phrase you entered.  Remember this passphrase as your Certificate Authority passphrase.  You'll need it whenever you want to create a certificate.

Examining your CA certificate

You can make sure the certificate is correct by looking at it on a Windows box.  Double click on the cacert.crt file and you will see:

Click screenshot
to enlarge it.

You'll see the certificate isn't “trusted” yet.  No problem – it shouldn't be trusted, given that you haven't installed it yet (installation is the indication that you trust it).  We show installation elsewhere in this guide. 

Go to the “Details” pane and highlight “Subject”.  You will see the name of your Certificate Authority.

Click screenshot
to enlarge it.

Finally, highlight “Basic Constraints”.  You should see Subject Type=CA.  If you don't, something has gone wrong – and you don't have a CA cert. 

Click screenshot
to enlarge it.

Configuring IIS to use the machine certificate

 Start up the IIS management console – for example by going to the Control Panel, opening “Administrative Tools”, and the opening “Internet Information Services”.

Double click on your local computer, then “Websites”, and highlight “Default Web Site”

Under the “Action” menu, select “Properties”, and then the “Directory Security” tab:

Click on the “Server Certificate” button and select “Next” when you see the wizard.  Then highlight the “Assign an existing certificate” radio button:

Click “Next”, highlight an appropriate certificate (e.g. the one you just installed), and press “Next” again.

You'll be shown certificate details, and on pressing “Next” one more time you'll be asked to “Finish”.

IIS is now configured to accept your machine certificate.


Converting OpenSSL PEM certificates and keys into a P12 format for IIS

Sometimes you want the same public key and certificate to operate on both *NIX and Windows machines. 

One way to do this is to create your key pair using openssl, obtain a certificate in PEM format, and then use openssl to convert the key and corresponding certificate into a P12 format that can be consumed by Windows.

PEM format is base64 encoded, meaning it is standard text that can be put into an ascii editor like Windows notepad.

Openssl needs you to give it a single file with a “.PEM” extension combining both your certificate and private key.  You do this by cutting and pasting the text from your certificate and private key files to produce a “.PEM” file like this:

Next, use openss to create a “p12” file using the combined “.PEM” file.  The command is shown below.  Assuming your private key is protected by a passphrase, you will first be asked for the passphrase to unlock your “.pem” key, and then asked for another to protect the newly created “p12” file.  (I use the same one to reduce prospects of insanity).

The result will be a “.p12” file that you can install into Windows.


Installing a machine certificate in the Windows certificate store

Our goal is to install a key and certificate that will act on behalf of your IIS server.  So the certificate must be stored in the “local machine” part of your certificate store (as opposed to that belonging to any one specific user)   Here's how do that:

  • Create a console by selecting “Start->Run” and entering “mmc” (or just type “start mmc” from a command prompt.
  • A console will be created, and under the File menu, select “Add/Remove Snap-in”.
  • Select Add, and the “Add Standalone Snap-in” screen appears
  • Select “Certificates” and press the related “Add” button

  • Select the “Computer account” radio button and press “Next”, then “Finish” with the next screen

  • Unwind the dialogs by pressing “Close” and “OK”
  • Open up “Personal” and the “Certificates” as shown here:

  • Then under the “Action” menu, select “All tasks” and then “Import…”
  • “Next” yourself past the first page of the wizard to get to the import menu.  You can just type the path, but if you browse, remember to change the “File Type” to “Personal Information Exchange” or you won't see anything.

  • Press “Next” and you will be asked for the file's passphrase.  Enter it, press “Next” and then accept the default Certificate store with another “Next”.

  • This takes you to the finish dialog, and you end up with a certificate that can be used by the IIS process. 


A Merit Badge That Can't Be Duplicated

From the Los Angeles Times

Boy Scouts can earn badges for woodcarving, raising rabbits and firing shotguns.

But in the Los Angeles area, Scouts will now be able to earn their stripes by proselytizing about the evils of copyright piracy.

Officials with the local Boy Scouts and the Motion Picture Assn. of America on Friday unveiled the Respect Copyrights Activity Patch — emblazoned with a large circle “C” copyright sign along with a film reel and musical notes.

The 52,000 Scouts who are eligible may earn the patch by participating in a curriculum produced by the MPAA. To earn the badge, Scouts must participate in several activities including creating a video public-service announcement and visiting a video-sharing website to identify which materials are copyrighted. They may also watch a movie and discuss how people behind the scenes would be harmed if the film were pirated.

But will the patch be a badge of honor or a scarlet letter of uncoolness?

Richie Farbman, 13, is raring to go, eager to warn others about the dangers of illegal downloading while adding to his more than 20 activity badges.

“I think it's really good to get the message out that it's bad,” said the Redondo Beach Scout. “You can see your friends doing it and tell them why it's bad. I think if you're a role model, you can stop people.”

But Richie said he knew his perspective wasn't shared by many of his classmates. “A lot of people don't think they're going to get in trouble,” he said, “so they do it anyway.”

Other teenagers say Richie and his Scouting buddies face an uphill battle. “Everyone knows it's illegal already, but they do it anyway,” said Kevin Tran, a senior at Taft High School in Woodland Hills. “They can't afford to buy CDs and DVDs, and they see it [on the Internet] for free, so why not do it?”

Officials at the Scouts’ Los Angeles Area Council said they approached the MPAA with the idea nine months ago, emphasizing that the entertainment industry lobbying group did not make financial donations to secure the badge program.

The inspiration for the new badge came from Hong Kong, where the local Boy Scouts organization had its members pledge not to use or buy pirated materials. In addition, the Scouts agreed to search Internet file-sharing sites and turn in sites and users they see violating the law. The campaign was launched at a stadium before a slew of pop stars where the so-called “youth ambassadors” pledged to stem the rise piracy.

The move raised concerns from civil libertarians, who feared the group was creating thousands of young spies to snitch on copyright abusers.

Victor Zuniga, a spokesman for the Scouts’ Los Angeles Area Council, said his group decided on a less aggressive approach: The Scouts won't be asked to police the Internet for pirates.

“Our program is educational,” Zuniga said, adding that the badge probably would be offered elsewhere if was successful here.

Stephanie Scott, a mother of two Boy Scouts, said the anti-piracy badge has something other Scouting activities lack. “This one is tailor-made for the city boy in L.A.,” she said. “Scouts may just as soon go for this one rather than Wilderness Survival.”

MPAA Chairman Dan Glickman said partnering with the Boy Scouts made sense because so much of the pirating was being done by teenagers. “The truth is: So many kids today are savvy with computers and Internet technology and can download anything,” he said.

Although teenagers might roll their eyes at the new badge, some technology-industry analysts said it was a good idea.

“It's actually an incredibly savvy recognition that all the legal and legislative protection, all the technological intervention is clearly not enough to shut dA fown the Internet,” said Eric Garland, an analyst with BigChampagne, which tracks file-sharing networks. “You have to go after the will of the people. Make it an ethical issue.”

But to many teens, it's not so much about ethics as it is money. “Sure [Scouts] should learn downloading is illegal. But if you can't afford to buy it, then they're going to do it anyway,” said Kevin Nguyen, 16, Chatsworth High. “There's no way to control it.”

To quote Slate:

A mom's take: “This one is tailor-made for the city boy in L.A.” As long as the L.A. city boy is an aspiring studio hack.

A friend tells me various youth organizations are working on “Downsizing” and “Outsourcing” badges as well.  The boys have to convince a company of their choosing to adopt a program resulting in a pre-negotiated reduction in salaries and benefits.  There has been talk of offering a supplementary badge for eliminating women staffers.


Cardspace in the enterprise – part .001

Joris Evers at CNET wrote a piece that captures my presentation to the recent Digital Identity World. 

In a session called “Understanding Cardspace in the Enterprise”, Partrick Harding from Ping Identity went through a series of use cases and scenarios at a very practical and convincing level, and then Ashish Jain gave an amusing and clear demo of how Active and Passive technologies could be used together to solve the Enterprise's identity problems.  I'll try to get links to those presentations for the blog.

To build on this at a more theoretical level, I talked about where all of this is going within a longer term perspective, and in terms of fundamental dynamics. 

The main idea I tried to convey was that if we made access control natural and easy enough that everyone could control it – and understand it – we wouldn't need to delegate nearly as much to layers of professional configuration experts as we do today. 

That isn't to say there shouldn't be corporate oversight or purely automated systems, but if the technology works well enough, oversight can be done in as it is in other fields – by setting behavioral procedures and auditing them.

One thing that Joris didn't pick up on – it seems I wasn't clear enough about it – is that I'm not saying we solve all these problems in Vista.  

We make big strides with information cards, but need to get the access control side of things up to the same standard in terms of visualization and natural interface.  So I hope everyone understands I was expressing a vision that we could begin discussing, not doing a sales pitch for a specific product.

By using technology known as Windows CardSpace, formerly code-named InfoCard, individuals in an organization could grant access to outsiders without having to involve the IT department, Kim Cameron, identity and access architect at Microsoft, said in a presentation Wednesday at the Digital ID World Conference here.

“The main role of information cards in the enterprise is to devolve access control to the resource owners,” Cameron said. “Setting access control policies becomes a naturalistic and intuitive and visual process.”

With today's systems, granting a third party access to a corporate resource has become fraught with red tape, stifling business, Cameron argued. With CardSpace, owners of certain information resources at an organization can easily unlock those to specific outsiders by making their own risk assessment, he said.

“My belief is that trust is local,” Cameron said. “Make the granting of access easy enough so that users can do it, albeit under adult supervision.”

Layers of bureaucracy have arisen from the lack of efficiencies in today's identity management technologies, Cameron said. Typically, any kind of access control is handled by a specific department in an enterprise because the technology is very complex, he said.

“Business people can't actually do directly the kinds of things that they want because it is too hard,” Cameron said. “If we continue to organize this by doing it all in a centralized, bureaucratic way, then you end up with solutions that are increasingly complex.”

CardSpace is a component of the Microsoft .NET Framework version 3.0, which was formerly called WinFX. Microsoft has been promoting the technology as a way to make using digital identities easier and safer and replace username and password as the means of verifying identity on the Internet.

Microsoft envisions the use of CardSpace and granting access in Windows Vista to be as simple as using a Word processor. Vista, the successor to Windows XP, is due to be broadly available in January.  (Kim's note:  this is where I want to make it clear that making access control as simple as we've made identity assertion still requires a lot more research.)

“Nowadays nobody has to go and learn how to do word processing; everybody knows how to do it. That is the kind of approach that will allow us to really have secure controlled access that works for business purposes,” Cameron said.

Andy Updegrove on the Open Specification Promise

Readers may be interested in Andy Updegrove‘s analysis of the Open Specification Promise (OSP).  He published it today on Standards Blog.  I'm not a legal expert but found the discussion interesting.  The Standards Blog “examines how standards are developed, and their impact on business, society, the world, and the future.”  Frighteningly, it tells us there are currently over 1,000,000! 

Microsoft has just posted the text of a new patent “promise not to assert ” at its Website, and pledges that it will honor that promise with respect to 35 listed Web Services standards. The promise is similar in most substantive respects to the covenant not to assert patents that it issued last year with respect to its Office 2003 XML Reference Schema, with two important improvements intended to make it more clearly compatible with open source licensing. Those changes are to clarify that the promise not to assert any relevant patents extends to everyone in the distribution chain of a product, from the original vendor through to the end user, and to clarify that the promise covers a partial as well as a full implementation of a standard.

I learned about the new covenant from Microsoft yesterday, which provided me an advance copy of the covenant and the FAQ that accompanies it and an opportunity to ask questions about what it is intended to accomplish. I did have a few requests for clarifications that I'll incorporate below which may resolve some of the questions that might occur to you as well.

Overall, I am impressed with the new covenant, and am pleased to see that Microsoft is expanding its use of what I consider to be a highly desirable tool for facilitating the implementation of open standards, in particular where those standards are of interest to the open source community.

By way of general introduction to those not familiar with this type of mechanism, a non-assertion covenant (also sometimes called a “covenant not to sue”, or in this case, a “promise not to assert”) is at minimum a pledge given by a patent owner that someone that implements a standard will not be sued for doing so by the patent owner, subject to certain limitations. In effect, it is similar to the more traditional promise given by companies when they engage in the development of a standard, but with several important differences:

1. Instead of reserving the right to require each implementer to agree to the terms of a license agreement of the patent owner's choosing, the promise is “self-executing,” meaning that the implementer doesn't have to do anything at all, except stay within the conditions of the covenant. Where, as with the new Microsoft promise, it is explicit that no one down stream need obtain a license as well, a key requirement of many of the most popular open source licenses is met as well.   

2. Unlike the usual promise to license on RAND (“reasonable and non-discriminatory”) terms, where the terms themselves are almost never made public in advance, and often never at all, all of the terms in a non-assertion covenant are out in the open, and apply equally to all. When such a promise is made before the standard is approved, that's even better, because there has been an increase in the number of disputes lately relating to whether the terms actually offered by a patent owner that has made a simple RAND promise have in fact been reasonable (for more see this blog entry , as well as this one).

Such covenants and promises, when they go far enough, are essential to the implementation of open source software under the most popular open source licenses, and as you'll see from the Microsoft Web page, it has gone to the trouble of consulting with a number of members of the open source community in advance regarding the specific wording of the new promise, and has secured approving quotes from two of them: a commercial customer (Red Hat) and a respected open source authority (Larry Rosen).

Promises and covenants such as the one that Microsoft has announced today have historically been unusual, but have lately been made more frequently, especially after IBM made a well-publicized promise not to assert 500 patents against open source software. Similar promises followed from Sun Microsystems, Nokia and Oracle, among others.

That being said, of course, the specific details of a non-assertion covenant are extremely important, and the wording of each promise made to date by a vendor has varied, sometimes simply to reflect the favorite phrasing of its legal advisors, but often in important ways as well.

With this as an introduction, let's take a look at the new Microsoft promise, both on an absolute as well as comparative basis. Here's what it says, and what I take it to mean:

Microsoft irrevocably promises…

While there are some ongoing issues that relate to all such covenants, and to regular standard setting promises as well (is the promise binding on someone to whom the vendor sells the patent?), the word “irrevocable” is the important one, and represents the desired pledge that the promise may not be later revoked, although the statement might better have been worded “Microsoft irrevocably promises (except as provided below),” because conditions do apply that would void the promise if violated by someone relying on the promise.

…not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation….

As noted earlier, the explicit downstream promise is helpful (Necessary Claims will be defined later in the text). But note that the same conditions apply to those downstream as to the original party.

…to the extent it conforms to a Covered Specification (“Covered Implementation”),…

The new promise relates to 35 standards, and may be extended to others in the future. It appears that the promise is a “base level,” because additional assurances may be added with respect to future versions of the same standard. According to the FAQ that accompanies the new language, the phrase “to the extent” is meant to include partial as well as full implementation of a standard, a grant of rights that goes beyond what many standards organizations require as a pre-condition to a patent owner making its patent claims available to implementers.

…subject to the following. This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it…

While the promise is irrevocable, it is not unconditional. In order to enjoy the benefits, an implementer must accept the terms that follow.

…that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise….

This limitation is actually less important than it might at first seem, since the definition of “Microsoft Necessary Claims” that appears later clarifies that Microsoft is, in fact, also pledging rights under patents that it “controls” as well as owns. Presumably this would include third parties to the extent that it is able to do so under license agreements or other rights granted by third parties as well as with respect to patents owned by controlled subsidiaries of Microsoft, but that would be a good subject for an addition to the list of FAQs.

…If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you….

This provision goes by a number of names, one of which is “defensive revocation,” and represents an exception to the introductory “irrevocable” promise. It is extremely common in standard setting and can have benefits to all implementers, who may benefit indirectly from the revocation of the rights of use of someone that is bringing infringement suits against other implementers. The addition of the new language that runs down the distribution change is helpful in the context of open source, since someone that loses its rights will not result in the loss of someone downstream that does not join in the law suit.

…To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement…

The inclusion of “Microsoft-controlled” patents is notable, as not all standard setting organizations require a member to disclose or license such claims. Absent this language, implementers would want to be sure to understand the intellectual property rights (IPR) landscape relating to the standard in question if, for example, it was based upon a submission made by Microsoft that included any third-party rights.

… only the required portions of the Covered Specification…

This is the degree to which the great majority of standards organizations require a commitment. However, in a given case, an implement needs to be careful to understand how complete a standard may be, and how the standards organization in question defines “required,” which can be more or less extensive, depending upon the organization.

…that are described in detail and not merely referenced in such Specification….

While not usually phrased in this fashion, this is a common limitation intended to clarify that, for example, other standards that may be referenced, or so-called “enabling technologies,” the use of which would be required to use an implementation (e.g., the computer upon which the software is running) are not included.

…”Covered Specifications” are listed below….

To begin with, the 35 listed Web Services standards.

…This promise is not an assurance either (i) that any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe patents or other intellectual property rights of any third party. No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppels, or otherwise.

This is the standard “boilerplate” language that keeps lawyers happy.

The FAQ provides additional details, although in a few cases, I found that they raised questions rather than resolved them. Here are two with respect to which I requested clarification, and what I learned:

Q: Does this OSP apply to all versions of the standard, including future revisions?   

A: The Open Specification Promise applies to all existing versions of the specification(s) designated on the public list posted at, unless otherwise noted with respect to a particular specification (see, for example, specific notes related to web services specifications).

The key word here is “existing,” which in context means “now existing.” The question thus arises, what about future versions of the same standards?

As with traditional standard setting commitments, patent owners are wary about making open-ended promises, since in an extreme case a competitor could seek to extend a standard to describe part of, or all of a product of a patent owner, going far beyond what had been anticipated by the owner at the time that it made its commitment. Although there are differences from organization to organization, typically when a new version of a standard is approved, a member remains bound by so much of the standard as does not change, but is not bound by any new material that is added to it unless it is then a member, and agrees to do so.

And that is what Microsoft is committing to do, when you read the note at the top of the table of standards to which the pledge applies. For a comparison, see the language in the Sun ODF covenant, which is analyzed here.

I also asked about this FAQ, which I found to be rather opaque:

Q: If a listed specification has been approved by a standards organization, what patent rights is Microsoft providing?   

A: We are providing access to necessary claims consistent with the scope of our commitments in that organization.

Would this mean, for example, that if Microsoft had pledged less to a standards organization, that only the lesser pledge would apply? The response was no, just the opposite. The example given was that if a definiton of “required portions” was more liberal within a given standards organization than another, in each case, the definition of the applicable organization would control. In other words, the Microsoft promise would incorporate the definition of the standards organization in question. Microsoft would also continue to honor the commitments that it made in any organization of which it was a member, and would therefore continue to provide an actual license, if requested, by any implementer that desired one (as some will), to the extent that it had previously committed to do so.

Exactly how open source friendly is the new language? The FAQ is surprisingly cautious on that score, reading as follows:

Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?


A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can't give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

On a first read, this seems pretty modest, and it will be quite interesting to see the reactions that the new language draws. If a given specification is not well detailed and will need lots of work in the future, then the pledge will only work well for so long as Microsoft stays involved with that standard. More significantly, the pledge only relates to “compliant” implementations, which does run afoul of the open source right to change anything. From a standards point of view, that serves a purpose, as it furthers the spread of interoperable implementations, which is what standards are all about. That works well from that perspective, but may leave some open source advocates less happy. Still, nearly all standards obligations are so limited, so to the extent that this limitation is regarded as unfortunate, the same objection could be made against nearly other vendor as well.

Be that as it may, I think that this move should be greeted with approval, and that Microsoft deserves to be congratulated for this action. I hope that the standards affected will only be the first of many that Microsoft, and hopefully other patent owners as well, benefit with similar pledges.Note: While I provide legal services to a variety of standard setting organizations (including OASIS, which has set many Web Services standards), the opinions expressed above are mine alone. I have not been consulted by OASIS or any of my other standards clients in connection with the new Microsoft covenant.

Microsoft's Open Specification Promise

Today marks a major milestone for Mike Jones and myself. 

Microsoft announced a new initiative that I hope goes a long way towards making life easier for all of us working together on identity cross-industry.

It's called the Open Specification Promise (OSP).  The goal was to find the simplest, clearest way of assuring that the broadest possible audience of developers could implement specifications without worrying about intellectual property issues – in other words a simplified method of sharing “technical assets”.  It's still a legal document, although a very simple one, so adjust your spectacles:

Microsoft Open Specification Promise

Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification (“Covered Implementation”), subject to the following.  This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise.  If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you.  To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification.  “Covered Specifications” are listed below.

This promise is not an assurance either (i) that any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe patents or other intellectual property rights of any third party.  No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise.

Covered Specifications (the promise applies individually to each of these specifications)

Web Services  This promise applies to all existing versions of the following specifications.  Many of these specifications are currently undergoing further standardization in certain standards organizations.  To the extent that Microsoft is participating in those efforts, and this promise will apply to the specifications that result from those activities (as well as the existing versions).
WSDL 1.1 Binding Extension for SOAP 1.2
WS-Federation Active Requestor Profile
WS-Federation Passive Requestor Profile
WS-Management Catalog    
WS-RM Policy
Remote Shell Web Services Protocol
WS-Security: Kerberos Binding
WS-Security: SOAP Message Security
WS-Security: UsernameToken Profile
WS-Security: X.509 Certificate Token Profile
SOAP 1.1 Binding for MTOM 1.0    
WS-I Basic Profile
Web Single Sign-On Interoperability Profile
Web Single Sign-On Metadata Exchange Protocol

Note that you don't have to “do anything” to benefit from the promise.  You don't need to sign a license or communicate anything to anyone.  Just implement.  Further, you don't need to mention or credit Microsoft.  And you don't need to worry about encumbering people who use or redistribute or elaborate on your code – they are covered by the same promise. 

The promise is the result of a lot of dialog between our lawyers and many others in the industry.  Sometimes we developers wished progress could have been faster, but these are really complicated issues.  How long does it take to write code?  As long as it takes.  And I think the same notion applies to negotiations of this kind – unless one party arrives at the table with some pre-determined and intransigent proposal.  People on all sides of this discussion had legitimate concerns, and eventually we worked out ways to mitigate those concerns.  I thank everyone for their contribution. 

How have people from various communities reacted to the final proposal?

Lawrence Rosen, the lecturer at Stanford and author of, “Open Source Licensing: Software Freedom and Intellectual Property Law”, said:

“I see Microsoft’s introduction of the OSP as a good step by Microsoft to further enable collaboration between software vendors and the open source community.  This OSP enables the open source community to implement these standard specifications without having to pay any royalties to Microsoft or sign a license agreement. I'm pleased that this OSP is compatible with free and open source licenses.” 

Mark Webbink, Deputy General Counsel at Red Hat, said:

“Red Hat believes that the text of the OSP gives sufficient flexibility to implement the listed specifications in software licensed under free and open source licenses.  We commend Microsoft’s efforts to reach out to representatives from the open source community and solicit their feedback on this text, and Microsoft's willingness to make modifications in response to our comments.”

And from RL “Bob” Morgan, Chair of the Middleware Architeture Committee for Education, and a major force behind Shibboleth:

The Microsoft Open Specification Promise is a very positive development.
In the university and open source communities, we need to know that we can implement specifications freely.  This promise will make it easier for us to implement Web Services protocols and information cards and for them to be used in our communities.

So there it is folks.  I'm impressed that such a short document embodies so much work and progress.