Category: Information Cards

Privacy and Identity – IGF workshop outcomes

From the Internet Governance Forum, via Ralf Bendrath's blog: 

The workshop on privacy and identity we held together with the LSE information systems group this morning sparked an interesting discussion.

Christian Möller gave some examples of how privacy is not only important in itself, but how it also is a necessary condition for freedom of expression.

Microsoft’ Jerry Fishenden presented their InfoCards concept and the “7 Laws of Identity” as one approach on how to handle user data based on different credentials. While most of the panelists agreed that this is a good basis for a start, and especially welcomed the company's recent efforts to make it more privay-friendly, Jan Schallaböck and Mary Rundle pointed at one major drawback: Once you have sent your personal information to a company – no matter if through InfoCards or another system – you can not control what happens with it afterwards.

Jan, who is with the data protection authority of the German land of Schleswig-Holstein, therefore presented the ideas, concepts and systems developed in the EU-funded Privacy and Identity Management in Europe (PRIME) project as an alternative.

Their model is that user data given to web service providers will have “sticky privacy policy” attached to it in the form of meta-data. This meta-data will move with the personal data and can help ensure that it is only used or tranferred in a way the user has agreed to.

Mary from NetDialogue suggested (having) a similar way as the Creative Commons license: Privacy Policies should be human readable, lawyer readable, and machine readable. The advantages would be that the users can better decide how they “licence” the use of their data to other parties. Mary even presented a very nice series of icons that symbolize different use policies.  This approach might be one way to address the failure or “myth of user empowerment”, as Ives Poullet called it.

Stephanie Perrin, research director at the Office of the Privacy Commissioner of Canada, finished by saying that the privacy community has to become much more involved in international technical standardization processes. As always, time was too short. Therefore, we will discuss a collaborative follow-up process later this evening.

Actually, the “sticky privacy policy” notion can be implemented by identity providers using version 1 of Cardspace – it doesn't limit the token types that can be exchanged.  A new type of token that includes metadata about use policy is a good example of why this flexibility is useful.  I support the idea.

Maybe Jan Schallaböck and Mary Rundle are aware of this, but are talking about the self-issued identity provider used to “bootstrap” Cardspace.  In v1.0, it does not have this kind of metadata built in to it. 

I look forward to collaborating with Mary and Jan to create the kinds of visual and metadata systems now being discussed.  I don't actually see PRIME as being “alternative” in any way to the work I've been doing – we have the same goals.

 

Feedback from Urs Gasser at Berkman

Here's some feedback on Rubinstein and Daemen's new Metasystem Privacy paper posted by Urs Gasser on his Law and Information blog.  Urs is an expert in cyber law associated with the Berkman Center at Harvard Law School.

Microsoft released a white paper entitled “The Identity Metasystem: Towards a Privacy-Compliant Solution to the Challenges of Digital Identity.” The excellent paper, authored by Microsoft’s Internet Policy Council Ira Rubinstein and Tom Daemen, senior attorney with Microsoft, and posted on Kim Cameron’s blog, is a must-read for everyone interested in user-centric ID management systems. (Disclosure: As you can take from the acknowledgments, I have commented on a draft version of the paper, based on my earlier observations on “Identity 2.0”-like initiatives.)

Among my main concerns – check here for other problem areas – has been Microsoft’s claim that the i-card model is “by design” in compliance with the unambiguous and informed consent requirement as set forth, for instance, by EU data protection law. I’ve argued that the “hardwired”-argument (obviously a variation on the theme “regulation by code”) might be sound if one focuses on a particular relationship between one user and one identify provider and/or one relying party – as the white paper does. However, at the aggregated level, the i-card model’s complexity – i.e. the network of informational relationships between one user and multiple ID providers and relying parties – increases dramatically. If we were serious about the informed consent requirement, so my argument goes, one would wish that the user could anticipate not only the consequences of consent vis-à-vis one ID provider, but would understand he interplay among all the components of the ID-system. Even in less complex informational environments, experience has shown that the making available of various privacy policies can’t be the answer to this problem – as the white paper seems to acknowledge.

In this regard, I particularly sympathize with the white paper’s footnote 23. It might indeed be a starting point for an answer to what we might call the “transparency challenge” to create “a system enabling web sites to represent privacy policies in a simple, iconic fashion analogous to food labels. This would allow consumers to see at a glance how a site’s practices compared to those of other Web sites using a small number of universally accepted visual icons that were both secure against spoofing and verified by a trusted third party.” (p. 19, FN 23.) Such a system could become particularly effective if the icons – machine-readable analogous to creative commons labels – would be integrated in search results and monitored by “Neighborhood campaigns” similar, for instance, to Stopbadware.com.

Although Microsoft’s paper leaves some important issues unadressed, it seems plain to me that it takes the discussion on identity and privacy protections as code and policy an important step further – in a sensible and practical manner.

I agree with Urs when he talks about where we can go with visual icons representing the practices and policies of sites and identity providers.  Let's do it.

Just to be clear, I see Information Card technology as providing a platform for people to control their digital identity.  As a platform, it leaves people the freedom to put things of their choice onto that platform.

Let's make an analogy with some other technology – say plasma screens.  The technologists can produce a screen with fantastic resolution, but people can still use it to view blurry, distorted signals if they want to.  But once people see the crsytal clarity of high definition, they move away from the inferior uses.  Even so, there still might be artifacts that are important historically that they want to watch in spite of their resolution.

In the same way, people can use the Information Card technology to host identity providers with different characteristics.  It's a platform.  And my belief is that a high fidelity and transparent identity platform will lead to uses that respect our rights.  If this requires help from legislators and the policy community, that's just part of the process.  In other words, I don't think CardSpace is the magic bullet that solves all privacy problems.  But it is an important step forward to have a platform finally allowing them to be solved.

Once you let one party send information to another party, there is no way to prevent it – technically – from sending a correlating identifier.  As a morbid example, terrorists have been known to communicate by depositing and withdrawing money from bank accounts.  The changes in the account are linked to a codebook.  So any given information field can be used to communicate unrelated information.  

What you can do is prevent the platform itself from creating correlation handles or doing things without a user's knowledge.  You can use policy, legal frameworks and market forces so providers and consumers of identity are transparent about what they are doing. You can create technology that can help discover and prove breaches of transparency.  You can facilitate holding third parties to their promises.  And you can put in place social and legal protections of technology users, along the lines of the privacy-embedded laws of identity.

That's why I see the contributions of legal and policy experts as being just as fundamental as the contribution of technologists in solving identity problems.  In in the long term, the social issues may well be more important than the technical ones.  But the success of the technology is what will make it possible for people to understand and discuss those issues.

I advise following some of the thoughtful links to which Urs refers.

 

Ontario Privacy Commissioner extends the Laws of Identity

Here is a post from the Toronto Globe and Mail's Jack Kapica on a development I'll be writing about over the next couple of days – the Ontario Privacy Commissioner's active support for those of us in the industry building an identity metasystem with “embedded” privacy.  This is a remarkable turn of events.

Dr. Cavoukian is one of the preeminent voices for privacy world-wide, and her early and active involvement will help ensure we technologists continue to go in the right direction.  I'll be podcasting her press conference and address to the International Association of Privacy Professionals (IAPP) Conference being held this week in Toronto, Canada.  She has also agreed to share the remarkable documents she and her colleagues have produced to tease out the privacy implications of the Laws of Identity.

Anne Cavoukian's work extends the conversation into a whole new milieu.  And what could be a more auspicious beginning than the vote of support from Jack Kapica, widely known and respected for his careful vetting of all things technological.

Ann Cavoukian, Ontario’s clear-eyed Information and Privacy Commissioner, is onto something very big after endorsing the Seven Laws of Identity, developed under an initiative headed by Microsoft, which she did at a press conference this morning. Using a form of Microsoft’s own strategy, she has embraced and extended those laws in a way that might change tame Internet forever, and maybe even help stop spam.

The seven laws of identity were formulated through a global dialogue among security and privacy experts, headed by Kim Cameron, Microsoft’s Chief Identity Architect. With Cavoukian’s spin, they describe a system in which a set of digital identity cards would keep personal information distinct from information needed for verification.

And no, the seven laws are not Microsoft’s property — anyone can use them. But a form of them will ship with Microsoft’s Vista, its next version of Windows, due for release in January.

Cavoukian and Cameron hint that the system ought to provide the best defence against spam I’ve yet seen. The idea is that while on-line, users can control their personal information, minimize the amount of identifying data they reveal, minimize the links between different identities and actions and detect fraudulent messages and websites, thereby minimizing the incidence of phishing and pharming.

While Cavoukian’s proposal, called Seven  Laws of Identity: The Case for Privacy-Embedded Laws of Identity in the Digital Age, is primarily intended to protect privacy and make on-line commerce safer, it could also kill e-mail from those villains who sell snake oil and pump penny stocks by sending you e-mail from  fraudulent return addresses.

Cavoukian was one of the first non-technologists to grasp the link between on-line identity management and privacy, and has a better understanding of technology than most people do. Kim Cameron, a former Torontonian who has been a personal friend for almost 30 years (he wrote the software that ran the original Globe and Mail books bestseller list), is another great visionary. The combination of the two should make an enormous impact on  technology and commerce if the world takes notice.

With uncharacteristic overstatement, Cavoukian says that once a universal method to connect identity systems and ensure user privacy is developed, there will be an “Identity Big Bang.”

I wish them both the best of luck.

Reading Jack's piece I remember the old days we spent together – and how hard we worked to make sure the Bestseller List was scrupulously scientific and objective.  That's the kind of guy Jack is.  There's real honor there.

 

New features added to Safari InfoCard plugin

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

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

click to download movie

 

Download the plugin for the Power PC here.

Download the intel version here.

 

Jamie Lewis on Open Specification Promise

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

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

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

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

Some Background

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

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

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

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

Enter the OSP

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

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

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

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

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

Could the world be upside down?

In my last post I shared Jon Udell's conversation about “translucent databases” as a way to protect us from identity catastrophies.  He mentions a lender (e.g. Prosper) who needs information from a credit bureau (e.g. Equifax) about a borrower's reputation.

I'll start by saying that I see the credit bureau as an identity provider that issues claims about a subject's financial reputation.  The lender is a relying party that depends on these claims.

The paradigm currently used is one where the borrower reveals his SSN (and other identifying information) to the lender, who then sends it on to the credit bureau, where it is used as a key to obtain further reputation and personal information.  In other words, the subject deals with the lender, and the lender deals with the credit bureau, which returns information about the subject.

There are big potential problems with this approach.  The lender initially knows nothing about the subject, so it is quite possible for the borrower to pose as someone else.  Further, the borrower releases someone's SSN to the lender – as each of us has given ours away in thousands of similar contexts – so if the SSN might once have been considered secret, it becomes progressively better known with every passing day.

What's next?  The lender uses this non-secret to obtain further private information from the identity provider – and since the user is not involved, there is no way he or she can verify that the lender has any legitimate reason to ask for that information.  Thus a financial institution can ask for credit information prior to spamming me with a credit card I have not applied for and do not want.  Worse still, as happened in the case of Choicepoint, an important opportunity to determine that criminals are phishing for information is lost when the subject is not involved.

Jon proposed ways of changing the paradigm a bit.  He would obfuscate the SSN such that a service operated by the user could later fill it in on its way from the lender to the credit bureau.  But he actually ends up with a more complex message flow.  To me it looks like the proposal has a lot of moving parts, and makes us wonder how the service operating on behalf of the user would know which lenders were authorized.  Finally, it doesn't answer Prosper's claim that it needs the SSN anyway to submit tax information.

Another simpler paradigm

 I hate to be a single trick pony, but “click, clack, neigh, neigh”.  What if we tried a user-centrilc model?  Here's a starting point for discussion:

The borrower asks the lender for a loan, and the lender tells him which credit bureaus it will accept a reputation from. 

The borrower then authenitcates to one of those credit bureaus.  Since the bureaus know a lot more about him than the lender does, they do a much better job of identifying and authenticating him than the lender can.  In fact, this is one reason why the lender is interested in the credit bureau in the first place.

The credit bureau could even facilitate future interactions by giving the subject an InfoCard usable for subsequent credit checks and so on.  (Judging by the email I constantly get from Equifax, it looks like they really want to be in the business of having a relationship with me, so I don't think this is too far-fetched as a starting point).

After charging the borrower a fee, the credit bureau would give out a reputation coupon encrypted to the lender's key.

The coupon would include the borrower's SSN encrypted for the Tax Department (but not visible to the lender).  The coupon might or might not be accompanied by a token visible to the borrower;  the borrower could be charged extra to see this information (let's give the credit bureaus some incentive for changing their paradigm!)

When the lender gets the coupon, it decrypts it and gains access to the borrower's reputation.  It stores the encrypted version of the borrower's SSN in its database (thus Jon's goal of translucency is achieved).  At the end of the year it sends this encrypted SSN to the tax department, which decrypts it and uses it as before.  The lender never needs to see it.

All of this can be done very simply with Information Card technology.  The borrower's experience would be that Prosper's web site would ask for an Equifax infocard.  If he didn't have one, he could get one from Equifax or choose to use the oldworld, privacy-unfriendly mechanisms of today.

Once he had an InfoCard, he would use it to authenticate to Equifax and obtain the token encrypted for Prosper.  One of the claims generated when using the Equifax card would be the SSN encrypted for the Tax Department. 

When you use an Information Card, the identity selector contacts the identity provider to ask for the token.  This is how the credit brueau can return the up-to-date status of the borrower.  This is also how it knows how to charge the borrower, and possibly, the lender.

InfoCard protocol flow

In my view, the problem Jon has raised for discussion is one of a great many that have surfaced because institutions “elided” users from business interactions.  One of the main reasons for this is that institutions had computers long before it could be assumed that individuals did. 

It will take a while for our society to rebalance – and even invert some paradigms – given the fact that we as individuals are now computerized too.

Jon Udell and InfoCards…

Good news and a good question from Jon Udell.

Last night I logged into your identity blog using Chuck Mortimore's Firefox extension — very cool!

It's great to see Jon excited about Information Cards.

Now on to that really good question…

It reminded me to ask you something I've been wondering about. How might following scenario map onto this technology:

  1. I join a site (A) that wants to communicate a doc containing my SSN to another site (B)
  2. Instead of allowing A to hold my SSN, I require A to flow SSN-bearing documents through me enroute to B.
  3. When the doc arrives, I tack on the SSN. If A must see the doc again before handing off to B, I encrypt the SSN for B's eyes only.
  4. Along with the SSN I attach a use-once-only-and-then-discard request directed at B.

(In the example I've been exploring on my blog, and in a podcast with Phil Windley, A is Prosper.com and B is Experian or Equifax.)

It would be interesting to know whether (and if so, how) the Cardspace tech could apply here. Some questions I've thought of:

At step 2, do we construe me as the identity provider asserting the claim that is my SSN?

Since I am not always online — and assuming the protocol tolerates asynch delay — would we model this as my use of a self-asserted SSN-bearing InfoCard in a B context that was set up by A?

I was a bit confused without refering back to Jon's blog, so here's the piece with which he began the discussion:

Back in 2003 I was trying to drum up interest in Peter Wayner’s book, Translucent Databases, which shows how to build and operate databases whose contents are opaque to their operators. Three years later, there’s still no serious discussion of why translucency should be a key architectural principle, or how it might be applied.

A couple of recent examples show why it’s an issue that belongs on IT’s agenda. The first involves Prosper, a service whose tagline is “people-to-people lending.” Using a social network to broker connections between groups of borrowers and groups of lenders, Prosper aims to do for loans what eBay has done for auctionable goods. I wanted to invest a small amount as a lender in order to find out more about how the system works, so I began the sign-up process. To enable a credit check, Prosper asked for my Social Security number. That seems like an obvious requirement but, when you stop and think, why should it be? Prosper doesn’t actually need to receive and store that number. It only needs to relay it to Equifax, Experian, and TransUnion.

If Prosper ran its database translucently, I would be able to encrypt the number so that nobody inside Prosper, legitimate or otherwise, could read it. Equifax and others would ask me to unlock it. Ideally they’d promise to use it once and then discard it.

At this point, of course, it becomes clear that Prosper shouldn’t need to store my encrypted number in its database. It should only need to sign a request to the bureaus for a credit check. The request should then bounce to me, acquire my encrypted Social Security number along with permission for one-time use, and hop along to the bureaus. This protocol won’t work synchronously, but it doesn’t have to. If asynchronous message flow gives me the control I want, that’ll be just fine.

Translucency shouldn’t apply to only databases; it should govern service networks too. Unfortunately, with the lone exception of SSL, every effort to make cryptographic protocols useful to ordinary folks has gone down in flames. How will that ever change?

Quixotic jousts with the likes of Prosper over individual Social Security numbers won’t move the needle. But AOL’s recent data spill, or another such Exxon Valdez-like disaster, just might. “My goodness,” said Thelma Arnold, AOL’s user #4417749, when her search history was linked to her identity and revealed to her. “It’s my whole personal life.”

It’s time for a public conversation about the uses and limits of translucency. Is it really necessary to retain my Social Security number, or my search history, in order to provide a service? If not, what does it cost the provider of a service — and cost the user, for that matter — to achieve the benefit of translucency? Is this kind of opt-out a right that users of services should expect to enjoy for free, or is it a new kind of value-added service that provider can sell?

Realistically, given the very real technical challenges, I think it would have to be a service. Until recently, that hadn’t been a service that many folks would have considered paying for. But Thelma Arnold and 658,000 other AOL customers probably see things differently now. If you’d rather not be liable for storing more of your customers’ data than is strictly necessary, that’s a step in the right direction.

This is one of several related items, all of which are interesting.  I'll let you rest your eyes, and respond in my next post.

Mortimore publishes code for managed information cards

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

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

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

https://xmldap.org/sts/cardmanager

If you'd like to try it out, you can download the source from http://xmldap.org

 

InfoCards for Firefox users

From Chuck Mortimore at xmldap.org: 

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

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

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

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

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

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

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

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

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

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

Ben Laurie responds to OSP

Ben Laurie, a major contibutor to internet security through his work at Apache, and now at Google, is generally positive about OSP but has questions: 

“Kim Cameron announced that Microsoft are making it possible for anyone to implement Infocard-compatible systems (and other systems the depend on the same protocols), via the Open Specification Promise.

“First off, let me say that this is a huge step forward – there’s been a great deal of uncertainty around WS-* and friends because of the various patents various companies own. Microsoft taking this step definitely helps.

“But, there are some details that worry me – firstly I am curious why Microsoft have taken the approach of this promise rather than an explicit licence. I’ve talked to various lawyers about it, and the general feeling I get is that they’d be more comfortable with a licence, but they can’t point to anything obviously wrong with the promise approach.”

So I need to make it absolutely clear that if anyone feels more comfortable with a RANDZ (Reasonable and Non-Discriminatory Zero Royalty) License rather than the Open Specification Promise, Microsoft will be happy to provide them with one.  The goal was simply to provide a simple, clear alternative for those who wanted one.  Ben continues:

“Secondly, there’s this definition:

“’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.

“(my italics). Now, I’ve implemented a lot of software from protocol specifications, and there are two things that are extremely common:

  • “The specifications include many optional parts. These parts will not be covered by Microsoft’s promise.
  • “The specifications reference other specifications for vital parts of their implementation. These parts will not be covered by Microsoft’s promise.

“Now, exactly what affect these considerations have on Microsoft’s promise and implementations of WS-* et al is something I have not had the time or energy to assess – perhaps others with more intimate knowledge of the specs could help me out there? I’d love to hear that, in fact, this is a non-problem.”

It may help to recall what Standards Guru Andy Updegrove says about the phrase “…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.”

But I do understand Ben's question about the required versus optional parts of a specification and will ask our legal people to clarify. 

Ben's next point:

“Another factor to consider is that (as I understand it) Microsoft are not the only people with IP around these standards. Will everyone else be so generous with their IP? Microsoft don’t care, of course, because they have the usual patent mutually assured destruction – but those of us with smaller patent portfolios are not so fortunate.”

So, as always, I guess I’m an optimistic cynic.

Incidentally, another thing Kim has talked about several times is Microsoft allowing exact copies of their user interface. I’m in two minds whether its a good idea to copy it, but this promise doesn’t cover the UI, as far as I can see. I wonder when that piece will be forthcoming?

I really want to make it clear that I have never suggested I would ask Microsoft to allow people to make “exact copies” of our user interface.  And in fact, no one has ever asked to be able to do this.

What we want to be able to do is create a “ceremony” that is recognizable across platforms.  I'm talking about the equivalent of using a steering wheel and brakes in a car.  All cars have them, so even if we like a particular type of car, we can get in another one and drive it.  This doesn't mean the cars are “exact copies” of each other, or even that the steering wheel and brakes look or feel identical. 

As Novell's Dale Olds put it at DIDW, we are talking about sharing a predictable sequence of experiences, not cloned screens.  So in this sense, I think everyone shares Ben's “two-minds” thinking.