Kim Cameron and DRM

Ben Laurie thinks I was damning digital rights technology when I complained about not being being able to burn some of the Modern Times songs I had paid for and downloaded. He writes:

“Kim’s got all steamed up over iTunes’ DRM.

“Perhaps a better target for his vitriol would be his own company’s DRM, which will not only prevent you from burning stuff to CD, it’ll even remove your right to play it after you’ve purchased it.”

Why?  The parties to a transaction may feel fine about a contract limiting the number of times content can be burned or played.  I have nothing against that.  Let a thousand flowers bloom.  I'm not against technological capabilities, if they are reliable and people want to use them.

But I went to iTunes for two reasons.  First, it had the album that I wanted to burn to CD.  Second, its policy said you can burn your downloaded songs onto CD seven times.

If iTunes had announced more draconian rules, I just wouldn't have gone there.

The problem is that some of the songs were not covered by the announced policy. 

Some have argued the tracks in question aren't songs, they are “videos”. 

I still think they're songs even though you can see Dylan's mouth moving.  At any rate, for four titles – that I also paid for – the sound of Dylan and his band is now caged up inside  iTunes’ proprietary environment.  I can't burn them.  And I can't hear them in my car, on my stereo, or on my television.  I have to use the iTunes application.

Selling me songs and then saying they're not songs and that they're bonus items is really the pits.  iTunes songs cost $1.00 each.  There are 10 songs on the album that can be burned to CD (cost of that is $10.00).  But I paid $14.00.  So the extra songs are not a bonus – they're charged at the same rate as all the other songs – but can't be burned.

All of this is what leads Cory Doctorow to ask if there is a two-tiered music distribution system emerging, and I think it's a very good question.

Music that can only be played on a television.

Julian Bond takes Cory's “new business model” thinking even further:

Cory has been talking about : Kim Cameron having trouble with missing tracks from Bob Dylan's CD “Modern Times”

There's another way to get Modern Times and burn it to a CD: you can buy it from

But go here and you'll find AllOfMp3 only have the 10 tracks off the Audio CD. Not the 4 tracks off the DVD.

I think we're going to see more and more of this. A CD packaged with a DVD containing videos of additional tracks. Ripping the audio from the DVD's videos is considerably harder than ripping a CD to MP3. And it opens up an avenue for the record companies (and by implication iTMS) to change the rules.

To a certain extent I admire this. It's a way of making the physical object worth more than the digital download. But it can also be seen as yet another example of DRM. In this case, the stronger DRM present on a DVD than the unprotected audio CD. The big downside of course is that the DVD is only playable on a DVD player. Which for many will mean no playing in the car, on a portable CD player or on the average stereo. That seems quite a strange idea. Music that can only be played on a television.

A two-tier music distribution system?

Just when I was getting over being traumatized by a glitch in the iTunes user interface, Cory stirred me up again.  Good thing that the tracks I can actually play on my stereo are so wonderful.    

If you buy the latest Bob Dylan album from the iTunes Music Store, be prepared to lose four of the tracks when you burn it to CD. Four of the tracks on “Modern Times,” which is only sold as a whole album on the iTMS, are only made available as video files, and iTunes isn't designed to allow you to burn the audio portion of a video when you burn your CD.

The CD version of “Modern Times” comes as a 14-track disc that includes the audio of the four iTunes videos; also included with the CD is a DVD carrying the four videos. In other words, if you buy the packaged good, you get the audio and the videos for the final four songs, if you buy the iTunes Store version, you only get the un-burnable videos for them.

I got this information from Amazon and I suspect Cory did the same.  But I haven't actually seen the molecular product, which is confusing because there are two versions as well, so maybe the same problem of unrippable music exists there.  It doesn't change much, despite what deadlocked says. 

The iTunes experience is lauded for its consistency and fairness, and for the ease with which iTunes customers can convert their purchased songs into MP3s. But this is a dramatic failure of the consistency, clarity and ease of iTunes.

First, when you attempt to burn the album (with the video-files, which are only distinguished from the audio-files by a small, obscure grey icon) to CD, the iTunes error message says only that the files “cannot be burned to an audio CD,” which led Kim Cameron, an experienced computer user and IT executive, to conclude that the files were locked — an error stating that these were video files would have been clearer.

A really confusing user interface

You know, Cory's right. I am an experienced computer user. And I was really confused. Maybe I'm being punished for the people I've confused with some of my own early interfaces?  I sure didn't liken any part of this experience.

Second, the whole Modern Times package defeats the simplicity of the iTunes pricing model — $0.99/track for any track. While the $14 price-tag gets you 14 “tracks,” it's not possible to buy singles from the disc, nor is there any discount for buying the whole CD instead of a tack-by-track purchase. And since four of the tracks are not “music” in the sense of being burnable and rippable, you're really paying more on a per-track basis. Remember the outcry when Edgar Bronfman, Jr threatened to raise the cost of some iTunes songs and lower the cost of others? Here we have a similar kind of differential pricing sneaking in via the back-door.

Finally, here's a way in which buying iTunes tracks creates real long-term lock-in to iTunes and iPods: since iTunes videos are locked to the Apple platform, and since the only way to get any of Modern Times through iTMS is to pay for these videos, Apple and Dylan are slyly adding some lock-in to the user experience without any explicit statement about it.

Apple could make this much better by offering both the videos and the audio, or by patching iTunes to allow for burning of the audio portion of videos. But better still would be to turn off the DRM altogether. There's another way to get Modern Times and burn it to a CD: you can buy it from, a service of disputed legality, for a fraction of Apple's pricing. Or you can download it from a P2P network. Apple's offering costs more and does less than its competitors’. How can this possibly be good business-sense?

Well, there is one way. By providing crippleware files, Apple makes it harder to switch to a competing portable player. And by giving Apple permission to cripple his music, Bob Dylan makes it harder for his fans to change to a competing service, which in turn makes it harder for Dylan to re-negotiate his own deal with Apple. Let's hope that Apple's interests and Bob Dylan's interests remain identical forever, then, for his sake.

Enough on iTunes and Modern Times

Now it appears Amazon had it wrong all along.  Apparently Disc 1 of the molecular version is missing the songs in the four videos as well.

Even in BrickAndMorterville you can't put the soundtracks of the DVD onto a CD because that would break other, more draconian, DRM.

So I guess I'm just supposed to accept the fact that I can't get all the songs (regardless of the format they came in) onto a CD – even though I have bought them.

Videos apparently aren't songs, although people are singing, so it's OK if they're trapped inside their iTunes cage.

That's life in Modern Times. 

Advanced auditing at Centrelink

Phil at Improving New Account Opening speculates about Centrelink's auditing system while making the important point – not necessarily related factually to this incident – that auditing systems can themselves raise privacy issues.

Kim Cameron's Identity Blog highlighted the case of more than 100 Australian government employees being forced out of a single agency for snooping on client information. According to the Sydney Morning Herald article, hundreds more were demoted or faced salary deductions as punishment.

Interestingly I have a little insight into some of the Centrelink agency's online applications. Despite this, the rest of the specifics to Centrelink in this post are wild speculation, so take them with a pinch of salt.

The agency provides a range of online services to Australians, especially around benefits and financial support, and enables users to perform many interactions and transactions with the agency online. This leads to approximately 80 million online transactions per week. As I understand it, before going online the agency had struggled with how to counter individual users claiming that information they had (or had not) provided online was incorrectly recorded, leading to incorrect payment of benefits and other issues. This would mean that cases that led to litigation would be hard to defend. The requirement for non-repudiation rested with the agency and this proved difficult for them to address.

Here is where the wild speculation starts. Centrelink is considered a gold-standard in the Australian government for an online service that is secure and trusted. It employs a website monitoring application called WebCapture that for online transactions records both the information presented to a user, the forms they see and the documents requested, alongside any information that users enter into forms, the options they select, links they follow and buttons they click. This information is recorded on the web-server, stored to a repository and may be played back by authorized users as a virtual video recording of the entire transaction. As I understand it, the captured, replayable transaction has been tested in court as having appropriate legal weight to provide non-repudiation: the logged in user did perform the transaction, and this is exactly the information they were presented and they responded with.

I am guessing if some of the employees in question used this monitoring capability to snoop on customer information that they couldn't access in other systems. WebCapture information is held in an extremely secure repository, with metadata passed to a standard database. The question is whether the agency effectively designed and enforced their security policies with respect to accessing this data. A system's security is only a strong as the security policies you define for it. In this case, it may be that the WebCapture repository or associated database was the subject of poor IT security policy enforcement or poor governance around the maintenance of those policies or the users that could access it.

If this scenario is actually true, it highlights an issue that should be obvious, but may have been missed in this case. As we add additional layers of software into our infrastructure, if they are not subject to good IT governance and management processes they may be fraudulently used to access personal data and transactions, or lead to other security issues. Every new layer of infrastructure needs to be managed – personal data does not just reside in the database anymore.

With good governance and management of the systems and security policies using best practices like ITIL, a system like WebCapture can provide undeniable proof of transactions performed by clients, protecting the organization from false claims and litigation. This is a huge benefit to an organization like Centrelink. There is no substitute for good management of data in all IT systems, not just the database.


Window Live ID Whitepaper


Since its inception, the Microsoft Passport service has existed in a digital world that is increasingly multi-centered and rich in contexts. This digital world requires the sharing and federation of identities and close attention to matters of user control. These requirements have led Microsoft to evolve the Passport service continuously. To emphasize this evolution, Microsoft is changing the name of the service to something more indicative of its specific contribution to the emerging “identity metasystem”: the Windows Live ID service.

Windows Live and Office Live are Internet-based software services designed to deliver rich, seamless experiences to individuals and small businesses. The offerings combine the power of software with online services to make compelling new tools that complement Microsoft Windows and Microsoft Office products.

Microsoft online services need to know who is interacting with them—just as users need to know that the services themselves are legitimate. This mutual need requires the use of digital identities. The Windows Live ID service is designed to manage identity and trust within the Windows Live ecosystem.

For end users, the Windows Live ID service provides roaming access to the broad array of Microsoft online services. For developers, it enables over 300 million potential online users to access their applications.

What Are Windows Live ID and the “Service”?

A digital ID is a set of claims made by one entity about another.

A Windows Live ID is a set of claims that the Windows Live ID service makes.

These claims can refer to individual users, organizations, devices, and services. Initially, most claims will be based on information stored in accounts the service maintains on behalf of its users, in much the same way that Passport has worked in the past. Moving forward, the service will also rely upon the claims issued by other federated identity providers, transforming them to make sense within the Windows Live ecosystem.

What kinds of claims can a Windows Live ID contain?

  • User's e-mail address
  • Type of entity (such as organization, group, or namespace)
  • Relationships among subjects, such as:
  • Parent-child relationship.
  • Administrator status or ownership of an organization, group, or namespace.
  • Membership in an organization, group, or namespace.
  • Authorization for specific scenarios, such as enforcement of parental controls
  • User ownership of a public-and-private key pair, for use in peer-to-peer communications

Windows Live IDs that are based on Windows Live ID accounts (as opposed to federated IDs) can be authenticated using traditional user-name/password pairs, strong passwords and security PIN combinations, and smart cards. Windows Live ID will also support the use of self-issued “InfoCards.” For example, users will be able to employ “InfoCards” to access Windows Live Mail. For more information, see “InfoCard” Support later in this document.

The Windows Live ID service also maps federated IDs supplied by other identity providers into a form that works within Microsoft online services. This is done through protocols like WS-Trust, WS-Security, and WS-Federation—widely accepted, royalty-free industry protocols that can be (and have been) implemented on any platform. WS-Security is already an OASIS (Organization for the Advancement of Structured Information Standards) standard, while WS-Trust and other related protocols are in the standardization process now. Because “InfoCards” also implement WS-Trust, the Windows Live ID services federation servers will be able to accept “managed InfoCards” too.

So that customers can access Microsoft online services by using any device, the Windows Live ID service also supports specialized mechanisms (like the Radius protocol) for authentication from cell phones, televisions, and Xbox 360. Through these devices, Windows Live ID also supports applications that range from dial-up service to peer-to-peer instant messaging.

For developers, Windows Live ID provides programmable interfaces that reduce development time on both the client and relying-party server sides, making it easier to develop new identity-aware services for the ecosystem and new client products to access them. The Windows Live ID services are also accessible through soon-to-be-published protocols.

High-Level Architecture

The following figure is a high-level illustration of the ecosystem in the Windows Live ID world.


How Does Windows Live ID Relate to Passport?

The Windows Live ID service represents the evolution of Microsoft Passport into a world based on federation. Windows Live ID will be the authentication system for all existing and future Microsoft online services. Relying parties (Microsoft properties and those of close partners) who have implemented Passport will be compatible with the Windows Live ID service.

Another area of evolution is towards support for “rich clients” using Web services. By supporting WS-Trust and “InfoCard,” Windows Live ID will extend its single sign-in framework to the Windows Communication Framework (WCF) employed in many emerging applications.

End users will be offered an automatic upgrade path for using their Passport accounts as Windows Live IDs. Similarly, the Windows Live ID service will be backward compatible with relying parties that have already integrated with the Microsoft Passport Network. However, to take advantage of the new features and scenarios provided by the new Windows Live ID service, relying parties may have to adopt new software development kit (SDK) components and protocols.

How Does Windows Live ID Participate in the Identity Metasystem and Work with “InfoCard”?

Microsoft is working with others in the industry to create an identity metasystem that brings existing and future identity providers into a connected identity ecosystem and empowers end users to control the use of their identities. The Windows Live ID service will participate in the identity metasystem as one identity provider among many, able to accept claims from other identity providers and transform them so they can be used within Microsoft online services. This participation will include acceptance of self-issued and managed “InfoCards.” It will thus provide full support for the “InfoCard” identity model.

Roles of the Windows Live ID Service in the Identity Metasystem

Microsoft has published its vision of a universal identity solution that is inclusive of a plurality of identity operators and technologies—the identity metasystem. In such a metasystem, identity providers, relying parties, and subjects can select, request, transfer, transform, and consume identities through a suite of well-defined and open Web Services (WS-*) protocols. Microsoft is working to implement components of the identity metasystem, as are many other companies in the industry. As a result, various building blocks for the metasystem are being developed. Some of these components will be delivered to end users in the form of software installed and running locally on their computers and devices, while others will be online services.

The design philosophy of the identity metasystem is not to replace the existing identity systems in use today, but instead to bring these existing systems together by enabling interoperation among subjects, relying parties, and identity providers through industry standard protocols. The Windows Live ID service will participate in the identity metasystem as a “managed” identity provider already at Internet scale. Windows Live ID will bring a large base of end users and relying parties to the metasystem, taking us one step closer to Internet-wide identity federation and doing our part to help the industry move beyond the “walled garden” paradigm.

The Windows Live ID service will play several essential roles that are strategic for Microsoft. The service:

  • Is an Internet-scale identity provider intended primarily for users of Microsoft online services, which are all relying parties of the Windows Live ID service.
  • Is open and issues claims in a form that can be consumed by any relying party, any device, and any other trusted identity authority.
  • Serves Microsoft online services as a “claims transformer,” allowing those services to accept identities issued by third-parties. Third-party identity providers include other Internet service providers and managed-identity providers, such as the planned Active Directory Security Token Service (STS).
  • Will be the identity provider and federating authority for third party services and software built on top of the Microsoft online services platform.

“InfoCard” Support

“InfoCard” is the code name for the Microsoft implementation of an identity selector for the identity metasystem. “InfoCard” provides a consistent experience for users to manage, control, and exchange their digital identities. It is an important step towards eliminating user names and passwords as the primary mechanism by which users identify themselves. “InfoCard” provides a safer way for users to manage and exchange their digital identity information, helping to protect them from various forms of identity fraud.

For more information, see the InfoCard site in the WinFX Developer Center.

Since Windows Live ID is designed to robustly manage user identities, it will support “InfoCard” when “InfoCard” is broadly available (expected in the fourth quarter of 2006 for Windows XP, Windows Server 2003, and Windows Vista).

The current plan is that Windows Live ID will support both self-issued and third-party managed cards as a mechanism to authenticate users when accessing Windows Live services. Subsequently, Windows Live ID will also issue managed cards to enable users to use their Windows Live ID with third parties.

Together, Windows Live ID and “InfoCard” will enable users to enjoy the rich array of Windows Live services more easily than ever before.


The Microsoft online services are designed to become an Internet programming platform for developers to build desktop applications and online services. (For more information about this platform, see the Windows Live Developer Center.)

So Microsoft must make it easy to program for the Windows Live ID service.

To simplify integration on both the server side and the client side, the Windows Live ID service will release software development kits (SDKs) later this year. In addition, the Windows Live ID service uses industry standard protocols. For cloud server-to-server scenarios, the Windows Live ID service exposes programmatic interfaces by way of SOAP services.

The Relying Party Suite (RPS) SDK makes it easier and cheaper to develop a new Microsoft Live service by providing interfaces that prepare authentication requests, decrypt, parse, and validate security tokens, and manage authentication-state cache in a browser session.

But more importantly, RPS reduces operational cost by providing support for configuration refresh—critical for partners that host services from different global geographic locations, and for times when it is necessary to change cryptographic keys.

A second SDK—the Windows Live ID Client SDK—runs on end users’ computers. This SDK makes it easier to write new client applications that understand Windows Live IDs and supports the sharing of authentication state across multiple rich clients and browsers. It also manages short-lived certificates issued by the Windows Live ID Certificate Authority; these certificates can be used in security-sensitive applications such as peer-to-peer communication channels.

Like the Relying Party Suite, the Client SDK supports the automatic configuration and refresh mechanisms critical to accommodating the Windows Live ID services “geo-hosting” plans.

Windows Live Messenger is an example of a client built on top of the Client SDK.

Advantages of the Windows Live ID Service

Through years of developing and operating one of the largest identity providers on the Internet, Microsoft has learned valuable lessons from customers, Internet security professionals, and developer communities worldwide.

Large Scale
The Windows Live ID service is the next-generation version of a system that does over 22 billion authentications per month and is used to access a large set of online services operated by Microsoft and its close partners.

Security is a priority for the Windows Live ID service, which undergoes regular audits performed by independent auditors. Microsoft is committed to investing in security to help protect customers and relying parties against ever-evolving threats.

Quality of Service
The Windows Live ID service is built on top of a highly available infrastructure, including redundant networking elements, front-end and back-end servers, and fault-tolerant software components. The services are continuously monitored by multiple automated agents including internal tools and external monitoring services. Windows Live ID is built on components that have demonstrated a high quality of service.

APIs to Speed and Simplify Deployment

The Windows Live ID service is designed with development support in mind. All functionality is exposed through programmable SOAP interfaces that will be published soon. The Relying Party and Client SDKs ease development efforts for both relying-party services and rich-client applications, and help to deliver robust and efficient components to run on relying party servers or end-user computers. The SOAP interfaces are documented and will be available to all, enabling Windows Live ID services to be used in contexts not using the other SDKs.

Seamless User Experiences

The Windows Live ID service delivers a seamless user experience across client applications and Web browsers accessing relying-party services.



I thought the following excerpt from a thoughtful piece by Steve Bryant at eWeek‘s GoogleWatch might interest you.  Steve is led to consider the Third Law of Identity – Justifiable Parties: 

Why does Google want to automate the advertiser click cycle and make it as fast as it possibly can? 

The first reason is obvious: Google makes money on click conversions. The more clicks done quickly, the more money for Google, and the happier the advertiser.

The second reason is that by automating the click cycle, Google will be vastly improving the efficacy of its search results, and how searches correlate with AdWords. Unlike destination sites that measure success by how much time is spent on a page, Google measures success by how quickly a user navigates off Google. The company is constantly testing out data centers to see which center returns the best results that get users off Google quicker.

There are other reasons: Google will begin compiling transactional data. That data alone, even without trending analysis, is worth billions. Google will also become the first company to own not only the method of advertising, but also the data on what advertising works best. Perhaps most importantly, GBuy, when combined with Google's new Cost Per Action feature, has the potential to significantly reduce click fraud.

But there's the rub. Will merchants actually use GBuy?

Of course, you say, why would they not? You could use Google for everything! AdWords, Page Creator, Analytics, GBuy … it's a virtuous circle of Googledom. And yes, even a curmudgeon like me is attracted to the idea of one Google to rule them all.

But let's not forget this has been tried before. It was called Yahoo PayDirect. Yahoo started the service as a competitor to PayPal. Unlike Google, Yahoo had a product incentive for this service. That is, Yahoo had a then-robust classifieds and auctions business that it wanted to tie PayDirect into. The math was simple: User browses Yahoo products, user buys with Yahoo system, Yahoo gets profit. PayDirect was free (most of the time), but it didn't work. Yahoo folded PayDirect in 2004, mostly because PayPal simply owned the market.

Of course, Google has several competitive advantages that Yahoo did not have. But what Google doesn't have — and this is important — is product to sell.

The main reason PayPal succeeded was because eBay was developing at the same time. There was no other easy way to pay an auctioneer, so users turned to PayPal. The two companies became so closely intertwined that eBay decided to buy PayPal and integrate it directly. Purchasing PayPal made perfect sense. As a merchant, why would eBay want give another vendor control of its clients?

This is the challenge that Google faces with GBuy. If you talk to a lot of retailers, I think you'll hear them saying the same thing: “Why would I give Google control of my customer?” Google's not selling anything. And traditionally, the merchant takes payment for an item because it's the merchant — not Google — that has to fulfill the order.

Of course, there is a new breed of merchant online that just aggregates content and has no interest in owning customers at all. Think Shopzilla. For sites like those, perhaps GBuy is the golden ticket.

But back to the traditional merchants. Online merchants already track purchases made via Google AdWords. They've already bought software to track orders, or they've integrated a code into their inventory systems that correlates a sale with an AdSense referral. There's an entire marketplace of shopping cart software that's already integrated PayPal.

So the question inevitably becomes: If I'm a merchant, and I've already gone through the trouble of integrating PayPal, and PayPal is cheaper and it's trusted, why would I switch to GBuy?

One possible answer to that question is that GBuy is free for AdWords customers. Yes, that's a great incentive. But don't expect GBuy to eclipse PayPal with that feature alone. Companies with large marketing budgets will be advertising over multiple sites, not just with Google AdWords. Does it make sense to switch to GBuy for a 1-2 percent gain? Perhaps.

At any rate, the market will decide. I'm still cautiously optimistic about GBuy. If merchants can be incentivized by the potential to reduce click fraud, and if they're not leery of giving too much control to Google, perhaps they'll switch…




This tutorial includes a demo, an explanation of how Self-Issued InfoCard identity tokens work, and sample PHP code allowing you to accept these tokens at a web site.

One of the key goals of InfoCard and the Identity Metasystem is to put the release of identity information under the direct control of computer users.  At the same time, the system respects the right of a web site to say what information it requires to grant entry.  The accompanying demo shows how InfoCards help bring the two sides of this equation together in a way that accords with the Laws of Identity.

Information Card technology can be used to manage the exchange of any kind of token.  CardSpace&#39s self-issued tokens use the SAML format.  With this format, identity information sent to a site is “signed” to guarantee that it really comes from whoever originates the “claims” in the identity token.  Then, to protect the user&#39s information during release, it is encrypted so only that site can get at it.

How can the identity provider encrypt the information destined for your web site?  You need a public key and certificate.  In the current version of InfoCard this has to be an SSL certificate (mine cost me under $20), and your web server needs to be able to support https.  Identity tokens sent to you will be encrypted under the same key your system uses for https.  If people need help with this, let me know and I&#39ll add instructions to this tutorial.

I wrote my sample code in PHP 5 (I had a 4.2 version running at one point, but didn&#39t want to keep two versions going).  If you wonder why I chose PHP, I wanted it to be clear that InfoCards are not Windows-specific.  You need to make sure your version of PHP has the mcrypt and openssl libraries enabled.  (By way of example, these libraries are part of the default environment at TextDrive, my excellent web site host.)

I would suggest you approach this tutorial as follows:

  1. Watch the demo.  Use this version for Windows Media Player.  (If your system complains that it requires the Techsmith Screen Capture Codec [TSCC], pick it up here.)  If you can&#39t use TSCC, try the much fatter Quicktime version (doubleclick on the demo to start it).
  2. Learn about the Encrypted SAML Token, and then how to decrypt it to reveal the signed token.
  3. Learn about the Signed Token, and how to verify it.
  4. Look at the sample HTML page and mainline that constitutes the demo.

You can download the sample PHP files here (I updated them to V3 in June 2007 to make the code compatible with the shipping version of Vista, and at the same time embrace the new OASIS claims names.)

I&#39ll be evolving this work over the next little while, so let me know about anything that is unclear or not pitched at the right level.

People have asked if I&#39ll be putting this tutorial into .pdf format.  I will, once I&#39ve received a bit more feedback.  In particular, I&#39m hoping some PHP gurus will look things over – this is my first PHP project.

I&#39ve also been asked what intentions I have for this code. My only goal is to share information as widely as possible.


I&#39ve been promising to share the sample code I wrote to InfoCard-enable my site.

Working on this, it became pretty clear that I needed to explain how tokens work before I could explain how the related code works.

And then, since few people so far have access to InfoCard bits compatible with my site, I saw that I needed to do a demo of what the user experience would be, showing how InfoCards actually work.

Finally, thanks to the review work of a number of colleagues across a number of different companies, I have a Simple InfoCard Tutorial and Demo ready for you to try out.  Watch the five-minute demo, and then follow this link into the tutorial.

Are you using Windows Media player?  Then use this version of my demo, encoded with the Techsmith Screen Capture Codec (TSCC).  If your system complains that the codec isn&#39t installed, it is totally worth picking it up here.  It does a tremendous job of compressing demos.

If your player doesn&#39t support TSCC, I hope the Quicktime version will help.  I found I had to download the whole file, then click on the icon to open Quicktime, and then double click on the demo image to make the demo start playing.  Am I doing something wrong?  The biggest drawback seems to be that the encoding is four (4) times larger than the TSCC version.  But hey, it works, and I like the way you can drag the progress bar to jump around within the demo.

Thanks to Robert Richardson for helping me understand the codec issues.  If others have advice for me, please send it, since I want to do more demos in the near future.

I&#39ll be evolving this work over the next little while, so let me know about anything that is unclear.  I&#39ll also add some demos of what it looks like using InfoCards on  the compatible sites that have been created by Chuck Mortimer and Ashish Jain.

Once I get more feedback on what can be improved, I&#39ll assemble the tutorial into .pdf format, and make a zip for downloading the samples, .

Someone has asked me what intentions I have for this code.  My only goal is to share information as widely as possible.


Brick and Mortar Cards with Chips

British Identity CardI&#39ve been learning more about British Identity Cards. Here is how the BBC covered introduction of the legislation by Home Secretary David Blunkett, who said polls showed 80% of the population supports the initiative.

The proposed Bill is short (sixty pages) and makes an interesting read – if you are an identity freak. The typical Labour Member of Parliament talks about it this way. The Conservative Party supports the initiative too (though it worries that it is tainted by Labour&#39s sponsorship…) At the other end of the spectrum, the Liberty human rights organization (no resemblance to the American Liberty Alliance) is critical for several reasons – including cost and the lack of protection from “feature creep”. The BBC&#39s ‘briefing page” is here.

The plan is to phase the card in over time, and although its use is initially optional, the bill lays out procedures to make procurement of a card mandatory for various “groups of persons”. Everyone would be required to have a card by 2013. People will use the card in order to gain access to government services – or when required to do so by the appropriate authorities.

The British card is so far very much framed for use in the brick and mortar world. It ties citizens to an entry in a centralized “registry” that would contain the following information (details are here):

  • personal information: names, birth date, current and previous addresses
  • identifying information: photograph, signature, fingerprints, other biometric info
  • residential status: nationality, terms and conditions of entitlement to remain in the United Kingdom
  • personal reference numbers: national identity number, national insurance number, and the numbers on ID cards, passports, immigration documents, work permits, driving license, and other documents issued
  • record history: circumstances surrounding changes in information; date of death
  • registration and ID card history
  • validation information
  • security information: personal identification number, password, questions and answers used for identification
  • records of provision of information: all kinds of information about the circumstances under which information from the registry was disclosed to others

Reading the Bill, there is no obvious discussion of use of the cards for identification in the virtual world. Yet it is inevitable, going forward, that as more governmental services are offered through electronic means, the government identity card will become a digital identity for use in dealing with Government services.

We can thus say that from the point of view of creating a universal system of digital identity, initiatives such as this one are essential features of the emerging landscape. A universal system should be able to integrate governmental identification in the appropriate contexts, which in turn will vary on a national basis according to what the British Information Commissioner calls “the relationship between state and citizen”.

The issues of identity in the Brick and Mortar world are outside the scope of the discussion I am animating here. But it seems the British Government could benefit by looking into the Fourth Law of Identity, and actually taking more advantage of the cryptographic capabilities of state-of-the-art cards. So far, it seems that the new identity cards, despite the presence of a nice golden chip, are conceived of just like their old-fashioned plastic predecessors.

The government says it is far too early to have worked through the specific implementation that will be deployed – and that it is still open to proposals. So maybe technical thinkers in Britain will be able to convey some of the technological options which can better achieve the purposes behind this initiative.

After all, David Blunkett says, “ID cards will mean people have to give the state less information about themselves.” And Tony Blair says that ID cards would “protect rather than erode civil liberties”. This is actually possible if the card is thought out better. But there is a lot of work to do.

For example, the card could emit unidirectional identifiers for each division of government. Though unidirectional and relevant only in the world of a given department, the identifiers would uniquely identify a person as qualifying for services. In such a scheme, one&#39s health records would not be keyed directly to one&#39s driving license or income taxes, because the card would produce a different, but still official, identifier for each department. The various departments could then be made accountable for storage of only that information which concerns them. And a breach of one of these systems would result only in the breach of a small subset of a citizen&#39s information, directly addressing the legitimate concerns of the Information Commissioner.

At the same time, the full set of unidirectional identifiers associated with a given person could be made available through another closely guarded system. The security of this system could be based on separation of duties – such that some procedure would need to be followed to obtain knowledge of the set of identifiers emanating from a single ID card. Armed with this set of unidirectional identifiers, an authorized investigator could assemble relevant information from all the departments stewarding specific knowledge. By combining cryptography, networking and web services, this kind of distributed system would provide information in as timely a manner as the one currently proposed.

In this scenario the state obtains the ability to garner the information it needs while protecting the privacy of its citizens and without creating a central storage site that would be nothing if not an information-disaster-waiting-to-happen. As a technologist I worry that the registry, as currently described, has been devised without regard to the laws of entropy. Why create a single system that knows everything and thus needs to be accessible by far too many people given the value of its contents?

Somehow I am certain that no political person or senior civil servant would want to be the father of a system embodying so much risk when the same results can be achieved without any risk at all. I hope that as the project goes forward this thinking can be communicated to those involved.