My friend Jerry Fishenden, Microsoft’s National Technology Officer in the United Kingdom, had a piece in The Scotsman recently where he lays out, with great clarity, many of the concerns that “keep me up at night”.  I hope this kind of thinking will one day be second nature to policy makers and politicians world wide. 

Barely a day passes it seems without a new headline appearing about how our personal information has been lost from yet another database. Last week, the Information Commissioner, Richard Thomas, revealed that the number of reported data breaches in the UK has soared to 277 since HMRC lost 25 million child benefit records nearly a year ago. “Information can be a toxic liability,” he commented.

Such data losses are bad news on many fronts. Not just for us, when it’s our personal information that is lost or misplaced, but because it also undermines trust in modern technology. Personal information in digital form is the very lifeblood of theinternet age and the relentless rise in data breaches is eroding public trust. Such trust, once lost, is very hard to regain.

Earlier this year, Sir James Crosby conducted an independent review of identity-related issues for Gordon Brown. It included an important underlying point: that it’s our personal data, nobody else’s. Any organisation, private or public sector, needs to remember that. All too often the loss of our personal information is caused not by technical failures, but by lackadaisical processes and people.

These widely-publicised security and data breaches threaten to undermine online services. Any organisations, including governments, which inadequately manage and protect users’ personal information, face considerable risks – among them damage to reputation, penalties and sanctions, lost citizen confidence and needless expense.

Of course, problems with leaks of our personal information from existing public-sector systems are one thing. But significant additional problems could arise if yet more of our personal information is acquired and stored in new central databases. In light of projects such as the proposed identity cards programme, ContactPoint (storing details of all children in the UK), and the Communications Data Bill (storing details of our phone records, e-mails and websites we have visited), some of Richard Thomas’s other comments are particularly prescient: “The more databases set up and the more information exchanged from one place to another, the greater the risk of things going wrong. The more you centralise data collection, the greater the risk of multiple records going missing or wrong decisions about real people being made. The more you lose the trust and confidence of customers and the public, the more your prosperity and standing will suffer. Put simply, holding huge collections of personal data brings significant risks.”

The Information Commissioner’s comments highlight problems that arise when many different pieces of information are brought together. Aggregating our personal information in this way can indeed prove “toxic”, producing the exact opposite consequences of those originally intended. We know, for example, that most intentional breaches and leaks of information from computer systems are actually a result of insider abuse, where some of those looking after these highly sensitive systems are corrupted in order to persuade them to access or even change records. Any plans to build yet more centralised databases will raise profound questions about how information stored in such systems can be appropriately secured.

The Prime Minister acknowledges these problems: “It is important to recognise that we cannot promise that every single item of information will always be safe, because mistakes are made by human beings. Mistakes are made in the transportation, if you like – the communication of information”.

This is an honest recognition of reality. No system can ever be 100 per cent secure. To help minimise risks, the technology industry has suggested adopting proposals such as “data minimisation” – acquiring as little data as required for the task at hand and holding it in systems no longer than absolutely necessary. And it’s essential that only the minimum amount of our personal information needed for the specific purpose at hand is released, and then only to those who really need it.

Unless we want to risk a domino effect that will compromise our personal information in its entirety, it is also critical that it should not be possible automatically to link up everything we do in all aspects of how we use the internet. A single identifying number, for example, that stitches all of our personal information together would have many unintended, deeply negative consequences.

There is much that governments can do to help protect citizens better. This includes adopting effective standards and policies on data governance, reducing the risk to users’ privacy that comes with unneeded and long-term storage of personal information, and taking appropriate action when breaches do occur. Comprehensive data breach notification legislation is another important step that can help keep citizens informed of serious risks to their online identity and personal information, as well as helping rebuild trust and confidence in online services.

Our politicians are often caught between a rock and a very hard place in these challenging times. But the stream of data breaches and the scope of recent proposals to capture and hold even more of our personal information does suggest that we are failing to ensure an adequate dialogue between policymakers and technologists in the formulation of UK public policy.

This is a major problem that we can, and must, fix. We cannot let our personal information in digital form, as the essential lifeblood of the internet age, be allowed to drain away under this withering onslaught of damaging data breaches. It is time for a rethink, and to take advantage of the best lessons that the technology industry has learned over the past 30 or so years. It is, after all, our data, nobody else’s.

My identity has already been stolen through the very mechanisms Jerry describes.  I would find this even more depressing if I didn’t see more and more IT architects understanding the identity domino problem - and how it could affect their own systems. 

It’s our job as architects to do everything we can so the next generation of information systems are as safe from insider attacks as we can make them.  On the one hand this means protecting the organizations we work for from unnecessary liability;  on the other, it means protecting the privacy of our customers and employees, and the overall identity fabric of society.

In particular, we need to insist on:

• scrupulously partitioning personally identifying information from operational and profile data;
• eliminating ”rainy day” collection of information - the need for data must always be justifiable;
• preventing personally identifying information from being stored on multiple systems;
• use of encryption;
• minimal disclosure of identity intormation within a “need-to-know” paradigm.

I particularly emphasize partitioning PII from operational data since most of a typical company’s operational systema - and employees - need no access to PII.  Those who do need such access rarely need to know anything beyond a name.  Those who do need greater access to detailed information rarely need access to information about large numbers of people except in anonymized form.

I would love someone to send me a use case that calls for anyone to have access - at the same time - to the personally identifying information about thousands of individuals  (much less millions, as was the case for some of the incidents Jerry describes).  This kind of wholesale access was clearly afforded the person who stole my identity.  I still don’t understand why. 

 From the Economist:

Internet users in Britain are more likely to fall victim to identity theft than their peers elsewhere in Europe and North America. In a recent survey of 6,000 online shoppers in six countries by PayPal and Ipsos Research, 14% of respondents in Britain said that they have had their identities stolen online, compared with only 3% in Germany. More than half of respondents said that they used personal dates and names as passwords, making it relatively easy for scammers to gain access to accounts. The French are particularly cavalier, with two-thirds using easily guessed passwords and over 80% divulging personal data, such as birthdays, on social-networking sites.

Of course, my identity was stolen (and apparently sold) NOT because of inadequate password hygiene, but just because I was dealing with Countrywide - a company whose computer systems were sufficiently misdesigned to be vulnerable to a large-scale insider attack.  So there are a lot of things to fix before we get to a world of trustworthy computing.

[This is the third installment of a presentation I gave to Microsoft developers at the Professional Developers Conference (PDC 2008) in Los Angeles. It starts here.]

Microsoft also operates one of the largest Claims Providers in the world - our cloud identity provider service, Windows Live ID.

It plays host to more than four hundred million consumer identities.

In the Geneva wave, Live ID will add “managed domain” services for sites and customers wanting to outsource their identity management.  With this option, Live would take care of identity operations but the sign in/sign up UX can be customized to fit the look of your site.

But in what I think is an especially exciting evolution, Live IDs also get access to our cloud applications and developer services via the gateway, and are now part of the same open, standards-based architecture that underlies the rest of the Geneva Wave.

Microsoft Services Connector

Some customers may want to take advantage of Microsoft’s cloud applications, hosting, and developer services - and have Active Directory - but not be ready to start federating with others.

We want to make it very easy for people to use our cloud applications and developer services without having to make any architectural decisions.  So for that audience, we have built a fixed function server to federate Active Directory directly to the Microsoft Federation Gateway.

This server is called the Microsoft Services Connector (MSC).   It was built on Project Geneva technology.

Since it’s optimized for accessing Microsoft cloud applications it manages a single trust relationship with the Federation Gateway.  Thus most of the configuration is fully automated.  We think the Microsoft Services Connector will allow many enterprises to start working with federation in order to get access to our cloud, and that once they see the benefits, they’ll want to upgrade their functionality to embrace full federation through Geneva Server and multilateral federation.

Through the combination of Geneva Framework and Server, Microsoft Services Connector, Live ID, the Microsoft Federation Gateway - and the ability to use CardSpace to protect credentials on the Internet -millions of Live and AD users will have easy, secure, SSO access to our cloud applications and developer services.

But what about YOUR applications?

OK.  This is all very nice for Microsoft’s apps, but how do other application developers benefit?

Well, since the Federation Gateway uses standard protocols and follows the claims-based model, if you write your application using a framework like “Geneva”, you can just plug it into the architecture and benefit from secure, SSO access by vast numbers of users - ALL the same users we do.  The options open to us are open to you.

This underlines my conviction that Microsoft has really stepped up to the plate in terms of federation.  We haven’t simply made it easier for you to federate with US in order to consume OUR services.  We are trying to make you as successful as we can in this amazing new era of identity.  The walled garden is down.  We want to move forward with developers in a world not constrained by zero sum thinking.

Configure your application to accept claims from the Microsoft Federation Gateway and you can receive claims from Live ID and any of the enterprise and government Federation Gateway partners who want to subscribe to your service.  Or ignore the MFG and connect directly to other enterprises and other gateways that might emerge.  Or connect to all of us.

Crossing organizational boundaries

If this approach sounds too good to be true, some of you may wonder whether, to benefit from Microsoft’s identity infrastructure, you need to jump onto our cloud and be trapped there even if you don’t like it!

But the claims-based model moves completely beyond any kind of identity lock-in.  You can run your application whereever you want - on your customer’s premise, in some other hosting environment, even in your garage.  You just configure it to point to the Microsoft Federation Gateway - or any other STS - as a source of claims.

These benefits are a great demonstration of how well the claims model spans organizational boundaries.  We really do move into a “write once and run anywhere” paradigm. 

Do you want choice or more choice?

For even more flexibility, you can use an enterprise-installed “Geneva” server as your application’s claim source, and configure that server to accept claims from a number of gateways and direct partners.

In the configuration shown here, the Geneva server can accept claims both hundreds of millions of Live ID users and from a partner who federates directly.

Claims-based access really does mean applications are written once, hosted anywhere.  Identity source is a choice, not a limitation.

You get the ability to move in and out of the cloud at any time and for any reason.

Even more combinations are possible and are just a function of application configuration. It’s a case of “Where do you want to get claims today?”.   And the answer is that you are in control.

In the next installment of this presentation I’ll tell you about another service we are announcing - again a claims-based service but this time focussing on authorization.  I’ll also link to the demo, by Vittorio Bertocci, of how all these things fit together.

[This is the second installment of a presentation I gave to Microsoft developers at the Professional Developers Conference (PDC 2008) in Los Angeles. It starts here.]

I don’t want to overwhelm you with a shopping list of all the scenarios in which the Claims-based architecture solves problems that used to be insurmountable.

But I’ll start from the enterprise point of view, and look at how this system helps with the big new trend of federation between partners. Then we’ll look at cloud computing, and see that the same architecture dramatically simplifies developing applications that can take advantage of it.  Finally, we’ll see how the approach applies to consumer-oriented web applications.  

Enterprise Federation

The rigid Enterprise perimeter is dissolving as a result of the need for digital relationships between an enterprise and its suppliers and customers, as well as the outsourcing of functions and services, the use of temporary workers, and having employees who sometimes work from home.  The firewall is still a useful element in a concentric set of defences, but must at the same time now be permeable. 

Most of us are even learning to collaborate on a per-project basis with partners who in other contexts might be our competitors.  So the relationships between business entities must be defined with more and more granularity.

In looking at this, I’m going to start with a very simple scenario - a story of two companies, where one has built an app in-house or has installed an ISV app for their own employees, and now wants to extend access to employees from a partner.

In the past, even this simple requirement has been really hard and expensive to fulfill. How can Microsoft help you solve this problem using the claims model?

Code name Geneva

Well, I’m happy to announce today, the first beta of “Geneva” software for building the claims-aware applications I’ve been talking about. It has three parts:

1. The “Geneva” Framework: A framework you use in your .Net application for handling claims. This was formerly called “Zermatt”.
2. “Geneva” Server: A claims provider and transformer (STS) integrated with Active Directory.  It comes with Windows, and makes managing trusts and policies easy.  Importantly, it supports Information Cards, making it easier for people to understand what identities they are using where, and to avoid phishing of their enterprise credentials. You may in the past heard this server being referred to as AD FS “2”.
3. Windows CardSpace “Geneva”:  The second generation Information Card client for federation that is dramatically faster and smaller than the first version of CardSpace, and incorporates the feedback and ideas that have emerged from our customers and collaborators.

In the use case we’ve been considering, our solution works this way:  each enterprise puts up a single Geneva Server – leveraging the power of their Active Directory.

Then the administrators of the application alter the .NET configuration to point to their enterprise’s Geneva server (with the config change I demonstrated here ). At this point, your customer’s application has become part of what we call an Enterprise identity backbone, and can accept claims.

So the software framework and components provide a single identity model that users configure in any way they want.  If you have written to this model, your app now works for both “employees” and “partner users” without a code change. All that is required is to set up the Geneve STS’s .

The fatal flaw

Anyone who has been around the block a few times knows there is one fatal flaw in the solution I’ve just described.

Your customer may have partners who don’t use Active Directory or don’t use Geneva or have settled on a non-Microsoft product.

No problem.  All aspects of Project Geneva are based on standards accepted across the industry – WS-Trust and WS-Federation.

I’m also very happy to announce that Geneva supports the SAML 2.0 protocol. Basically, no system that supports federation should be out of reach.

All this means your partners aren’t forced to use “Geneva” if they want to get access to your applications. They can use any third party STS, and that is part of the great power of the solution.

Does Microsoft practice what it preaches?

Microsoft is an enterprise too.  So if this architecture is supposed to be good for our enterprise customers, what about for Microsoft itself?  Are we following our own advice?

I’m here today to tell you Microsoft has fully stepped up to the plate around federation. And it is already providing a lot of benefits and solving problems.

You’ve heard a lot at the PDC about Azure. Microsoft offers cloud applications like hosted SharePoint and Exchange, and cloud developer services like the .Net Services and SQL Data Services, as well as a whole range of applications.  We want other enterprises to be able to access these services and sites, much like other enterprises want their own customers and partners to access the systems pertaining to their businesses.

So we make our offerings available to customers via the Microsoft Federation Gateway (MFG), which anchors our “services identity backbone”, and is based on the same industry standards and architecture delievered through the Geneva Project’s server. It is all part of one wave, the Geneva wave of Identity Software + Services.

The result is pretty stunning, in terms of simplifying our own lives and allowing us to move forward very quickly - as it will be for enterprises that follow the same route. Through a single trust relationship to our gateway, our customers can get access to our full range of services.

Again, we’re not telling our customers what federation software to use. They can federate with the MFG using “Geneva” or other third party servers that support standard protocols.  And they can use the same protocols to federate with other gateways run by other organizations.

What about Live ID?

It is important to understand that the Microsoft Federation Gateway is different from Windows Live ID.  Yet Live ID feeds into the Gateway just as all our partners do.  I’ll describe this, and the cool implications for application develoeprs of this approach, in the next installment.

I always want my blog to be about ideas, not the specific products I work on. 

But I thought it might be useful to make a bit of an exception in terms of sharing the announcements I made this week at the Microsoft Professional Developers Conference in Los Angeles.  I’m hoping this might help others in the industry understand exactly what we at Microsoft been able to accomplish around identity, what’s left to do, and where we think we’re going.

A number of people have told me that one of the conclusions they drew from the presentation is that when it comes to identity,  big, synergistic, cross-industry things are happening.   I liked that.

Not random things, not proprietary things, not divisive things.  But initiatives that further our collaboration, open standards, user choice and control and the “identity metasystem” many of us believe in so strongly, even if we call it by different names. 

I thought it might help, in particular, to share the conversation we are having with our developers.  This set of posts is intended as a bit of a look behind the curtain - or rather, as pulling back the curtain to show there is no curtain, if you will.  My presentation, which is on video here, went like this…

The first lines of every application

Whether you are creating serious Internet banking systems, hip new social applications, multi-party games or business applications for enterprise and government, you need to know something about the person using your application. We call this identity.

There is no other way to shape your app to the needs of your users, or to know how to hook people up to the resources they own or can share.

I want to be clear. Knowing “something” doesn’t mean knowing “everything”.  We want to keep from spewing personal information all over the Internet.  It means knowing what’s needed to provide the experience you are trying to create.

This might sometimes include someone’s name. Or knowing they are really the person with a certain bank account.

Or it might just involve knowing that someone is in a certain role. Or in a certain age bracket.

It also might simply be a question of remembering that some user prefers Britney Spears to New Kids on the Block or Eminem.

Identity Turbulence

But getting identity information is one of the messiest aspects of application development. People are up to their necks in passwords. They use many different mechanisms to establish identity, and its getting worse.

One of my good friends at Microsoft is in charge of the identity aspects of one of our flagship apps. Let’s call him Joe .

He started years ago by building in support for usernames and passwords.  He was supposed to finish up within a few weeks, but soon found he needed a second project to build in better password reset and account management.

This soon worked pretty well, but when presented to customers, no one would deploy in large numbers unless he added a help desk component - so he did.

Then as Active Directory started gaining critical mass, he needed to set up a project to integrate with Active Directory.  When that was finished, the large sites wanted to use AD with multiple forests, and that involved a complete rewrite…

Next, people wanted to use the app outside the firewall, so he needed to add One Time Password (OTP) support. Supporters of Smart Cards were adamant that if OTP was supported, smartcards should work too.

Joe was just pretty much ready to return to his “core work” when he was asked to support SAML. He hadn’t even finished his initial investigation of this when people started asking for OpenID support too.  Plus he needed to integrate with another software product by a different vendor  - who used a completely different and proprietary approach to identity.

As he was looking at all this he was hit by phishing attacks. That brought about a whole new round of security reviews - one for every one of the projects just discussed.

Now Joe has realized that his application has to be easily hostable in the cloud as well as work on-premise. And it needs to support delegation so it can access other services on behalf of his users…

So you’ll understand that he really wants and needs a better way. He wants to focus on the core values of his app, not the changing trends in identity.

Claims-based Access

 As we understood more about these problems, and the hardships they were causing developers, we started work on a way to insulate the application from all these issues.

Our goal? You - the developer - would write the application once and be done, yet it would support all the identity requirements customers have as they host it in different environments.

This was the same kind of problem we had in spades in the early days of computing. Back then, you needed to write separate code for each type of disk drive you wanted to support. There was no end to it. If you didn’t support the new drives you’d lose part of your market. So we needed the idea of a logical disk that was always the same.

We can now do the same thing around identity. We use what we call the Claims Based model.

A claim is a statement by one subject about another subject. Examples: someone’s email address, age, employer, roles, custumer number, permission to access something.  There are no constraints on the semantics of a claim.

The model starts from the needs of the application:  you write your application on the assumption you can get whatever claims you need.

Then there is a standards-based architecture for getting you those claims. We call it the Identity Metasystem – meaning a system of identity systems. 

Here’s how the architecture works. As I said, the application is in control. It specifies the kinds of claims it requires. The claims providers support protocols for issuing claims. You can also pop in claims providers that translate from one claim to another – we call this claims transformers. That makes the system very flexible and open.

The technical name for a claims provider is a “Security Token Service”. You’ll see the abbreviation STS on upcoming slides.

The important thing here is that all existing identity mechanisms can be represented through claims and participate in the metasystem. As an app developer, you just deal with claims. But you get support for all permutations and combinations without getting your hands dirty or even thinking about it.

I say “all” to emphasize something – the open nature of this system. It accepts and produces identities from and for every type of platform and technology – no walled gardens.

You can choose to get your identity from anywhere you wish.  You can choose any framework to build your app.  You can choose to use any client or browser.

What’s involved for the developer?

Let me give you an example.  I’ll peek ahead and show you how the claims-based model is used in the Geneva Framework - new capabilities within .NET.  Other frameworks would have similar capabilities, though we think our approach is especially programmer-friendly. 

Basically, to answer the “Who are you?” question, you write your app as per normal, and simply add this extra configuration to you app.config file: 

(There are a couple of more cut-and-paste lines needed, to make sure some modules are included, but otherwise that’s it.)

Now, when a user hits your app, if they haven’t been authenticated yet, they will get automatically redirected to the claims provider at https://sts1.contoso.com/FederationPassive to pick up their claims.  The claims provider will get your user to authenticate, and if all goes well, will redirect her back to your application with her identity set, and any necessary claims available to your program.  In other words, with zero effort on your part, no unauthenticated user will ever hit your app.  Yet you are completely free to point your app at any claims provider on any platform made by any vendor and located anywhere on the Internet.

To drill into the actual claim values, you use a technique like this:

You’ll see the Thread has a Current Principal, and the Principal has an Identity, so you get a Claims Identity interface as shown, then cycle through the claims or pull out the one you need.  In this case, it is the claim with the type of “role” - in the the enum MyClaimTypes.Role…

If you are an application developer, we’ve already come to the big takeaway of this presentation.  You can get up and go home now.  Everything else I’m going to show you is just to give you a deeper understanding of all the many use cases and scenarios that can be supported through these mechanisms.

Again, the claims shown in this example are implemented through well accepted industry standards. The same code works with claims that come from anywhere, any platform, any vendor, any operating system, any cloud provider.

Solving problems with claims

{In the next segment, I’ll share the ideas I presented to my developer audience about how they could use claims to solve concrete problems.}

I need to correct a few of the factual errors in recent posts by James Governor and Jon Udell.  James begins by describing our recent get-together:

We talked about Project Geneva, a new claims based access platform which supersedes Active Directory Federation Services, adding support for SAML 2.0 and even the open source web authentication protocol OpenID.

Geneva is big news for OpenID. As David Recordon, one of the prime movers behind the standard said on Twitter yesterday:

Microsoft’s Live ID is adding support for OpenID. Goodbye proprietary identity technologies for the web! Good work MSFT

TechCrunch took the story forward, calling out de facto standardization:

Login standard OpenID has gotten a huge boost today from Microsoft, as the company has announced that users will soon be able to login to any OpenID site using their Windows Live IDs. With over 400 million Windows Live accounts (many of which see frequent use on the Live’s Mail and Messenger services), the announcement is a massive win for OpenID. And Microsoft isn’t just supporting OpenID - the announcement goes as far as to call it the de facto login standard [the announcement actually calls it "an emerging, de facto standard" - Kim] 

But that’s not what this post is supposed to be about. No I am talking about the fact [that] later yesterday evening Kim hacked his way into a party at the standard using someone else’s token!  [Now this is where I think some "small tweaks" start to be called for... - Kim]

It happened like this. I was talking to Mary Branscombe, Simon Bisson and John Udell when suddenly Mary jumped up with a big smile on her face. Kim, who has a kind of friendly bear look about him, had arrived. She ran over and then I noticed that a bouncer had his arm across Kim’s chest (”if your name’s not down you’re not coming in”). Kim had apparently wandered upstairs without getting his wristband first. Kim disappeared off downstairs, and I figured he might not even come back. A few minutes later though and there he was. I assumed he had found an organizer downstairs to give him a wristband… When he said that he actually had taken the wristband from someone leaving the party, and hooked it onto his wrist me and John practically pissed our pants laughing. As Jon explains (in Kim Cameron’s Excellent Adventure):

If you don’t know who Kim is, what’s cosmically funny here is that he’s the architect for Microsoft’s identity system and one of the planet’s leading authorities on identity tokens and access control.

We stood around for a while, laughing and wondering if Kim would reappear or just call it a night. Then he emerged from the elevator, wearing a wristband which — wait for it — belonged to John Fontana.  Kim hacked his way into the party with a forged credential! You can’t make this stuff up!

While there is certainly some cosmic truth to this description, and while I did in fact back away slightly from the raucus party at the precise moment James says he and Jon “pissed their pants”, John Fontana did NOT actually give me his wristband.  You see, he didn’t have a wristband either. 

So let’s go through this step by step.  It all began with the invite that brought me to the party in the first place:

As a spokesperson for PDC2008, we’re looking forward to having you join us at the Rooftop Bar of the Standard Hotel for the Media/Analyst party on October 27th at 7:00pm

This invite came directly from the corporate Department of Parties.

I point this out just to ward off any unfair accusations that I just wanted to raid the party’s immense Martini bar. Those who know me also know nothing could be further from the truth. You have to force a Martini into my hands.  My attendance represented nothing but Duty.  But I digress.

Protocol Violation

The truth of the matter is that I ran into John Fontana in the cafe of the Standard and we arrived at the party together.  He had been invited because this was, ummm, a Press party and he was, ummm, Press. 

However, it didn’t take more than a few seconds for us to see that the protocol for party access control had not been implemented correctly.   We just assumed this was a bug due to the fact that the party was celebrating a Beta, and that we would have to work our way past it as all beta participants do. 

Let’s just say the token-issuing part of the party infrastructure had crashed, whereas the access control point was operating in an out-of-control fashion.

Looking at it from an architectural point of view, the admission system was based on what is technically called “bearer” tokens (wristbands). Such tokens are NOT actually personalized in any way, or tied to the identity of the person they are given to through some kind of proof. If you “have” the token, you ARE the bearer of the token.

So one of those big ideas slowly began to take root in our minds.  Why not become bearers of the requisite tokens, thereby compensating for the inoperative token-issuing system?

Well, at that point, since not a few of the people leaving the party knew us,  John and I explained our “aha”, and pointed out the moribund token-issuing component.  As is typical of people seeing those in need of help, we were showered with offers of assistance.

I happened to be rescued by an unknown bystander with incredibly nimble and strong fingers and deep expertise with wristband technology.  She was able to easily dislodge her wristband and put it on me in such a way that it’s integrity was totally intact. 

There was no forged token.  There was no stolen token.  It was a real token.  I just became the bearer.

When we got back upstairs, the access control point evaluated my token – and presto – let me in to join a certain set of regaling hedonists basking in the moonlight.  

But sadly - and unfairly -  John’s token was rejected since its donor, lacking the great skill of mine, had damaged it during the token transplant.

Despite the Martini now in my hand, I was overcome by that special sadness you feel when escaping ill fate wrongly allotted to one more deserving of good fortune than you.  John slipped silently out of the queue and slinked off to a completely different party.

So that’s it, folks.  Yet the next morning, I had to wake up, and confont again my humdrum life.  But I do so inspired by the kindness of both strangers and friends (have I gone too far?)

The UK’s Register has been running a a series of articles by John Leyden  (here, here and here) about Verified By Visa. (VByV)  Verified By Visa uses the same kind of “site redirection” I’ve written about many times with respect to OpenID and other password-based federation technologies - but in this case it is a banking password that can be stolen.

The phishing scenario is simple enough.  If you happen onto an “evil” site and are tricked into purchasing something, it can “misdirect” your browser to a counterfeit VByV signon page.  As John explains, you have little chance, as a user, of knowing you are being duped, but once you enter your password it is available to the evil site for both instant use an future reuse.  Those familiar with this site will understand that this is yet another example of an attack that cannot be made against Information Card users.

Beyond focussing attention on the phishing problems inherent in “site redirection” approaches, John argues that the system - though claiming to be more secure - is actually just as vulnerable as non-VByV mechanisms.  He then argues - and I have know knowledge as to whether this is the case - that the false claims about increased security are being used to reject complaints by end-users about irregularities and fraudulent purchases made in their name.  If that were true, it would be scandalous.

Friends, this is a case of “The Writing on the Wall”.  I think people in the industry should see John’s work as a sign of what’s to come.   He is the guy in the fable who is shouting out that ”the Emperor has no clothes!”  And he’s doing it cogently to the wide readership of the Register.

If I were an advisor to the emperor at this point I would insist on two things: 

1. admit the vulnerability of all systems based on “site redirection”; and
2. start getting into phishing-resistant technologies like Information Cards while one’s modesty can still be protected.

John makes his points without the stench of jargon.  In spite of this, North American readers will require a dictionary to follow what he’s saying (I did).  I’m talking here about a dictionary of British idioms (thanks to my friend Richard Turner for boosting my vocabulary on this one) :

punter n guy. A punter is usually a customer of some sort (the word originally meant someone who was placing bets at a racecourse)…

To see a bit of what mainstream press worldwide will be writing about as the paucity of redirection technology for long-tail scenarios is concerned, I do suggest looking first hand at these articles.  One small taste:

Both Verified by Visa (VbyV) and MasterCard’s equivalent SecureCode service are marketed as offering extra security checks to online purchases. Importantly, the schemes also transfer liability for bogus transactions away from merchants who use the system back towards banks (and perhaps ordinary e-commerce punters).

Online shoppers who buy goods and service with participating retailers are asked to submit a VbyV or SecureCode password to authorise transactions. These additional checks are typically submitted via a website affiliated to a card-issuing bank but with no obvious connection to a user’s bank.

Punters aren’t informed up front that a merchant has signed up to Verified by Visa. Sites used to authenticate a VbyV or SecureCode password routinely deliver a dialogue box using a pop-up window or inline frame, making it difficult to detect whether or not a site is genuine.

The appearance of phishing attacks hunting for Verified by Visa passwords are among the reasons some punters are wary of the technology.

Once obtained by fraudsters, either by direct phishing attack or through other more subtle forms of social engineering trickery, VbyV login credentials make it easier for crooks to make purchases online while simultaneously making it harder for consumers to deny responsibility for a fraudulent transaction…

The little-publicised mandatory use of the technology by some banks means that those with reservations have an uphill struggle to opt out of the scheme…

Verified by Visa and Mastercard SecureCode are there purely to protect the banks, not the card holder. They offer zero additional protection to the consumer, but allow the bank to claim that transactions using purloined credit card credentials were really made by the card holder. It is as simple as that.

[More here}.

The next Internet Identity Workshop (IIW) is coming up in November.  Identity Woman Kaliya and Phil Windley do a great job running this, and I did a double take reading Kaliya’s list of what was accomplished there.  It really happened.

If you attend, you’ll meet people thinking deeply about identity from a hundred points of view - and doing great software.   Here’s Kaliya’s description:

The community that comes together at the workshop is really amazing.  It is a working meeting for a range of groups focused on the technical, social and legal issues arising with the emergence identity, relationship and social layer of the web. The key thought leaders in the area are all there in a highly interactive environment.

We have been focused on “user-centric identity” - considering how end-users, regular people, can manage their own identity across the range of websites, services, companies and organizations that they belong to, purchase from and participate with.

A lot has happened since we first met in the fall of 2005 in Berkeley:

• We have several foundations that have formed around key technologies - OpenID and Information Cards.
• LIberty Alliance continues to be actively involved in the community
• OASIS TC’s have started actively participating.  
• The Vendor Relationship Management project has sprung up out of the community continues to evolve. 
• OSIS - (Open Source Identity Systems) was founded at IIW and is working on its 4th major interop event happening at DIDW next week (#3 was at RSA in the spring).

 As a community we have been exploring these kinds of questions:

• How are social networking sites and social media tools applying user-centric identity?
• What are the open standards to make it work? (identity and semantic)
• What are technical implementations of those standards?
• How do different standards and technical implementations interoperate?
• What are the new social norms and legal constructs needed to make it work?
• What tools are needed to make it usably secure for end-users?
• What are the businesses cases / models that drive all this?

 You can check out our community aggregate blog http://www.planetidentity.org

Here is my blog on the conference http://www.identitywoman.net/?p=784

 Who comes to  IIW?:

• Anyone interested in identity (user profiles, social linking, user history & metadata etc) on the web and in digital systems. 
• Entrepreneurs  who are working companies about people and their identities online - profiles, social linking, group formation. Basically those doing ANYTHING with the word SOCAIL in it.
• Product Managers who are trying to figure what to do now and plan for interms of user-identity and information sharing in your product. 
• Engineers/Programmers who have to implement the emerging standards that are covered at IIW.
• Researchers/Academics studying identity online. 
• Lawyers who are interested in end-user agreements and how new technologies change/improve how people interact with companies.
• Sociologists, Anthropologists who are considering online life and the implications of identity online.

This is a conference where you get out of it what you want.  If you have something to present you are most welcome to. If you have questions you need answers to you can find them.

You can read what community members have said about the quality of the event.

Cost:

The event is VERY affordable for a 2.5 day high quality conference with the leading professionals in the industry.

• Students - $50
• Independents (small startups, nonprofits)- $200
• Corporate - $350

Paul Madsen at ConnectID makes a good point in his “Could someone hand me that hammer please?”

I have a dead horse here that needs some beating.

Does  ‘identity metasystem’ not imply “a pluralism of operators and technologies”? Isn’t this even almost a law?

If so, should a TC focused on a single (albeit important) identity technology claim within its name the ‘meta’ scope?

The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards

The IMI TC’s mandate respects the ‘pluralism of operators’ required by the metasystem definition, but not the other piece.

NB: Any comment that includes any combination of  ‘forgot SAML token’ will be summarily rejected.

Metasystem and Identity Selector

Paul is completely right that the Identity Metasystem is a unifying model intended to bring together many contributing technologies - including Kerberos, PKI, browser-only federation protocols like SAML, WS-Security, WS-Trust and lightweight protocols like OpenID.  And in fact, reaching across this diversity is the most important thing about it.  Breadth is what allows us, as an industry, to create “one identity model” in terms of application development, deployment and most important, user experience.

To make this vision a reality, we need a component of the metasystem that has been missing: a common ”Identity Selector”  (early examples being CardSpace and DigitalMe). 

Clearly such an important component needs to evolve in the context of an international standards body, so the announcement of the new OASIS Technical Committee dedicated to Information Cards and their interoperability is an important milestone:

Boston, MA, USA; 23 September 2008 — OASIS, the international open standards consortium, has formed a new group to enable the use of Information Cards to universally manage personal digital identities. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards. A rapidly-developing, Web 2.0-friendly method for shared light authentication, Information Cards let people authenticate themselves on multiple web sites without maintaining passwords for each site.

But back to the name 

While I think Information Cards are beneficial to the whole metasystem, they are not themselves the metasytem, and don’t encompass all aspects of its interoperability. 

For this reason, I don’t personally think the OASIS committee’s name is currently quite right.

I’ve never personally participated in OASIS or any other standards body (I have great respect for those who do.)  So I have no idea whether it is possible to tweak a name once a committee is formed.  If it didn’t turn into a major time-waster, I think doing so would show everyone’s respect for all the other contributions being made to the metasystem.  I would prefer a name that is more technically specific, like the OASIS Identity Selector Interoperability Technical Committee (ISI).

The people who put in the effort to set up the committee and come up with a name will rightly say, “I wish you had given us that feedback earlier” - and I accept that criticism.  Maybe I have missed my opportunity to provide feedback.  Basically, I was sufficiently excited about the emergence of the committee, and convinced that the Identity Selector did contribute to Metasystem Interoperability, that the potential issues with the name didn’t jump out at me. 

And now to Occam

And now for something completely different.  In a recent post Paul also reveals the origins of the third law of identity, and makes a great connection:

It was inevitable, given how sloppy many companies are when handling the identity of their customers, that someone would eventually steal all my personal information.  But no matter how much science you have in your back pocket, it hurts when you get slapped in the face.

The theory is clear:  systems must be built to withstand being breached.  But they often aren’t.

One thing for sure: the system used at Countrywide Mortgage was so leaky that when I phoned my bank to ask how I should handle the theft, my advisor said, “I don’t know.  I’m trying to figure that out, since my information was stolen too.”  We commiserated.  It’s not a good feeling.

And then we talked about the letter.

What a letter.  It is actually demented.  It’s as though Countrywide’s information systems didn’t exist, and weren’t a factor in any insider misbehavior. 

I agree there was a bad employee.  But is he the only guilty party?  Was the system set up so employees could only get at my personal information when there was a need to know? 

Was the need to know documented?  Was there a separation of duties?  Was there minimization of data?  Can I see the audit trails?  What was going on here?  I want to know.

My checks rolled in to Countrywide with scientific precision.  No one needed to contact me through emergency channels.  Why would anyone get access to my personal information?  Just on a whim?  

How many of us were affected?  We haven’t been told.  I want to know.  Iit bears on need to know and storage technologies.

But I’m ahead of myself.  I’ll share the letter, sent by Sheila Zuckerman on behalf of “the President” (”President” who??).

We are writing to inform you that we recently became aware-that a Countrywide employee (now former) may have sold unauthorized personal information about you to a third party. Based on a joint investigation conducted by Countrywide and law enforcement authorities, it was determined that the customer information involved in this incident included your name, address, Social Security number, mortgage loan number, and various other loan and application information.

We deeply regret this incident and apologize for any inconvenience or concern it may cause you. We take our responsibility to safeguard your information very seriously and will not tolerate any actions that compromise the privacy or security of our customers’ information. We have terminated the individual’s access to customer information and he is no longer employed by Countrywide. Countrywide will continue to work with law enforcement authorities to pursue further actions as appropriate.

I don’t want to hear this kind of pap.  I want an audit of your systems and how they protected or did not protect me from insider attack.

If you are a current Countrywide mortgage holder, we will take necessary precautions to monitor your mortgage account and will notify you if we detect any suspicious or unauthorized activity related to this incident. We will also work with you to resolve unauthorized transactions on your Countrywide mortgage account related to this incident if reported to us in a timely manner.

I find this paragraph especially arrogant.  I’m the one who needs to do things in a timely manner although they didn’t take the precautions necessary to protect me. 

As an additional measure of protection, Countrywide has arranged for complimentary credit monitoring services provided by a Countrywide vendor at no cost to you over the next two years. We have engaged ConsumerInfo.com, Inc., an Experian® Company, to provide to you at your option, a two-year membership in Triple Advantage Credit Monitoring.  You will not be billed for this service. Triple Advantage includes daily monitoring of your credit reports from the three national credit reporting companies (Experian, Equifax and TransUnion®) and email monitoring alerts of key changes to your credit reports.

Why are they doing this?  Out of the goodness of their hearts?  Or because they’ve allowed my information to be spewed all over the world through incompetent systems?

To learn more about and enroll in Triple Advantage, log on to www.consumerinfo.com/countrywide and complete the secure online form. You will need to enter the activation code provided below on page two of the online form to complete enrollment. If you do not have Internet access, please, call the number below for assistance with enrollment.   You will have-90 days from the-date of-this letter-to-use the code to activate the credit monitoring product.

Borrower Activation Code: XXXXXXXXX

And now the best part.  I’m going to need to hire a personal assistant to do everything required by Countrywide and still remain employed:

In light of the sensitive nature of the information, we urge you to read the enclosed brochure outlining precautionary measures you may want to take. The brochure will guide you through steps to:

• Contact the major credit bureaus and place a fraud alert on your credit reports;
• Review your recent account activity for unauthorized charges or accounts;
• Be vigilant and carefully review your monthly credit card and other account statements over the next twelve to twenty-four months for any unauthorized charges; anTake action should any unauthorized activity appear on your credit report.

I need more information on why I only need to be vigilant for twelve to twenty-four months, when, thanks to Countrywide, my personal information has spilled out and I have no way to get it back!

We apologize again that this incident has occurred and for any inconvenience or worry it may have caused.  If you have questions, please call our special services hotline at 1-866-451-5895, and a specially trained representative will be ready to assist you.

Sincerely,

Sheila Zuckerman
Countrywide Office of the President
Enclosure

O.K.  This is going to be a long process.  It drives home the need for data minimization.  It underlines the need for stronger authentication.  But EVERY case like this should make us deeply question the way our systems are structured, and ask why there are no professional standards that must be met in protecting private information.

When a bridge collapses, people look into the why of it all.

We need to do that with these identity breaches too.   As far as I’m concerned, Countrywide has a lot of explaining to do.  And as a profession we need clear engineering standards and ways of documenting how our systems are protected through “need to know” and the other relevant technologies.

Finally, we all need to start making insider attacks a top priority, since all research points to insiders and our number one threat.