Not the browser!

Google's Ben Laurie bookends our dialog (work back from here) with a really clear statement:

Kim correctly observes that the browser is not the place to be typing your password. Indeed. I should have mentioned that.

Clearly any mechanism that can be imitated by a web page is dead in the water. Kim also wants to rule out plugins, I take it, given his earlier reference to toolbar problems. I’m OK with that. We want something that only a highly trusted program can do. That’s been so central to my thinking on this I forgot to mention it. Sorry.

This sounds really positive.  Now, just so I don't end up with a different security product from every big web site, I hope Ben's work will include integration with the CardSpace framework.  I'm certainly open to discussions about ways we might evolve CardSpace to facilitate this.

Ben Laurie's “Single Passwords”

Given his latest post, I guess I got the gist of Ben Laurie's proposal for using what I'll call “Single Passwords” rather than “Single Signon”:  

“Kim Cameron, bless him, manages to interpret one of my most diabolical hungover bits of prose ever. I am totally with him on the problem of pharming, but the reality is that the average Cardspace user authenticated with nothing better than a password (when they logged into Windows).

Wow.  I appreciate the blessing from Father Laurie, but this is kind of a “We're going to die one day, so who cares if we die tomorrow?” type of argument – surprising for a priest. 

While it's true that pharming is a challenge for the operating system as well as the browser, let's not seriously equate the dangers of entering passwords into browsers (a malleable experience, the goal of which is to be infinitely and easily modified by anyone) with those involved in booting up your PC (a highly controlled environment designed to allow no modification and use a secure desktop).  It's true that both involve passwords.  But the equation is simplistic, best summed up as: “Tables have legs, people have legs, therefore tables are people.”

Anyway, I'm sympathetic to Ben's concerns about portability:

“Furthermore, if you are going to achieve portability of credentials, then you can either do it in dreamland, where all users carry around their oh-so-totally-secure bluetooth credential device, or you can do it in the real world, where credentials will be retrieved from an online store secured by a password.

I don't dismiss dreamland – isn't that what iPhones want to be?  But we do need lightweight roaming.  Using an online vault secured by a passphrase is a reasonable way to bootstrap a secret onto a machine.

But not the browser! 

The rub is:  once a user gets into the habit of typing this secret into the browser, she's ready to be tricked.  I'll go further.  If  the vault one day accrues enough value, a browser-based system WILL fail the user – sooner or later.   

Ben concludes:

“If you believe the Cardspace UI can protect people’s credentials, then surely it can protect a password?

“If it really can’t (that is, we cannot come up with UI that people will reliably identify and eschew all imitations), then how will we ever have a workable, scalable system that includes recovery of credentials after loss or destruction of their physical goods?”

There's food for thought here.  Start to take advantage of the engineering in CardSpace, and you inherit significant protection in terms of both phishing and pharming.  So if Ben implements his “Single Password” this way, he could start to be reasonably confident that the “function of the password” is what is released, while the password is guarded.

Half-life of personal information

In November I coined the term “Identity Chernobyl” for Britain's HMRC fiasco (at least it seems that way when I look at Google).

Cory Doctorow elaborates on this in a nice Guardian piece:

When HM Revenue & Customs haemorrhaged the personal and financial information of 25 million British families in November, wags dubbed it the “Privacy Chernobyl”, a meltdown of global, epic proportions [Hey, Cory, are you calling me a wag? – Kim].

The metaphor is apt: the data collected by corporations and governmental agencies is positively radioactive in its tenacity and longevity. Nuclear accidents leave us wondering just how we're going to warn our descendants away from the resulting wasteland for the next 750,000 years while the radioisotopes decay away. Privacy meltdowns raise a similarly long-lived spectre: will the leaked HMRC data ever actually vanish?

The financial data in question came on two CDs. If you're into downloading movies, this is about the same size as the last couple of Bond movies. That's an incredibly small amount of data – my new phone holds 10 times as much. My camera (six months older than the phone) can only fit four copies of the nation's financial data.

Our capacity to store, copy and distribute information is ascending a curve that is screaming skyward, headed straight into infinity. This fact has not escaped the notice of the entertainment industry, where it has been greeted with savage apoplexy.

Wet Kleenex

But it seems to have entirely escaped the attention of those who regulate the gathering of personal information. The world's toughest privacy measures are as a wet Kleenex against the merciless onslaught of data acquisition. Data is acquired at all times, everywhere.

For example, you now must buy an Oyster Card if you wish to buy a monthly travelcard for London Underground, and you are required to complete a form giving your name, home address, phone number, email and so on in order to do so. This means that Transport for London is amassing a radioactive mountain of data plutonium, personal information whose limited value is far outstripped by the potential risks from retaining it.

Hidden in that toxic pile are a million seams waiting to burst: a woman secretly visits a fertility clinic, a man secretly visits an HIV support group, a boy passes through the turnstiles every day at the same time as a girl whom his parents have forbidden him to see; all that and more.

All these people could potentially be identified, located and contacted through the LU data. We may say we've nothing to hide, but all of us have private details we'd prefer not to see on the cover of tomorrow's paper.

How long does this information need to be kept private? A century is probably a good start, though if it's the kind of information that our immediate descendants would prefer to be kept secret, 150 years is more like it. Call it two centuries, just to be on the safe side.

If we are going to contain every heap of data plutonium for 200 years, that means that every single person who will ever be in a position to see, copy, handle, store, or manipulate that data will have to be vetted and trained every bit as carefully as the folks in the rubber suits down at the local fast-breeder reactor.

Every gram – sorry, byte – of personal information these feckless data-packrats collect on us should be as carefully accounted for as our weapons-grade radioisotopes, because once the seals have cracked, there is no going back. Once the local sandwich shop's CCTV has been violated, once the HMRC has dumped another 25 million records, once London Underground has hiccoughup up a month's worth of travelcard data, there will be no containing it.

And what's worse is that we, as a society, are asked to shoulder the cost of the long-term care of business and government's personal data stockpiles. When a database melts down, we absorb the crime, the personal misery, the chaos and terror.

The best answer is to make businesses and governments responsible for the total cost of their data collection. Today, the PC you buy comes with a surcharge meant to cover the disposal of the e-waste it will become. Tomorrow, perhaps the £200 CCTV you buy will have an added £75 surcharge to pay for the cost of regulating what you do with the footage you take of the public.

We have to do something. A country where every snoop has a plutonium refinery in his garden shed is a country in serious trouble.

The notion of information half-life is a great one.  Let's adopt it.

The tendency for “information to merge” is one of the defining transformations of our time.  When it comes to understanding what this means, few think forward, or even realize that there “is a forward”.

The “contextual separation” in our lives has been central to our personalities and social structures for many centuries.   

Call me conservative, but we need to  retain this separation. 

The mobility and clonability of digital information, in combination with commercial interest and naivite, lead us toward a vast sea of personal information intermixed with our most intimate and tentative thoughts. 

The essence of free-thinking is to be able to think things you don't believe as part of the process of grasping the truth.  If the mind melts into the computer, and the computer melts into a rigid warehouse of indelible data, how easy is it for us to change, and what is left of the mind that is “transcendental” (or even just unfettered…)?

The ramifications of this boggle the mind.  The alienation it would cause, and the undermining of institutions it would bring about, concern me as much as any other threat to our civilization.

    

Scotland's eCare wins award

Scotland's eCare has been recognised at an international awards ceremony on good practice in data protection.  On Tuesday, 11 December, the Data Protection Agency of the Region of Madrid awarded the eCare framework one of two “special mention” awards.  The aim of the annual prize is to expand the awareness of best practices in data protection by government bodies across Europe.

I'm really pleased to see the authors of eCare recognized. They have created a system for sharing health information that concretely embodies the kind of thinking set out in the Laws of Identity.

A Scottish Executive publication describes eCare this way:

The system is designed with a central multi-agency eCare store in a ‘demilitarised’ zone (hanging off NHS net), which links to the multiple back office legacy systems operating locally in the partner agencies. This means that each locality will have its own locally defined and unique approach.

All data shared is subject to consent by the client. The system users are authenticated through their local systems, and are only entitled to view the data of their clients. Clients can change their consent status, and as soon as this is logged on the local system the records cannot be viewed by the partner practitioners.

Benefits that the programme will deliver

The direct benefit to the citizen will be through improved experience of care. Single Shared Assessment, through electronic information sharing, will reduce the volume of questions repeatedly asked by professionals, as data will only have to be collected from the client once, then shared through the technology.

The Children's Services stream will focus on the delivery of an electronic Personal Care Record, an Integrated Children’s Services Record, and a Single Assessment Framework for sharing, to benefit both Scotland’s children, and care practitioners. Across the streams’ care groups, practitioners will save time, because core data will be shared, rather than gathered by multiple agencies. This will reduce the possibility of duplicated or inappropriate care. A more holistic picture of the client will be created, which will help to ensure services that more accurately meet peoples needs.

The principal deliverables of the Learning Disability stream are the development of integrated local service records, which will help planning across a range of services, and the piloting of a national anonymised database, which will enable the Scottish Executive to monitor implementation of ‘The same as you?’ initiative.

Ken Macdonald, Assistant Commissioner (Information Commissioner’s Office, which provided a note of support for the eCare application) has commented:

It is wonderful to see UK expertise in data protection being officially recognised in Europe for the second year running.  Recent events have highlighted the need to comply with the principles of the Data Protection Act and I am delighted to see the eCare Framework and the Scottish Government setting such a fine example to others not just in the UK but throughout Europe.

I hope the work is published more broadly.  From seeing presentations on the system, it partitions information for safety.  It employs encrypted data, not simply network encryption.  It favors local administration, and leaves information control close to those responsible for it.  It puts information sharing under the control of the data subjects.  It consistently enforces “need to know” as well as user consent prior to information release.  In fact it strikes me as being everything you would expect from a system built after wide consultation with citizens and thought leaders – as happened in this case.  And not surprisingly with such a quality project, it uses innovative new technologies and approaches to achieve its goals.

Ultimate simplicity: 30 lines of code

With the latest CardSpace bits anyone who is handy with HTML and PHP, Ruby, C#, Python or almost any other language can set up CardSpace on their site in minutes – without the pain and expense of installing a certificate.  They can do this without using any of the special libraries necessary to support high security Information Card exchanges.

This approach is only advisable for personal sites like blogs – but of course, there are millions of blogs being born every second, or… something like that.  Students and others who want to see the basic ideas of the Metasystem can therefore get into the game more easily, and upgrade to certificates once they've mastered the basics.

I've put together a demo of everything it takes to be successful (assuming you have the right software installed, as described later in this piece).

From the high security end of the spectrum to the long tail

Given the time pressures of shipping Vista, those of us working on CardSpace had to prioritize (i.e. cut) our features in order to get everything tested and out the door on schedule.  One assumption we decided to make for V1.0 was that every site would have an X.509 certificate.  We wanted our design to start from the high end of the security spectrum so the fundamental security architecture would be right.  Our thinking was that if we could get these cases working, enabling the “long tail” of sites that don't have certificates would be possible too.

Let's face it.  Getting a certificate, setting up a dedicated external IP address, and configuring your web server to use https is non-trivial for the average person.  Nor does it make much sense to require certificates for personal web sites with no actual monetary or hacker value.  I would even say that without proper security analysis, vetting of software and rigorous operating procedures, SSL isn't even likey to offer much protection against common attacks.  We need to evolve our whole digital framework towards better security practices, not just mandate certificates and think we're done.

So again, when all is said and done, it is best to promote an inclusive Identity Metasystem embracing the full range of identity scenarios – including support for the “long tail” of personal and non-commercial sites.  One way to do this is through OpenID support.  But in addition, we have extended CardSpace to work with sites that don't have a certificate.

The user experience makes the difference clear – we are careful to clearly point out that the exchange of identity is not encrypted. 

Warnings are presented in words and graphics

In spite of this, CardSpace continues to provide significant protection against attack when compared with current browsers.  You are shown the DNS name of the site you are visiting as part of the CardSpace ceremony, not on some random screen under the control (or manipulation) of a potentially evil party.  And if you have been redirected to a “look-alike” site containing an unknown DNS name, you will get the “Introductory” ceremony rather than the more streamlined “Known site” ceremony.  This unexpected behavior has been shown to make people much more careful about what is appearing on their screen.  Ruchi from the CardSpace blog has a great discussion of all the potential issues here.

What software is required? 

As my little demo shows, if you have a website to which you want to add CardSpace support, all you need to do is add an “object tag” to your login page and parse a bit of xml when you get the Information Card posted back to your site.

On the “client” side, if you are using IE, first you will need to install an updated browser specific extension that will work at a non-SSL site.  If you have IE7 you probably already have it as part of the October security update.  If not, download it from here.

Second you will need to install an updated version of Cardspace that does the right thing when a website (we call it the “relying party”) does not have a certificate.  The latest version of Cardspace can be downloaded as part of .Net Framework 3.5 from here.

For people using Mac and Linux clients, I look forward to the upcoming Internet Identity Workshop as an opportunity to catch up with my friends from Bandit, OpenInfoCard, Higgins and others about open source support for the same functionality.  I'll pass on any information I can at that time.

Once you watch the demo, more information is available here and here and here.  The code snippets shown are here.

Download cheap oem discount software.

OSIS User-Centric Identity Interop at Catalyst Europe

OSIS conducted the third in our series of User-Centric Identity Interop events last week at the Burton Group Catalyst conference in Barcelona. 

As in San Francisco, the Burton Group hosted and provided support for the event, and in this posting, analyst and cat herder Bob Blakley reports on what was accomplished:

There were a few differences between the Barcelona interop and the earlier event held at Catalyst North America 2007.   The most noticeable difference is that the Barcelona interop has been conducted entirely in public.  You can visit the Interop wiki to see details of the organization, planning, use cases, and participants; if you’re in a hurry, though, I’ll summarize here.

Fourteen projects and organizations participated; you can see the list here.

The participants tested 6 identity selectors, 13 identity providers, and 24 relying parties.  The Barcelona interop added a significant amount of testing of OpenID interoperability; 6 OpenID providers and 5 OpenID relying parties participated.

The participants have posted their results on the wiki, and a few words are in order about these results.  The first thing you’ll notice is that there are a significant number of “failure” and “issue” results.  This is very good news for two reasons.

The first reason it’s good news is that it means enough new test cases were designed for this interop to uncover new problems.  What you don’t see in the matrix is that when testing began, there were even more failures – which means that a lot of the new issues identified during the exercise have already been fixed.

The second reason the “failure” and “issue” results are good news is that they’re outnumbered by the successes.  When you consider that the things tested in Barcelona were all identified as problems at the previous interop, you’ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.

I’d like to call your attention to one more thing.  At the Catalyst North America interop in San Francisco, all the interop participants were onsite, sitting in a room together.

Here in Barcelona, as you can see in the Participant Profile table, about half the participants worked remotely.  What this means in practical terms is that a lot of the components in this interop were accessed over the Internet, in the same configuration you’d use if you deployed them in your business.

I expect that the results table will continue to evolve for a while as additional information from the event is digested and entered into the wiki; I’ll probably post another blog entry with some analysis of the significance of the results after the conference is over and I’ve gotten some sleep.  But my preliminary sense is that this interop continued to demonstrate progress toward an open, deployable, interoperable identity metasystem. Continue reading OSIS User-Centric Identity Interop at Catalyst Europe

That elusive privacy

Craig Burton amused me recently by demonstrating conclusively that my use of a digital birthday for non-disclosure reasons couldn't survive social networking for longer than five digital minutes!  Here's what he says about it in his new wordpress blog (and he's setting up infocard login as we speak)…

Pamela Dingle pointed this post out to me early in Sept. We both decided not to write about it and make fun of Kim and Jackson for violating privacy guidelines so blatantly. But Kim got a good laugh out of my pointing that out so – while late – here it is. Pictures, dates the whole thing. Who cares about privacy anyway eh?

Continue reading That elusive privacy

Long Zheng tweaks Information Card icon

Long Zheng's blog – iStartedSomething.com – is way cool , and though he describes himself as “technophobic”, he has not only understood the meaning of Information Cards – he has applied his obvious talent to tweaking the icon

A while ago, Microsoft began working on an icon to symbolize Information Cards. The download describes, “this icon is intended to provide a common visual cue that Information Cards can be used to provide information to a site or program, similarly to how the RSS icon is used to indicate the availability of syndicated content.”

If you don’t know what InfoCards are, these are basically virtual cards containing identification information such as your name which can be sent and received by websites and web services. On Windows, this is implemented via the CardSpace technology. Other platforms have their own implementation but theoretically Information Cards are universal. If you’re on Vista, type “CardSpace” into your start menu, make an InfoCard for yourself and use it on the demo site here.

I think the idea of an icon is great, especially in comparison to the RSS icon which not only serves as a symbol but also a promotional message to attract people to subscribe to content. On top of just indicating a website is ‘InfoCards compatible’, it also spreads the word about InfoCards. However I wasn’t too keen on the design. The purple was unique, but it wasn’t very bright or vivid either. The roundness of the outside border didn’t match the squareness of the inside cutout. But I did like the “i”, and how it is shaped like a person.

I had a stab at coming up with my own alternative design. Continue reading Long Zheng tweaks Information Card icon

MyOpenID.com supports Information Cards

If you use OpenID, you are propably running software developed by the gang of “Internet ninjas” at JanRain (yes, I've been there, and they actually do all wear black silk kung “foo” robes).  Besides writing software, JanRain runs one of the largest independent OpenID services: MyOpenID.com.  Today Jan Rain's Kevin Fox announced they had reached a major milestone:

The JanRain OpenID team is pleased to announce Information Card support has been added to MyOpenID.com

What is an Information Card?

What can I do with it? With a self-issued Information Card you can sign-in to MyOpenID, as well as sign-up and recover your account, without ever having to enter your password. Anywhere on MyOpenID that you can enter a password will now allow you to use an Information Card instead. With the addition of Information Card support MyOpenID is able to offer another solid option for people wanting to protect their OpenID account from phishing attacks and remember fewer passwords.

We were able to work with Microsoft’s Mike Jones and Kim Cameron who have both been long time proponents of OpenID  + Information Card support.

As noted by Kim Cameron “Cardspace is used at the identity provider to keep credentials from being stolen. So the best aspects of OpenID are retained.” While one of the less desirable aspects (confusing user experience) has been improved for someone using an  Information Card to login to their OpenID provider.

Support for Information Cards has been growing as more software projects implement the technology. It is important to note that this technology is being supported by many other organizations besides Microsoft. Information Card support is available for Windows platforms (Vista / XP) as well as Mac OS X and Linux.

Mike Jones beat me to the punch in heaping well-deserved praise on the Jan Rain group:

The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.

There’s another kind of integration they also did that makes this even more impressive in my mind: connecting their new Information Card support with their existing support for the draft OpenID phishing-resistant authentication specification. This is another significant step in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year. Because of this work, this sequence is now possible:

  1. A person goes to an OpenID relying party and uses an OpenID from MyOpenID.com.
  2. The OpenID relying party requests that MyOpenID.com use a phishing-resistant authentication method to sign the user in.
  3. The person signs into his MyOpenID.com OpenID with an Information Card.
  4. MyOpenID.com informs the relying party that the user utilized a phishing-resistant authentication method.

This means that MyOpenID users will be able to get both the convenience and anti-phishing benefits of Information Cards at OpenID-enabled sites they visit and those sites can have higher confidence that the user is in control of the OpenID used at the site. That’s truly useful identity convergence if you ask me!

Congratulations to all.

Business, Model, Scenario and Technology

Reading more of the discussion about Identity Oracles, I've come to agree with the importance of having separate names for the business model and the underlying technology that would be used to deliver services.  So I buy Dave Kearns's advice

Drop it while you can, Kim. Bob's right on this one. The “Identity Oracle” is a business model, not a technology feature.

Why was I conflating things?

Well, when we were devising the technology for claims transformers, we were specifically trying to enable the scenario of providing answers to questions without releasing the information on which the answers are based (in other words, support derived claims).  We intended the claims transformer to be the technology component that could supply such answers. 

I saw the name “Identity Oracle” as describing the scenario.

Now I see the advantages of having very precise naming for a number of interrelated things.  It can leave us with this taxonomy: 

Reading Dave Kearn's post on how a service like HealthVault might evolve in the direction of an Identity Oracle, I couldn't help wondering about the problems of liability implied by some of these behaviors.

For example, consider a health-related Identity Oracle that could answer the question, “Can Kim take drug X without fear of drug interactions?”.  The resultant “yes” or “no” would be a lot more privacy friendly than releasing all of Kim's drug prescriptions and the medical information necessary to adequately answer the question. 

However, the Identity Oracle presumably assumes more liability by “selling” its “yes” or “no” conclusion than it would by releasing simple facts (assuming the right permissions and use restrictions were in place). 

In other words, success of this model will involve a transfer of liability from the party currently making a decision to the oracle.  This liability has to be factored into the cost structure of the identity oracle business model, and the resultant pricing must make sense to the requesting party.