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 http://www.microsoft.com/interop/osp/, 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).
WS-Addressing
WS-AtomicTransaction
WS-BusinessActivity    
WS-Coordination
WS-Discovery
WSDL
WSDL 1.1 Binding Extension for SOAP 1.2
WS-Enumeration
WS-Eventing
WS-Federation
WS-Federation Active Requestor Profile
WS-Federation Passive Requestor Profile
WS-Management
WS-Management Catalog    
WS-MetadataExchange    
WS-Policy
WS-PolicyAttachment
WS-ReliableMessaging    
WS-RM Policy
Remote Shell Web Services Protocol
WS-SecureConversation
WS-Security: Kerberos Binding
WS-Security: SOAP Message Security
WS-Security: UsernameToken Profile
WS-Security: X.509 Certificate Token Profile
WS-SecurityPolicy
SOAP
SOAP 1.1 Binding for MTOM 1.0    
SOAP MTOM / XOP
SOAP-over-UDP
WS-Transfer
WS-Trust
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.

Dynamic detection of client dialect requirements

It seems I might not have found quite the magic recipe yet in my attempt to dynamically recognize whether you are coming from a July CTP or release candidate client.  “Close, probably, but no cigar.”

If you have any kind of problem logging in with an Information Card, please email me the output of this diagnostic.

“Funny, it worked on MY machines.” (From Programming Yarns, Volume 1, Chapter 1). 

Sorry for having been a little optimistic about my initial success.  A bunch of people had reported that things worked – and I prematureluy took that as meaning that they didn't NOT work. 

I'm still trying to sort out why some people are having problems.  So if you don't mind trying out and mailing in the diagnostic, I'd really appreciate it.

 

Upcoming DIDW

I hope everyone's going to Digital ID World (DIDW) next week. We'll start on Monday with an Identity Open Space Unconference (don't worry, Virgos, they're unstructured, but not without shape and self-revealing purpose). Once this gives rise to the main event, there are a number of sessions that look fascinating for identity afficionados – like “What Do the Internet's Largest Sites Think About Identity?”, a panel moderated by Dan Farber and featuring representatives of the large sites and a new presentation by Dick Hardt. There will also be an OSIS meeting – and of course, the endless hallway conversation.

I'm pairing up with Patrick Harding (from Ping Identity) on a Wednesday session called “Understanding InfoCards in an Enterprise Setting“. It will include a demo that I think will really help show the concrete benefits of InfoCards inside the enterprise. What can you expect? 

First, you'll see the latest version of Ping's InfoCard server, now featuring both Managed IdP as well as Service Provider capabilities. Ping's goal is to show how to seamlessly chain passive and active federation – allowing for on-the-fly privacy context switching.  They'll use real-world use-cases where passive federation gives way to active and vice-versa.

According to Andre Durand, Ping Identity's CEO:

“The Digital ID World demo will show two scenarios to depict how passive federation (via SAML 2.0 Web SSO Profiles or WS-Federation) and active federation (via CardSpace) can both play a role in enabling a seamless user experience for accessing outsourced applications. The plan is to demonstrate how passive and active federation work together to enable a myriad of different business use cases when chained together in different situations

“Scenario 1:

“An enterprise employee leverages her internal employee portal to access applications that are hosted externally. In the first case we show how SAML 2.0 Web SSO (passive federation) is used to enable seamless access into the SF.com web site. The user accepts this as part of her employment contract – the employer has deemed that the use of SF.com is critical to their business and they want no friction for their sales force in entering information for forecasting purposes.

“In the second case we'll show how CardSpace is used to ‘optionally’ enable seamless access into the employees Employee Benefits web site. As the Employee Benefits web site is made up of a mixture of personal and corporate information (i.e. 401k, health and payroll) the employee is given the choice of whether to enable SSO via the use of CardSpace. The Employee Benefits web site is enabled with CardSpace. After the user clicks on the ‘Benefits’ link in their corporate portal, she is prompted with different Cards (Employer and Benefits) which she can then choose between for accessing the Benefits web site. If she chooses ‘Employer’ then she will be enabled with SSO from the Corporate Portal in future interactions.”

By the way, Andre, please tell me there's some way for her to change her mind later!

“Scenario 2:

“An enterprise employee is traveling and loses her cell phone. She uses her laptop to access her corporate cell phone provider in an effort to have the phone replaced immediately. The employee would normally access this web site via SSO from her corporate portal. The cell phone provider web site is enabled with Card Space to simplify the IdP discovery and selection process. The employee is prompted to use her Employer card to authenticate to her employer's authentication service. The cell phone provider web site leverages CardSpace to handle IdP Selection rather than having to discover this themselves. Once the user has authenticated to her employer the returned security token contains the relevant information to service the employee's request for a new cell phone.”

It all sounds very interesting – amongst the first examples of what it means to have a full palette of identity options.  Ping is emblematic of an emerging ecology – many of us, across the industry, moving us towards the Identity Big Bang.

Doc Searls will be doing the closing Keynote.  I'm really looking forward to that and to seeing you in Santa Clara.

Namespace change in Cardspace release candidate

Via Steve Linehan, a pointer to Vittorio Bertocci's blog, Vibro.NET:

In RC1 (.NET framework 3.0, IE7.0 and/or Vista: for once, we have all nicely aligned) we discontinued the namespace http://schemas.microsoft.com/ws/2005/05/identity, substituted by http://schemas.xmlsoap.org/ws/2005/05/identity. That holds both for the claims in the self issued cards (s-i-c) and for the qname of the issuer associated to s-i-c. If you browse a pre-RC RP site from a RC1 machine, you may experience weird effects. For example, like the Identity Selector claiming that the website is asking for a managed card from the issuer http://schemas.microsoft.com/ws/2005/05/identity/issuer/self no longer recognized as the s-i-c special issuer. Note that often is not a good idea to explicitly ask for a specific issuer :-)

 If you want to see a sample of this, check out the updated version of the sandbox.

Why this change? As you may know, relying parties specify the claims they want the identity provider to supply (for example, “lastname” or “givenname”) using URIs.

Everyone will agree that the benefit of this is that the system is very flexible – anyone can make up their own URIs, get relying parties to ask for them, and then supply them through their own identity provider. 

But a lot of synergy accrues if we can agree on sets of basic URIs – much like we did with LDAP attribute names and definitions.  

Given that a number of players are implementing systems that interoperate with our self-asserted identity provider, it made sense to change the namespace of the claims from microsoft.com to xmlsoap.org.  In fact this is an early outcome of our collaboration with the Open Source Identity Selector (OSIS) members.  Now that there are a bunch of people who want to support the same set of claims, it makes total sense to move them into a “neutral” namespace.

While this is therefore a “good and proper” refinement, it can pose a problem for people trying out the new software:  if you are using an early version of Cardspace with self-issued cards that respond to the “microsoft.com” namespace, it won't match new-fangled claims requested by a web site using the “xmlsoap.org” namespace.  And vica versa.  Further, the “card illumination” logic from one version won't recognize the claims from the other namespace.  Cardspace will think the relying party is looking for specialized claims supplied by a “managed card” provider (e.g. a third party).  Thus the confusing message.

After getting some complaints, I fixed this problem at identityblog: now I detect the version of cardspace a client is running and then dynamically request claims in either an old dialect or the new one.  I would say people would do well to build this capability into their implementation from day one.  My sample code is here.

Update to PHP sample code for Information Cards

I've finally been able to come through with my promise to post an updated version of the zip file containing sample code intended to help people learn how Information Cards work, and how to implement systems compatible with Cardspace.  This includes Keith Grennan's fix.  The original post and the screen cap that goes with it is here.

Adventures in Cardspace

Industry guru Craig Burton's Cardspace is working now (thank goodness).

The bad news is that he's had a pretty miserable time getting it going.  Mainly, it seems in retrospect, because his computer was set up with a FAT32 file system.  If you have this configuration, no error message is displayed to you as a user – you have to read through a cryptic note in the system-wide error log.  This has to be fixed.

The good news is that once he got Cardspace working, Craig really liked it.  That's really important to me:

I have been trying to get CardSpace to work on my machine for several weeks. (Seems much longer.)

I have downloaded tons of upgrades, deleted apps and services, and so on.

Pamela Dingle and Kim Cameron have been very helpful in trying to help me make things work.

Pamela studied the error log –created by the CardSpace control panel–I posted and suggested that the problem was that my c: drive was using the FAT32 file system. She explained that her resources tell her that CardSpace only supports NTFS.

Turns out this is true. Kim subsequently fessed up that FAT32 isn't secure enough so they decided to set the bar at NTFS. They just didn't bother to tell anybody. (Good thinking.)

I decided–against my better judgement–to convert my FAT32 file system to NTFS. I haven't done that until now because I haven't been successful in creating an NTFS compatible boot CD. If something happens to my system, I'm in trouble. I am working on resolving this. (There is a DOS-based utility that will access NTFS for recovering critical data. I don't like that prospect.)

Anyway, to convert from FAT32 to NTFS you do the following. Open a command line window:

start>run>cmd

Run the convert utility:

convert c: /fs:ntfs

Reboot, and the convert utility–assuming you have enough empty storage–will convert FAT32 to NTFS with no loss of data.

I tried it. It worked. Whew! Getting this far has been no simple task.

I was then able to create an Infocard with the CardSpace control panel and login  to the Idendity web log and to the NetFX Sandbox.

I also tried the Ping site . It was slow–not sure why–but it worked. A page came up with four other sites that support Ping Federation that I can sign into with my Infocard. The sites aren't all the useful to me, Java, Verisign, Computer Associates, and another one I can't remember. That was cool.

The Ping site–unlike the other two sites–gave me three options for signin:
Traditional (yuch) name and password, self issued Infocard or Managed Infocard. Not sure why ping distingshes between self-issued and managed Infocards as the Infocard selector lets you do that, but I will find out.

Caveats.

If you convert to NTFS, you cannot go back to FAT32 without repartioning and formatting your disk.

I love being able to register and login to a website with an Infocard…SWEET!

I hate how complicated it is and that it only works with BETA code. Infocard simplicity comes at a complicated uphill price. At least it isn't Msft-silo-centric. Apple, Mozilla, RedHat and others have commited to support Infocards.

Things will have to get significantly easier–and supported by other browsers and OSs–before we see any kind of adoption.

Despite all of that. Not having to use name-password mechanisms for secure interaction is very significant to the industry and people. This has been a long time coming and I can't emphasize its importance enough.Thanks to all that have made it happen. 

Many thanks to Pamela, who has become a Cardspace savante, for figuring this out – I've been in Australia and couldn't keep up with the troubleshooting.

Demo libraries fix

Keith Grennan has a fix to the PHP sample code I published a while back.  He notes he “hasn't heard back”…  My mail system is extremely aggressive about putting things in the Junk Mail folder, so if you ever “don't hear back” don't be afraid to ping me again. 

I was hacking on Kim Cameron’s demo PHP InfoCard libraries recently, and sometimes found I got the error “SignedInfo digest doesn’t match calculated digest”.

It turns out the XML canonicalization in infocard-post-get-claims.php was breaking when character data in the token contained entity references (e.g. &), because the characterData handler gets only the decoded data.

Here’s a patch that fixes it. The patch re-encodes ‘< ’, ‘>’, and ‘&’ characters back to ‘<’, ‘>’ and ‘&’ respectively before adding them to $canonicalTokenBuffer. There are some edge cases that may not be solved by this patch, but it’s a quick fix that should make the token processing code more robust for many possible cases. I sent it to Kim but have not heard back.

Happy infocarding.

Check out the fix here.  I'll incorporate it into my code, which is intended to help people master infocard and can be used in whatever way is deemed helpful.  I'll post an updated ZIP this comng week.

Thanks, Keith.

 

Liberty, Open Space and Information Cards for Apple

Red Hat's Pete Rowley on the recent adjoining Liberty Alliance and Open Space events in Vancouver – and Apple support for Information Cards:  

The Liberty Alliance made a bold statement in Vancouver last week when it opened its doors for the first time to the hoi polloi. Now this was something interesting enough to demand a visit in of itself, but with the addition of an Open Space after the Liberty meeting, well, you knew I was going to be there right?

The first two days consisted of the regular business of the Liberty Alliance where visitors were allowed to attend any session except for the super secret board stuff. I attended many of the technical sessions which were interesting, though sometimes hard to follow as an outsider without access to the documents under consideration. I also took part in a session around privacy concerns that not only assured me that Liberty has them but that they are serious about dealing with the issues. The conversation turned at one point to outside perceptions of Liberty itself and its lack of openess to its internal process and draft documents. Somewhat ironic was the point made that nowhere was there to be found any information regarding the location of the Liberty conference, at least not to those without access to internal websites. A consequence of this being the first open meeting no doubt. In all, an interesting and worthy meeting.

The final two days were spent on the Open Space which was run in unconference format by Kaliya Hamlin and was excellent as usual. Topics ranged from SAML to Liberty People Service to how should we rename this user centric identity thing? Kim Cameron wrapped up with a lunchtime introduction to CardSpace that by popular demand lasted for nearly two hours. At one point Kim was asked whether Apple would have an identity selector like CardSpace and Kim redirected the question to me in my capacity as OSIS representative. As the newly appointed unofficial spokesman for Apple I suggested that if Steve Jobs would call me I’d hook him up.

So Steve, call me.

Gee.  That's an interesting idea.

Like Pete I took Liberty's Open Space collaboration as being a very positive step in increasing dialog and understanding in the identity community.  It was great to speak with a number of the Liberty people who have been leaders in moving identity technology forward over the last few years.  It strengthens my conviction that we are on the road to an Identity Metasystem reaching across platforms and underlying technologies.

Soothing music all around

Google's Ben Laurie continues with a post I'd call “Cogent with cloudy periods”:

Not surprispingly, my post “Google Account Authentication” attracted some pretty instant responses, as well as comments on the post itself.

On further reflection, comparing Live ID with Google’s authentication is comparing apples and oranges. Live ID may allow people to choose who they accept authentication from, but where does it say that anyone is planning to accept anyone’s word other than their own? In particular, where do Microsoft say they’re going to grant access to Microsoft properties using identity tokens issued by anyone other than Microsoft?

Interesting. Let me explain how I see it. The Windows Live ID whitepaper is about the technical architecture of Windows Live ID, and new capabilities allowing it to be part of a standardized, multi-centered, federated identity fabric. This includes support for Information Cards. Reading the paper, it's easy to see how enterprises or groups of users could gain access to Windows Live services using their native systems federating with Windows Live ID, rather than requiring separate accounts. The business model for this would be totally straightforward.

Now, in terms of how the protocols work, a similar federation relationship could be established between a Windows Live and a Yahoo or a Google. But the business models there are way harder to figure out. You need multiple players to buy in – it needs to be a win/win/win. I don't think anyone has figured this stuff out. Basically, it's a lot easier to change technologies than to change business models.

Still, to me, it makes sense to put a safer, more flexible technical infrastructure in place that offers advantages within current business models while simultaneously laying the groundwork for new approaches as they arise. But let's try to see the two as relatively autonomous.

Ben continues:

Eric Norlin says: “Lots of people inside of Microsoft now understand *why* they must open the silo, and that learning is precisely because of their experience with Passport.” But is this actually true? What Microsoft appears to have learnt is that it can’t get everyone to accept its credentials. So, what’s the next best thing? Get everyone to use MS technology for accepting credentials. Perhaps that’ll even lead to Passport Mark II where the default is to trust Microsoft. Where does Microsoft’s work on Infocard or Live ID or whatever-the-passport-nom-de-jour is show that Microsoft has any intention whatsoever of opening their silo? What it shows is that they think everyone else should open their silo.

This mish-mashes so many orthogonal ideas together that it gets a wee bit looney. If the following sounds disconnected, it's because the way Ben connected things doesn't make any sense to me:

  • It's true that a lot of us at Microsoft want to “open the silo”. That doesn't make it easy, or make it obvious what to do.
  • WS-Trust is not Microsoft Technology, unless IBM is now part of Microsoft – not to mention the hundred or so other companies who have worked on the WS specifications.
  • Information Cards are not Microsoft proprietary for two reasons: first, the protocols are in OASIS standardization and available royalty-free; and, second, because there is a consortium building real open-source implementations today (OSIS).
  • I don't understand why Ben wants to confuse a service offering like Windows Live ID with a cross platform technology initiative like the Identity Metasystem.
  • I'm even more mystified at the implication that our Cardspace implementation of Information Cards is a plot. It doesn't offer special advantages to Windows Live ID. Services like those offered by Google get equal billing with services that might come from Microsoft. What is the sin here?
  • Given the difference between services and open cross platform technology, why call Cardspace “the-passport-nom-de-jour” – except to be naughty?

Anyway, I'm just going to assume Ben had a bad hair day, which everyone has a right to.

Parhaps the flurry of postings made it look like people were ganging up on Google – not at all my intention – I still think that on identity our interests converge and we're all in similar places.

At any rate, Ben concludes thus:

Fred asks: “could you explain why Google shouldn’t allow their accounts system to be accessed by Yahoo credentials?”

All I can say is what I already said: there isn’t a widely used, mature, reliable, secure identity federation mechanism available today. Whether Google wants to do this or not, in practice, they can’t. Such decisions have to wait for standardised mechanisms to emerge, in my view.

Dick is “suprised to see this post given conversations we had”. Well, Dick, if the fact that I don’t always agree with you is surprising, then you’d better stock up on soothing music or something.

I think the situation calls for soothing music all around. How about Iggy Pop?