Month: July 2005

In the abstract for my paper on the Laws of Identity, I wrote:

Ben Laurie commented on my response to Doug Kaye's challenge with this:

This punts completely on a pile of issues that aren't obvious from your example. The top of my list are:

a) How do I know that Kim Cameron is the person who “signed” the release.

b) How do I know that Kim Cameron has anything to do with the event (that is, suppose (a) is satisfied, how do I tie that identity to the performance that is included in the event?)?

I think what Doug was looking for was a way to eliminate his liability from a content provider point of view. Thus the issue is not whether the real Kim Cameron is signing the release – it is whether the person speaking at the event has signed the release. Let's assume Darth Vader poses as Kim Cameron and speaks at the event. With the proposal we have outlined, Doug can be sure that Darth can't claim he didn't give approval to podscast his duplicitous public appearance. In this sense, the podcast stands.

The issue of whether Darth is Kim (or visa versa) is a matter of normal journalistic integrity, and concerns the relations between IT Conversations and its producers. It is a completely different question – potentially involving the identity metasystem but potentially involving a number of other brick and mortar approaches.

What I found so interesting about Doug's problem was that it was the identity of the event and its participants – as participants – which was at stake. The “context” was really unique.

Over at Blogarithms, Doug Kaye has a challenge for identity people:

Okay, all you identity gurus. (And I know you’re reading!) Here’s today’s challenge for you. For the new project we need to make sure we have authorization to record and publish tens of thousands of events every year from all over the world. How can we be reasonably certain that the person who gives us such permission is who they say they are and that they’re authorized to grant such permission?

It’s easy on the relatively small scale of IT Conversations. We have a written contract with each of the events we publish. But that’s not scalable worldwide and with the volume we anticipate.
I thought of one way we could do this, based upon the technique that Technorati uses to allow someone to claim an RSS feed. To demonstrate that the person has some association with an event, we could require that they add some invisible unique string to the HTML of one of the web pages associated with the event. We parse the HTML, find the secret string and close the authentication loop. The only problem is that we’re then limited to events with an on-line presence.

Got any better ideas for this one?

There are a number of good comments posted already. The difficulty here is that you have a number of parties involved who are collaborating (those being recorded as well as those doing the recording), and you require related releases from each of them with regard to some specific event.

In my view, Doug is – at the highest level – on the right track. Why? His scheme hinges on the identity of the event (it proxies this identity through the publisher of the web page tied to it). So I buy the high level approach.

However, there is another way to do it – this is part of some thinking I’ve done on related issues.

It would call upon the sixth law of identity – that the users of the system must be part of it, participating and understanding the system through a “ceremony”. Would it be possible to develop such a ceremony?

How about something like this:

1. Prior to a podcast, the “producer” runs a Podcast Ceremony Generator (C-Generator) on his workstation.

2. He enters the title and date.

3. The C-Generator creates four things:

• A private key available only to the producer.
• An event number which is a one-way function of the public key corresponding to the private key plus the date and title (example: X29 3BU 4PK).
• An html page containing a Podcast release script that can be read by the participants
• A record in the C-Generator database that remembers all this stuff.

4. During the mike check for the event, each participant reads the script. This is the ceremony. Here’s an example:

“This is [Kim Cameron] and I grant Scott Mace unlimited [blah blah] to distribute the event numbered X29 3BU 4PK, titled “Interview with Kim Cameron” and recorded on April 1, 2006.”

5. The producer records the participants reading the ceremony script. This is saved as the “Release” audio file.

6. The producer records the event, giving it the right title, event number, date and so on (for maximum protection this could even be part of the audio stream – for example in the closing credits).

“This has been “Interview with Kim Cameron” recorded on April 1, 2006, by Scott Mace with event number X29 3BU 4PK.”

7. After the event, the producer calls up the C-Generator, selects the title at issue, and drags in the Release audio file (recording of the ceremony script) so it will be available if ownership is ever contested.

8. When he wants Doug to post it, he types in the name of Doug’s organization (IT Conversations). C-Generator now produces an XML Release Blob signed by the private key that only the producer owns (and cryptographically related to the release number). He sends this and the podcast in to Doug (possibly the release audio file as well).

So at a high level, the steps are:

1. Produce the release script

2. Have the participants read it

3. Produce the release blob and send it to the publisher along with the program.

The system works this way. There is an event key, and the event number represents this key – along with the title and date – in human-speakable form. The participants sign this event key with their voices by reading it in the release ceremony. Then the producer signs the release with the secret that is provably at the basis of the event number.

The system is based on an algorithm that makes it intollerably expensive to search for keys that would, given a particular title and date, produce a given event number.

Finally, the system would work on web sites, or wherever.

Several readers have sent more information and details on the Belgian Identity Card program.

In a previous posting I said, “the use of government smart cards in establishing digital identity is optional and under the control of the person described.” Apparently my distinction between use of the card for digital identity and bricks and mortar identity wasn't at all obvious, so let me try again.

Belgians who have reached the age of 12 are obliged to carry an ID-Card. In the past this has been a paper ID Card. It is now being replaced by a smart card. It will remain mandatory that citizens carry this identification card.

Twelve-year-olds get a new (smart) card right away. Others in the population already have cards that are valid for ten years. What happens when they expire?

• You get an invitation letter from your municipality.
• You go to the municipality with your old card and the letter.
• You fill in a form, and sign it manually to assert that the data on the form is accurate. You add a picture, and pay between zero and fifteen euros, depending on the municipality.
• A few weeks later you get a letter with a “PUK” and a “PIN Code”, and the request to pick up your new card.
• When you pick up your card, you are asked whether you wish to “activate” it (there is basically an opt-out procedure).
• You use your PUK to activate it.
• You may change your PIN.
• You are done.

Thus, citizens can opt out of using their cards for digital identity purposes. They can opt out in the sense of not activating their card. And if they do activate their card, they can still, if they feel so inclined, opt to use some other authentication mechanism when accessing eGovernment.

Citizens, government departments and businesses will have to be convinced to buy card readers before the eID cards can be used in a widespread way for digital purposes in consumer scenarios And sites will have to provide users with alternatives besides smart cards – at least during the time period when large portions of the population are not equipped with both the activated smart cards and readers.

So while it may be mandatory to carry the card for brick and mortar (physical) identification, we should be careful before making the assumption that the same level of coercion is easy to apply in the digital realm. To me this is a bit of an aha.

The law of user control and consent will continue to make the success of the system contingent on user acceptance – unless a number of draconian changes are made to current legislation.

This emphasizes again the need to see this kind of system as part of a continuum of potential underlying identity options, and indeed, part of an identity metasystem. If we could get the metasystem “out there”, relying parties could accept self-asserted identity starting on day one (certainly a lot better than passwords) and users could upgrade the strength of their authentication just by plugging in an identity provider which recognizes strong tokens like the eID card. We would see the emergence of identity providers that could do claims transformation to suppress the universal identifiers and constant public keys associated with today's eID cards and issue tokens containing minimal necessary information in accordance with laws two and four.

Get the usability and privacy aspects right, and make use of the government identity part of a wider set of identity choices, and end-users will probably come in droves. Especially if eGovernment allows citizens to save time by doing things on the computer which otherwise would require that they visit a government office.

Thanks to Caspar Bowden for telling us about Usable Security, a site which is absolutely fascinating and which concentrates on issues related to the sixth law of identity – the human as a part of the identity metasystem.

As if this site were not enough of a treat already, it contains a link to a paper called Making Prime Usable (this now works again – Kim). Prime is a european privacy initiative that brings together a number of important researchers.

The paper deals with many of the visualization and user experience issues we have encountered during our development of the InfoCard, so I'm reading it with great interest. Authors are John Sören Pettersson, Simone Fischer-Hübner, Ninni Danielsson and Jenny Nilsson from Karlstad University in Sweden; Mike Bergmann, Sebastian Clauss and Thomas Kriegelstein from TU Dresden; and Henry Krasemann from the Independent Centre for Privacy Protection (ICPP) in Germany.

People who care about the sixth law will find this irresistable.

I'd like to share Trevor Lawrence's comment on my answer to Kapil's question about how InfoCards are displayed in the digital identity management interface:

Yes this does help, or rather confirm deductions from scattered information fragments.

It looks at the moment as if the InfoCard UI has a special case built in to allow you to edit your claims in the self-asserted IP that is included. In general, as I understand it, out-of-band mechanisms are likely to be needed to change the claim data that an external IP asserts for a user. (In an authoritive IP I can't just change my passport number without by some other means proving to this IP that that indeed is the number of a new passport issued to me.)

Because of this it seems to me that the current beta InfoCard UI is a bit misleading.

This is a good way to put it. The self-asserted identity provider is special-cased because, after all, the user can change the claims at will.

I agree that without having an example of a managed card which cannot be edited, the current UI is a bit misleading. I hope you'll forgive us – we didn't want to wait until we had added managed cards before starting to share the concepts with the industry.

Channel 9 has posted an interview with me on my Identity work. It was done before I could talk publicly about InfoCards. Actually, I was fairly new to blogging and had written to Robert asking him if he could tell me about video blogging. So I was pretty surprised when he turned on the camera and pointed it at me! Then he told me that was the first lesson. You'll hear the session starting with Robert telling me you shouldn't put the brightest light behind the subject. You'll see I'm a little taken aback when they start asking me questions…

Anyway, it was great meeting Robert Scoble and Charles Torre in person.

Kapil also asks a question about the relationship between Liberty and the Identity Metasystem I have been proposing. First he quotes from the Identity Metasystem whitepaper:

“Participants in the identity metasystem can include anyone or anything that uses, participates in, or relies upon identities in any way, including, but not limited to existing identity systems, corporate identities, government identities, Liberty federations, operating systems, mobile devices, online services, and smartcards. Again, the possibilities are only limited by innovators’ imaginations.”

Then he says,

If I have a Liberty ID-FF or SAML 2.0 enabled IDP which use SAMLRequest and SAMLResponse for security tokens [the WS-Trust] architecture does not help.

My understanding is that this identity meta system is for service providers, identity providers and client machines (infocard system) which are based on WS-Trust and so saying that other participants such as Liberty could participate in this meta system may not be correct.

Perhaps I should have been clearer that Liberty or SAML products would need to add some technology to support the proposed identity metasystem (as would related Microsoft products, for example). I was really trying to point out that everything SAML users and vendors already had in place could continue to work just as it does now, while with a small incremental effort their systems could embrace the metasystem. Sure, it would mean supporting WS-Trust – a protocol designed for metasystem purposes: exchanging one security token for another different security token. But the people who've built SAML systems will have little difficulty going this extra step.

The truth is, to get to a metasystem, it wouldn't only be Liberty or SAML implementors who would have add the token exchange capability – changes would be required in all the systems asserting corporate and government identities; in operating systems, mobile devices, online services, smartcards; and in every other technology mentioned in our whitepaper. No one, including Microsoft, has WS-Trust rolled out at this point in time, so everyone would have to take the plunge.

From what I can see, most people interested in identity see WS-Trust as being a protocol that can really take us forward. But to commit to it, they need to see WS-Trust and its related specifications living in standards organizations. So now, the ball is in our court. We have to deliver.

Kapil Sachdeva, author of SmartCard Serenity, is an identity blogger from Axalto, which Gartner has called the world's leading supplier of microprocessor cards. These are innovative folks, who seemed to have no trouble at all putting full featured Java and .NET implementations into a credit card form factor… I find that sort of stuff amazing. So it will be interesting to see what they do with the Identity Metasystem.

Kapil has raised a couple of questions recently:

There is a nice blog from Andy Harjanto on InfoCard System so do not want to explain here the basic concepts. He has done a great job describing with some sample code all the elements of InfoCard system.

By the way, unfortuntately for us (but fortunately for Andy) he's gone to the (metaphorical) beach for a few weeks… He wanted to stay and work, of course, but what could he do? Anyway, Kapil continues:

I was recently playing with the Avalon and Indigo BETA SDK to see the InfoCard systems in action. There is something which may be confusing (seems like today I am going to talk only about confusions 🙂 ) to some people. With Indigo comes a Windows service called Microsoft Digital Identity service (InfoCard system) which displays a GUI where you could create sets of attributes. These sets are called “Cards”. Lot of people will take this to be “InfoCards”.

Yes, the user is really editing a set of claims forming a self-asserted digital identity that is then represented by an associated InfoCard. Our naming isn't clear enough yet.

Kapil continues:

An InfoCard is just a metadata which says what is the authentication mechanism to be used at STS .. what are supported claims at STS etc. It does not contain the data or attributes about user.

This is exactly right.

Microsoft InfoCard 1.0 Beta 1 GUI displays digital identities of user and not the Info cards. Wish there is a better word MSFT can use for these set of attributes instead of “Cards” to avoid possible confusion.

Well, the question is, does the user have to know about the metadata connecting the InfoCard to the Identity Provider? I don't think so. Therefore we “dereference” the metadata and show the underlying identity information. Developers might find this confusing at first, but what do developers like better than a level of indirection????

Here's our thinking. The InfoCards contain “metadata” just as Kapil says. But when a user looks at an InfoCard, we don't show her the metadata (which would be meaningless to her). Instead, we use the metadata to procure a token, and show the information the identity provider is capable of releasing (in other words the set of claims that go along with that identity).

The user experience is that when they examine the InfoCard they see the contents of the token it is capable of releasing (expressed as a set of attributes).

In the case of self-asserted InfoCards, not only can the user see the related attributes – she can also edit those attributes.

Those who understand the details of the technology will know that the InfoCard is itself metadata, and the user is really examining and even editing the set of claims pointed to by the InfoCard. In the old ‘C’ days we would have said:

userView = *InfoCard;

Does this help?

Here's an article from The Economist that nicely captures the sea change around data protection. It posits that safeguarding of identity assets has become “a business issue” on the “corporate agenda” rather than simply an aspect of IT operations…

IT NEVER rains but it pours. Just as bosses and boards had finally sorted out their worst accounting and compliance troubles, and beefed up their feeble corporate governance, a new problem threatens to earn them—especially in America—the sort of nasty headlines that inevitably lead to heads rolling in the executive suite: data insecurity. Left, until now, to geeky, low-level IT staff to put right, and seen as a concern only of data-rich industries such as banking, telecoms and air travel, information protection is now high on the boss's agenda in businesses of every variety.

Bosses, according to the piece, need to put risk-management processes in place:

“Boards should pay as much attention to these IT operational risks as they do to other operational risks in the firm,” argues George Westerman of the MIT Sloan School of Management. After all, boards have audit committees and compensation committees. It may be time for a data-protection committee, he argues. Bosses must ensure that there are effective data risk-management processes in place, be aware of their greatest vulnerabilities and promote a corporate culture that acknowledges data risks rather than hides them.

But there is a catch:

… the problem is often a lack of understanding by senior managers not just of technology but of business processes, says Thomas Parenty, author of “Digital Defense: What You Should Know About Protecting Your Company's Assets (Harvard Business School Press, 2003). “No one in the organisation bothers to look at the value of what data they hold, the consequences if something bad happens to it, and the appropriate mechanisms to prevent that from happening,” he says.

The bottom line seems to be litigation:

Many of the worst recent data leakages resulted from failure of the most basic kind. The data-processing firm that suffered the breach that exposed 40m credit-card accounts was not in compliance with the security standards of Visa and MasterCard—which may now find themselves liable for negligence. If nothing else gets bosses to focus on data security, surely the prospect of ending up in court will.

I'll be curious to see how you put a price tag on an information catastrophe.