Archive forSeptember, 2006

SAML Token Profile included in Microsoft promise

I have to admit, I would have missed it without Paul Downey’s help. In a comment below, he points to Jorgen Thelin’s post announcing yesterday morning that the Open Specification Promise has been extended to cover three more of WS-Security’s token profile specs, including the SAML one. That’s good.

(Interesting — the original submission of the “Kerberos Binding” spec had been listed, but now the standards-track spec with the name of “Kerberos Token Profile” is also listed. Lots of specs have been refactored into multiple pieces, renamed, etc. since they were submitted; should the official standards-track versions all be explicitly named for clarity?)

Comments

Simple signin’

JeffH is on fire lately. He’s one of the key people, along with Scott Cantor, who have been showing people just how easy it can be to “do SAML”. He put together a short document that explains the best entry points for reading the SAML specifications, and he and Scott have published a new version of their “no XML Signature” SAML binding, now called HTTP POST-SimpleSign. But wait, there’s more: They have also published an Internet-Draft spec that makes use of this binding, called the SAMLv2 Lightweight Web Browser SSO Profile. He’s got more interesting news besides — make sure to check it all out.

Comments

Identity award season!

Though I wasn’t able to attend the IOS or DIDW this week, it’s been fun to read about all the goings-on from afar.

Robin has the inside scoop on the inaugural IDDY awards given out by the Liberty Alliance this week. This wasn’t just a navel-gazing exercise; all the nominations had to show they were the real thing, and the judges included some non-Liberty-member luminaries. The three winning “identity deployments of the year” are quite different from each other. Robin discusses how one of the winners, a deployment by the UK Cabinet Office, offers more proof of benefits arising from the productive relationship that Sun and Microsoft have continued to build together.

And Identity Woman won an award from DIDW itself for being, well, herself — a tireless community driver. Congratulations to Kaliya!

I’m sure all the various award recipients were decked out in their finest Christian Dior and Hugo Boss outfits, along with ostentatious borrowed jewelry and cool sunglasses. :-)

Comments

Promises, promises

A few further random thoughts on Microsoft’s Open Specification Promise

First, a small observation: Despite Andy Updegrove’s deliberate use of “standards” in his analysis post (and throughout ConsortiumInfo.org) to refer to all specifications that have gained some currency, Microsoft is quite careful in making the distinction between “standards” and “specifications” in its promise text. In fact, some of the questions raised by Andy have to do with the distinction — for example, what happens if one of the specs has been submitted on a standards track at a formal org and subsequently finishes that track? These orgs all have IPR polices of their own. Microsoft’s FAQ isn’t crystal-clear on this point so we’ll need to see what they say going forward.

Onward: I missed seeing Mike Jones’s response to Gerry yesterday, which answers one question: whether developers of actual CardSpace implementations are covered. The bad news is that the documentation that would fill in a large part (if not, perhaps, all) of what’s needed for building compliant CardSpace implementations is clearly not covered. The good news is that they’re working on it. Mike says:

As of today, the InfoCard/CardSpace specs are not on the list. The good news is that (a) all the web services specs underlying CardSpace are covered (which is great news!) and (b) it means we’ve done the work internally to enable us to license specifications in this way. Licensing additional specifications under these same terms should be much easier to do at this point, but I obviously can’t make public commitments yet beyond those we already have buy-off on. Watch this space for further developments…

(By the way, I really should have listed Mike properly yesterday in offering congratulations — it’s obvious he did a fair amount of heavy lifting!)

The unanswered (or unsatisfactorily answered) question has to do with what “required portions of the Covered Specification” means: Does it refer to only those portions of a spec that have RFC 2119-defined MUST (NOT)s and SHALL (NOT)s in them? The covered specs have an awful lot of MAYs in them because they’re meant to be composable and turned to many purposes; that’s why we see the need for profiles (such as those done at WS-I, the Liberty Alliance, and various vertical industry groups) for actual interoperability in deployment. It would be good to get some clarification on this point, and it sounds like Mike is working on that too:

My interpretation of the language “patents that are necessary to implement only the required portions of the Covered Specification” was that “required” refers to “portions of the specification required by the application” — not “required versus optional portions of the application”. But I’m not a lawyer and you shouldn’t take my word for it. I’ll pass this question on to those who are lawyers. ;-)

Finally: I just noticed that the list of covered specs doesn’t include the SAML Token Profile of WS-Security. I realize that this wasn’t one of those specs that Microsoft privately published first; its genesis was some work that the SAML technical committee did before tossing it over the wall to the WS-Security TC by mutual agreement. But nonetheless, it’s an important spec (nay, standard!) that Microsoft clearly has some investment in, and their name is on it to boot. So why exclude it? Hopefully this is just an oversight that can be remedied soon along with the other outstanding issues. Go, Mike!

Comments (4)

Microsoft’s new promise: a welcome development

Today there’s been good news on the IPR front: Microsoft has published what it calls an Open Specification Promise that has the effect of offering a non-assertion covenant on a host of specifications that Microsoft has authored and co-authored. For a legal statement, it’s remarkably clear and easy to read.* Here’s the main bit:

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.

The ConsortiumInfo.org blog has an excellent analysis of both the official statement text and the FAQ that follows.

I like that they went and called it a “promise”, much as I did when announcing Sun’s similar promise on the SAML2 standard and the Web SSO Interop specs in this post in June. For some reason, I’ve noticed that non-lawyers get spooked by anything called a “covenant not to sue”, I suppose because it contains the “s-word”. So this clear language and the deep assurances to developers that Microsoft has offered today are very welcome indeed, and a huge contribution to what is shaping up to be a trend.

I see some OSIS-related triumphalism about this, and it certainly seems that OSIS discussions of late have been an important driver of this new development, as Johannes rightly notes. It does look as though there are a few remaining questions that need to be answered (my colleague Gerry Beuchelt poses some here) before we know whether non-Microsoft developers of CardSpace-compatible implementations should feel similarly at ease.

I’m sure we’ll learn more as we go. In the meantime, congrats to Kim Cameron et al. for their work on this. Having negotiated these things with Sun lawyers several times in the past, I’ve come to respect the world of IPR declarations as a technology in and of itself, one that’s difficult to master.

*Okay, after all these years, I finally looked up estoppel — turns out it means non-repudiation. Cool.

UPDATE: Since Simon Phipps’s commentary on the subject mentions this post, people coming to Pushing String for the first time may want to check out my further commentary above.

Comments (2)

An Instalanche for SchemaXpert?

Oh, my. Glenn Reynolds of Instapundit fame has a link to a new thing called SchemaXpert. When worlds collide…

Apparently he’s having to parrot what his sister-in-law tells him:

SCHEMAXPERT is a program that “dynamically and accurately creates XML documents from XML schemas.” To be honest, I have only a vague understanding of what that means, or why it’s useful.

I wonder what proportion of the Insta-hordes will actually be interested? I had never heard of SchemaXpert before myself, and have no idea whether it’s any good…

Comments (1)