The Bits Stop Here

One of the drivers for SOA, both commercial and public sector, is to extend and enrich the opportunities to provide services to customers/citizens over the internet.

But the more reliance we place on electronic identity, the more important it seems to be to link this back to some face-to-face identification by a trusted authority. And these processes are getting more tedious. Perhaps rightly so, as identity theft becomes ever easier and more prevalent.

For example, before I could open a savings account for my son recently, I needed a lengthy interview with a bank clerk, who apparently needed to take photocopies of my passport and utility bills. This routine is called 'Know Your Customer'.

[Wikipedia: Know Your Customer]

It's not good enough for the bank clerk merely to see these documents. A paper archive is needed for "compliance" - in other words, providing retrospective evidence that I haven't tricked or bribed the bank clerk to overlook some missing document. Is this because the bank doesn't entirely trust its own employees?

But the bank does trust the paperwork from other organizations with which it has (as far as I know) zero electronic interoperability (the passport authority and the utility companies). That's nice.

Until recently, UK citizens have been able to apply for passports remotely, but the Identity and Passport Service is going to introduce face-to-face interviews. At which I guess we are going to produce copies of bank statements and utility bills.

[BBC News: Interviews for passports 'vital', Robin Wilton: Face-to-face interviews for passport candidates, Tomorrow's Fish-and-Chip Paper: And talking of the Identity and Passport Service ...]

Meanwhile, the utility companies are trying to back out of this role in the network of trust, by producing electronic bills instead of paper ones. These are useless for identification purposes, because they can be too easily forged by amateurs. (Forging old fashioned utility bills does require a tiny amount of expertise.)

So there seem to be some infinite loops in the network of trust, with some pretty obvious vulnerabilities yielding countless opportunities for real crooks.

I was minded of this when I saw the problems faced by Tim Bray getting a new Canadian passport. Spent nine hours waiting in line.

[Tim Bray: Passport Hell, Emerging Chaos: How Long to Be Identified]

Maybe electronic identity (complete with biometrics and RFID) is going to save you a little time for each transaction, but if it takes that long to get/issue the credentials in the first place, then there is some catching up to do.

As it happens, there are some pretty bright people in the IT industry working on exactly this problem, and some pretty neat solutions emerging. But the managers and politicians running the organizations that actually handle identity on a daily basis (leaving sackloads of unshredded personal data on the sidewalk, losing laptops on a regular basis, that kind of thing) don't seem to have a clue about this, don't seem to realise that they are just making things worse.

Like I said, there is some catching up to do. SOA (with Identity 2.0) has the potential to solve a lot of problems, but the first step is for the people who are causing the problems in the first place to acknowledge that they need help.

Otherwise all these cool solutions will just remain interesting talking points for bloggers.

Information Sharing and Joined-Up Services 2

My colleague David Sprott has just posted a critique (Big Brother Database Dinosaur) of the latest UK Government proposals [Note 1] for putting citizen data into a large central database.

As many commentators have pointed out [Note 2], a large central database of this kind would have to be built to extremely high standards of data quality and data protection. Given the recent history of public sector IT, it is hard to be confident that such standards would be achieved or maintained. There is also the question of liability and possible compensation - for example if a citizen suffered financial or other loss as a result of incorrect data.

But in any case, as David points out from an SOA perspective, the proposal is architecturally unsound and technologically obsolescent. Robin Wilton (Sun Microsystems) comes to a similar conclusion from the perspective of federated identity.

Government ministers are busily backtracking on the "Big Brother" elements of the proposal [Note 3], but the policy paper confirms some of the details [Note 4].

David's comments refer mainly to the proposed consolidation of citizen information across various public sector agencies within the UK. But there is another information-sharing problem in the news at present - the fact that the UK criminal records database does not include tens of thousands of crimes committed by UK citizens in other countries. [Note 5]

Part of the difficulty seems to be in verifying the identity of these records. Information sharing requires some level of interoperability, and this includes minimum standards of identification. There are some serious issues here, including semantics, which can never be resolved merely by collecting large amounts of data into one place.

The problem of information sharing within one country is really no different from the problems of information sharing between countries. But at least in the latter case there is nobody saying we can solve all the problems by building a single international database. At least I hope not.

As I said on this blog in 2003 [Note 6], we need to innovate new mechanisms to manage information sharing. This is one of the opportunities and challenges for SOA in delivering joined-up services in a proper manner. Then centralization becomes irrelevant.

Note 1: BBC News January 14th 2007

Note 2: Fish & Chip Papers: Government uber-databases,

Note 3: BBC News January 15th 2007. See also Fish & Chip Papers: Data sharing does not a Big Brother make.

Note 4: Daily Telegraph Microchips for mentally ill planned in shake-up.

Note 5: According to ACPO, some 27,500 case files were left in desk files at the Home Office instead of being properly examined and entered into the criminal records database. [BBC News]

Note 6: See my post from 2003 on Information Sharing and Joined-Up Services.

Technorati Tags: SOA service-oriented

Service-oriented security 3

In a post called Preventing Identity Theft, venture capitalist David Cowan explains (referencing Kerckhoffs' principle via Bruce Schneier) why he regards protecting secrets as a lost cause. Instead of preventing people finding out your social security number, concentrate on preventing people abusing your social security number. Cowan enthuses about one of the companies in this space, in which he has invested.

Kerckhoffs' principle is that security should not depend on secrecy, apart from the key. Social security number is not a key - at least not in the sense understood by cryptographers. Another form of Kerckhoff's principle is Shannon's Maxim: "the enemy knows the system".

Gunnar Peterson uses a chess analogy for service-oriented security. The message is the king, and if you are not using WS-Security (and apparently only 28% of ESBs do) then it's WS-GameOver. This can be seen as another application of Kerckhoffs' principle: you don't make SOA secure by trying to obscure your web services - this just compromises reuse without actually improving security. You protect the payload not the design.

But what exactly is the payload here - the information or the transaction? By Cowan's argument, it may seem a waste of effort to protect the information. But of course if you are a commercial organization (say), you can't just leak people's private data with the excuse that everyone else is doing it so it's not worth protecting. The point is that you must protect the transaction as well, just in case the information is leaking somewhere else in the network.

Cowan thinks it is a good idea to provide a diverse set of security policies and mechanisms to the user. (See also his post on Doomsday Hackers and Evildoing Robots.) This supports my own belief in differentiated security.

Update

Not just commercial organizations leaking private data. See Henry Porter's comments in the Observer (Surveillance is really getting under my skin) about the ease with which the RFID chip on the new UK passport can be cracked, together with the casual unconcern of Governnment officials. FishNChipPapers comments:

"It is naive to believe ... you can build impregnable systems. Instead our government should be focusing on approaches, such as distributed, federated databases, lack of a common identifier to link into those databases etc to mitigate the very real risks."

Meanwhile, in his response to David Cowan, Chris Walsh asks whether the problem (together with the value of Cowan's investment) might be eliminated by legislation, "with a stroke of the pen". But I think Chris has answered this question himself by quoting Gerry Goffin and Carole King in the title of his post - "It's Too Late Baby".

Wikipedia: Differentiated security, Kerckhoffs' principle
Technorati Tags: SOA service-oriented

Handling Uncertainty

Eighth post in seven days. As regular readers will know, I don't always post this often. But I've got lots of material to share after attending the SPARK workshop, which I hope you find useful and/or thought-provoking.

One of the most interesting discussions at the SPARK workshop was about business strategy for SOA, with some great contributions from Steve Davis of Disney Studios. The first insight was on handling uncertainty, using Identity Management as an example.

Handling Uncertainty

Who is going to dominate the identity space? There are several plausible scenarios.

• Credit card companies (Visa)
  
• Government agencies (national ID cards)
  
• Telecoms companies
  
• No single dominant position

So what is the appropriate strategic response to this uncertainty?

1. Do nothing until the situation resolves itself.
2. Pick a winning horse. Maybe try to influence the outcome.
3. Develop a strategy that is independent of the outcome.

SOA provides useful support for the third approach. If identity is a significant source of uncertainty (which it is), then abstract away from any identity-related assumptions. Strip all identity from the applications, and prevent developers creating any local identity processing. Establish a standard set of identity-related services, separate from the basic applications. We may then be able to define two different business cases for building and using these shared services.

1. Tactical efficiency. Economics of scale / scope.
2. Strategic flexibility. Ability to accommodate any of the possible scenarios.
   

Steve argued that four scenarios was a good number - sufficient to provide reasonable variety, while small enough to be meaningful to management.

Technorati Tags: identity SOA service-oriented SPARK SPARK06

Context and Purpose

Adam Shostack's latest post reminds us that It Depends What The Meaning of "Credit Report" Is.

For what purpose were social security numbers originally created - was it er something to do with social security?

Social security numbers have been widely reused and repurposed as general personal identifiers, especially in the context of financial services. So many people are thinking of identity theft as something executed for the purposes of financial fraud.

But someone called Pablo is apparently using Margaret's social security number for an entirely different purpose - to pose as a legal migrant. This interferes (not surprisingly) with Margaret's ability to claim unemployment benefit.

Any piece of data - and especially an identifier - changes its meaning when it is used for a different purpose in a different context. This is of course nothing new - but the opportunities to repurpose data are hugely amplified by the latest service-oriented protocols including XML and web services.

This story should remind us that we need to be purpose-agnostic, not just when we are designing service-oriented data systems, but also when we are thinking of security threats against such systems.

Technorati Tags: identity identity theft reuse SOA service-oriented

Data Ownership and Trust

This month, I've been looking at some complicated questions of data provenance, data protection and copyright, prompted by a tricky but fascinating client problem - how to convert a legacy archive into a network of information services. (Among other things, this involves dividing material according to the ownership of the content.)

So I was particularly interested to see the following three separate items appear in my blogreader today.

Identity Theft and Brand Damage	Silicon.com via Emergent Chaos	A UK charity had its donor list stolen by a hacking gang, which then proceeded to beg funds from the same donors.	this is being described as a security breach
Software as a Service	Cindy Cohn via Tecosystems	"If information about you is stored on your own computer, it's generally not available to others unless they are able to hack your machine or serve legal process on you. In contrast, if information about you is stored on Google's computers, the law generally treats it as Google's, not yours."	this is being described as a privacy issue
Platforms and Stacks	Jon Battelle via Simon Bisson	Alexa (part of Amazon) is exposing its index for commercial reuse, via a series of web services.	this is being described as a ground-breaking innovation

I proceeded to put two and two and two together and make fifteen. What if Charity X had used a Google-like CRM service to maintain its donor list? What if Charity Y had performed some specialized webservice-enabled search on the data, and happened to retrieve a list that was (by a remarkable coincidence) identical to Charity X's donor list? Whose trust is betrayed in this scenario, and by whom?

There are undoubtedly new business risks that emerge whenever we make a significant change in platform. (That's not to say we shouldn't change, merely that we need to do it with our eyes open. As Stephen O'Grady puts it, "the point here is not to be alarmist, but rather to build awareness".) The new technologies of interaction carry the potential of new forms of sociotechnical intimacy, which may take a little getting used to.

Most importantly, sociotechnical shifts like these may cause us to rethink whether we really own the data (or knowledge) we thought we owned. If an email platform can use email content to target advertising, if a communication platform can analyse message traffic to identify friendship clusters, what else is fair game?

Ultimately this comes down to an important strategic choice. Do we want intimate relationships with intelligent service providers, who can interpret (and customize) both content and context to provide deeper service value? Or do we want arms-length relationships with service providers that don't know us from Adam? Where does the platform stop and the true service begin?

Technorati Tags: asymmetry risk security service-oriented SOA trust