Before we start, we need to remind ourselves that what the computer security field describes as “authentication technologies” are not. A password does not demonstrate that you are Alice, nor does a smartcard or even a biometric. All an authentication technology can do at best is to demonstrate that a person is the same person who was present in a previous encounter.

The real authentication usually takes place at first contact: the start of the relationship between an employer and employee, a doctor and a patient, a bank and a customer, a blog and a reader. If the information gathered at first contact is bogus, it will be equally bogus thereafter.

Presenting a passport or a driving license on each visit to the bank would be tedious in the extreme. Presenting an authoritative credential during first contact is generally acceptable when a significant relationship such as with a bank or an employer is being established.

Government credentials typically provide the best form of authentication available: not very good. Most U.S. college students know that forging a driving license is well within their capabilities. Holographic foils look pretty when the card is new but quickly wear away, rubbing up against other cards in the pocket. In Frederick Forsyth’s novel The Day of the Jackal, the assassin obtains a genuine passport under a false name by requesting a copy of the birth certificate of a dead person. Similar schemes still work today. As with any other authentication mechanism, government-issued credentials at best only demonstrate that the person who presents them is the person to whom they were issued.

Identity is a relative, not an absolute, value. If this conclusion appears to be unacceptably postmodern, it is. Computers follow logic blindly to its illogical conclusions and tend to puncture overconfident philosophical pretensions in passing.

It is not the name but the accountability that is important. If someone decides to live under the name of Mr. Saunders, it does not matter if Saunders is or is not his real name, only that it can be used to hold him accountable if necessary.

When a bank issues a credit card, it only needs to be confident that the applicant will pay his bill. Knowing the identity of the applicant is much less important than knowing his previous credit history.

Passwords are a single factor authentication technology: something you know. The problem is that a password is disclosed every time it is used.

There is not really much to be said in favor of passwords except that everyone uses them, which in infrastructure terms is everything. As password-protected Web sites proliferate, they are not even easy to use.

It is not too difficult to remember a single password that is used every day. Nobody tries to remember a hundred different passwords. Either they write them down on a post-it note stuck to their monitor, or they do as I do and use the same password (almost) everywhere. I have (separate) strong passwords for my bank and brokerage accounts and for work, but I don’t spend my time and effort protecting other people’s property unless they are paying me to do so.

As the problems with passwords become ever more painfully apparent, Web sites demand increasingly complex combinations of letters, numbers, and special characters in a futile attempt to force the user to choose a new password that is hard to guess. As a result, I find myself forgetting passwords rather often or, more precisely, I find myself forgetting which particular variation of my password I used at the time.

I bank online, but I don’t check my insurance policies online anymore. Remembering a username/password combination I use only once a year is more trouble than calling them on the telephone.

Passwords cost almost nothing to register and almost nothing to use. The cost of passwords is hidden in the back end, in the customer service or help desk calls that result from inevitably forgotten passwords.

This brings us to the question of how to authenticate a password change request. The solution favored by many banks today is another password, one that is easier to remember: the name of your first pet or mother’s maiden name—something that is easier to guess and quite likely a matter of public record.

This technique can provide an effective control of certain risks in limited situations. Dignified with the unjustified term knowledge-based authentication, it threatens to become a dangerous form of pseudo-security.

Some promoters suggest public awareness campaigns designed to persuade people to keep this public information secret. As efforts in futility go, telling people that the answers to life-long questions must be kept secret is a world-class effort; the MySpace generation has few secrets, and none are life-long. They have already blogged any information they are willing to give to a bank.

A stronger form of backup authentication is a callback scheme, such as the e-mail challenge response scheme we encountered earlier. Verifying the e-mail address, telephone number, or physical mailing address associated with the account provides a stronger means of authentication than a password alone.

Verifying an e-mail address is straightforward but makes the security of the bank dependent on the security of the e-mail service provider. This is a serious flaw if the customer uses a popular e-mail provider and has used the same username and password combination as for their bank account.

The telephone system is somewhat more secure; telephone service providers expect to provide a certain level of security. Unfortunately, the level of security actually provided is rather less than one would desire. And a telephone callback is useful only if the bank has the correct telephone number in the first place. Few customers tell their bank when they change their telephone number; many would rather not receive yet more telemarketing from their bank and give false information anyway.

Callback provides stronger authentication but at the cost of convenience. Users of Internet banking want to be able to access their account from anywhere, not just from home, and they don’t want to have to go through a callback procedure every time. Machine verification bridges the gap. The IP address from which the request is received and information stored on the computer on a previous visit are used to create a profile of the machine from which the request is made.

A request to log in to an account from a computer that has been used to access the account previously is less likely to be fraudulent than a request from a different machine. A request coming from a network address close to the customer’s home is much less likely to be fraudulent than a request from a high-risk country such as Nigeria.

Many banks manage their fraud risk by profiling individual customers and looking for anomalies in their particular behavior pattern. A frequent traveler to Europe might be allowed to access his account from France, whereas a customer who has never traveled is asked to provide additional authentication such as respond to a callback request. A frequent traveler to Nigeria might be given a strong authentication token to use abroad.

Passwords are expensive, inconvenient, and insecure, but they are the technology that the existing Internet infrastructure is designed to support. Few Internet protocols provide a smartcard “slot,” but every successful protocol provides a password slot.

The chief security weakness of a password is that every time it is used, the other party knows the password. A password that changes every time it is used—a one-time password—allows less opportunity for the attackers.

Customers of some European banks already use a one-time password scheme. The bank sends the customer a sheet of cardboard with a series of numbered scratch-off panels. To log into their online bank account, the customer removes the next scratch-off panel to reveal the authentication code, which will be their next One-Time use Password (OTP).

The determined criminal intent on stealing from a particular individual might with some time and effort obtain their OTP password sheet. But doing so forces the perpetrator to return to the pre-Internet tactics used in traditional credit card frauds: stealing wallets, intercepting the mail and so forth. This in turn requires them to accept pre-Internet risks and profits, making the game considerably less appealing to them.

Using a one-time password in place of a traditional static password limits the damage caused by phishing attacks. The phishing gangs can still use phishing attacks to steal authentication codes, but they can only use each code once, and they have to use it before the consumer logs into his account.

The use of one-time passwords interferes with the criminal value chain of the phishing gangs, limiting the type of crime that they can perform. Stolen authentication codes have to be used almost immediately; a carding gang buying stolen codes has to be able to trust the supplier, which is somewhat difficult given that dishonesty is their trade.

Scratch-off cards provide an effective low-technology method of limiting the damage caused by phishing. Unfortunately, “low technology” does not mean “low cost.” The bank has to track which card each of its customers is using and send out a new card before the old one is used up. For the scheme to be secure, every scratch-off card must contain a unique sequence of numbers. Production and distribution of the cards becomes a major effort.

More importantly, for banks that are trying to encourage their customers to use online banking services rather than costly to provide branch services, scratch-off cards encourage customers to ration their use of the online banking service. If they are on a business trip and they are coming close to the end of the card, they are less likely to use the online service.

OTP tokens provide an infinitely large scratch card. An OTP token is used in the same way as a scratch card, but there is no limit to the number of times the customer can visit his online banking site. Each time a button is pressed, the next password appears (see Figure 14-1).

Figure 14-1. One-time password token

Relying on the OTP token alone only provides a single authentication factor. Although the OTP token provides a password that is considerably stronger than a static password chosen by the user, the token itself might be lost or stolen. Using an OTP token and a password (or PIN number) in combination provides two factor authentication: Something known and something carried. Using two factor authentication means that an attacker must break two different types of puzzle to succeed.

OTP tokens were until recently an expensive proprietary technology guarded by a thicket of patents. An enterprise would typically pay $50 per user per year for a time-based token which, like the replicants in Blade Runner, came with a preprogrammed termination date.

The Initiative for Open AuTHentication (OATH), an alliance of token manufacturers and security service providers, has since broken the proprietary lock. OTP tokens are now a commodity technology. Tokens based on the OATH open standards are readily available from a wide range of suppliers for less than $5 in volume, little more than the price of the CPU, battery, and display.

Over time, the cost of OATH tokens will fall even further. Most people already carry a CPU, battery, and display in their pocket: their cell phone. With open standards, any device can be turned into an OATH token for a few pennies (see Figure 14-2).

Figure 14-2. Cell phone with OATH token support

OTP tokens offer much better security than passwords alone, but less than we might like. A one-time password is still a password and still vulnerable to a man-in-the-middle or phishing attack. The successful attacker only gains limited access to the account, but that might be enough.

The most important impact of OTP tokens appears to be that they negate the tactics used in a traditional phishing approach. A customer who uses an OTP token to log in is much less likely to be fooled by an e-mail message demanding that he “verify his account.”

Some one-time password tokens involve a time or challenge element. These make a man-in-the-middle attack somewhat harder and the results somewhat less useful. We can’t eliminate the attack unless we can reliably train users to authenticate the source of the request before giving out their password.

PKI is the queen of authentication methods. Public key cryptography allows Alice to prove to Bob that she knows a secret without revealing the secret to anyone.

The main problem with PKI is storing the secret key; it is much too big for a person to remember. If he only ever uses one computer and the computer is sufficiently trustworthy, he could store his secret key on his machine.

Most people have machines that are far from being “trustworthy,” although this is beginning to change. Making an entire operating system trustworthy is a colossal task; making just the part of the computer where secret keys are stored trustworthy is still difficult but achievable.

The simplest means of achieving a high degree of security for a secret key is to store it in a dedicated computer that is purposely built for performing public key calculations. Depending on the form factor, these are known as smartcards or smart tokens. The Chip and PIN credit cards issued in Europe are a type of smartcard.

Smartcards offer much better security than one-time password tokens, but they only work where there is a reader. USB smart tokens are slightly bulkier and work with practically any computer made since 1998.

At some point in the future, it is possible that wireless smart tokens based on the Bluetooth specification will become practical. Bluetooth is still a rarity on personal computers but commonplace on telephones. A particular advantage of using a wireless token in a corporate environment is that the wireless signal has a finite range so that it can act as a proximity device. The computer can be set to lock its keyboard whenever the user steps away from his desk for a minute or two and unlock automatically on his return.

Bluetooth keyboards are already starting to appear. It might not take more than a couple of years for the makers of computer monitors to realize that Bluetooth is a complementary technology to the USB hubs that they already offer as a built-in option.

OTP tokens work anywhere; smart tokens offer higher security but only work where there is a slot for them to plug into. How should we choose?

Fortunately, we don’t need to. A hybrid token offering both authentication methods need not cost much more than a single-purpose token of either type (see Figure 14-3).

Figure 14-3. One-time password token

According to proponents, biometric authentication technologies offer the strongest possible demonstration that a person really is who he claims to be. After all, what could be more secure than examining a person’s fingerprint or looking at a retina scan?

As it happens, plenty. The practice tends to fall far short of the claims.

Biometrics certainly provide an additional strong authentication factor under carefully controlled conditions. The U.S. government uses biometrics at border crossings to ensure that the person who is using a visa is the same person who applied for it. In the workplace, biometrics prevent workers from using a borrowed ID card or punching a time clock for a friend.

In August 2006, the popular science program Mythbusters demonstrated that it was possible to defeat a purportedly “high-security” fingerprint lock using distinctly low-technology methods.^[1] In one test, a paper copy of the fingerprint was sufficient. It would be hard to use the Mythbusters’ technique with a U.S. immigration officer watching, but fooling a fingerprint-based lock or safe is much easier.

Biometrics rely on the secrecy of something that isn’t very secret. Every time a finger is presented to a fingerprint scanner, the reader has the opportunity to make a complete inventory of every single feature of the fingerprint. No matter how clever the communication protocol between the scanner and the analysis device, the subject gives away the whole secret every time.

Of the biometric identification techniques on offer today, iris scanning appears to be the most promising. Unlike earlier retinal scanning techniques using lasers, iris scanning is noninvasive. Under controlled circumstances, it is practically impossible for an impostor to present a substitute to the scanner in place of his eye without being noticed. If the circumstances are not controlled, we are back playing the game of determining whether the sample presented to the scanner is live tissue.

Although the iris scanner would probably require the Mythbusters to raise their game, I believe it can be beaten. Biometric techniques work well as a means of preventing employees sharing an authentication token. Current biometric techniques do not provide a good replacement for an authentication token, and it is unlikely that any ever will.

Another, more serious problem with biometrics is that the person’s body becomes the key. What do you consider more important: your person or your property?

In 2005, a gang of Malaysian car thieves tried to steal a $75,000 Mercedes. When the thieves were unable to bypass the fingerprint-scanner activated immobilizer, they chopped off the owner’s index finger to start the car.

For the past two decades or so, the principle question in “human computer interaction” has been how the human can provide the machine with the information it needs to do its job. The user-centric principle reverses this bias and demands that we make how the computer serves the user our primary concern.

The padlock icon is emblematic of the old approach. The user wants to know if he is safe, but the padlock icon only tells him that the communication is encrypted. In the old approach, the user was not given the information he needed in case he “became confused.” The user is, however, bombarded with information he simply doesn’t need, such as warning dialogs of the type that lawyers write to dump responsibility for security onto the user.

We can state a principle of user-centric security as follows: The user must be given exactly the knowledge he needs to make an informed trust decision and no more.

The user experience begins with the first contact between the user and the identity system, when the user registers the personal details he wants to share with the site.

The user who is asked to provide information must balance the benefit of disclosure against the disclosure risk. A user might respond to a Turing test to demonstrate that he is not a robot without much fear; anything else carries a disclosure risk.

We would like registration to be as infrequent as possible. If I have entered all my personal details to register for the London Times, I should not be required to enter them again for its sister paper, The Sun. I should not be required to enter them again anywhere, unless I want to establish a new pseudonymous identity.

Many Web sites collect this type of information so that they can tell their advertisers the type of person who reads the site. Accuracy is preferred but not essential. If someone claims that he is a millionaire rather than unemployed, he will receive advertisements targeted at the wrong audience. Other Web sites—particularly those offering financial services—do need to know if their customer is telling the truth, if not for their own purposes then to meet government regulations. The verification performed on the information provided, if any, should be appropriate for the level of risk.

As with registration, logging in should be as infrequent and as easy as possible. Authentication should be as lightweight and simple as possible. This means that if the user is visiting multiple sites, he should not normally be required to log in to each one individually unless there is a particular reason to require an additional authentication step.

The user experience should be ubiquitous, available on any platform a user might use whether that is a computer (Windows, OS X, and so on), a mobile phone, or anything in between.

Roaming is the ability to access an account from more than one machine. Depending on the application, roaming might be a requirement.

It is entirely reasonable for a bank to decide that customers will only be able to use a limited number of machines to perform a risky transaction such as adding a recipient for bill payment or requesting a wire transfer. Readers of a newspaper or a blog are going to expect to be able to read it from anywhere.

The field of computer security usability is new, even by Web standards. The seminal papers in the field were published in 1999, and the first conferences held in 2005. Microsoft CardSpace, a component of Windows Vista that is also available for Windows XP, represents the first new major mainstream security application whose design has been shaped by security usability considerations.

A useful demonstration of the CardSpace user experience is the blog of its chief architect, Kim Cameron.

We live in what I call the “Google Earth” era of user experiences. Google Earth was the first mainstream consumer application other than a game to present the user with an experience that was as compelling as those routinely presented in Hollywood movies. CardSpace is the first security user experience to cross that bar.

CardSpace 1.0 demonstrates that security is not incompatible with usability and meets all our requirements for the user experience except ubiquity and roaming.

Ubiquity is already being addressed: CardSpace is built on open standards including WS-Security and WS-Trust, and code implementing the protocol is already available from the Open Source Higgins project. Equivalent implementations should be available for all the major operating system platforms in a short time.

Roaming is supported in CardSpace 1.0, but the user experience is much worse than we would want. People who use multiple computers on a regular basis will have to transfer their CardSpace credentials from one machine to another using the limited import and export features supported by CardSpace. This particular limitation is much harder to remove without compromise to the security measures that protect CardSpace credentials from malicious code such as viruses. The most likely solution is to abandon the idea of transferring the credentials altogether and instead implement the CardSpace subsystem on some form of smart token.

CardSpace is built to answer the question, “What is the best possible identity infrastructure we can build today if we begin from a completely clean slate?” OpenID is built to answer the question, “What is the best identity infrastructure we can build today if we begin from where we are?”

CardSpace represents a clean break with the past, a no-compromises approach designed to replace the existing infrastructure. OpenID 2.0 is the result of an organic, pragmatic approach combining the work of many different authors.

The difference in approach has proved to be complementary rather than disruptive. OpenID provides an approach that any Web user can use today; CardSpace provides the no-compromises architecture we want to arrive at in the future. The challenge is to ensure that these approaches eventually meet.

You might well have used OpenID already without even knowing it. OpenID is often used to allow a reader to post comments on different blogs without needing to register separately for each one.

The keystone of the OpenID system is an identity provider. Several identity providers exist, and a core article of faith in the OpenID system is that users can choose any identity provider they wish.

My identity provider is the VeriSign Labs personal identity provider (PIP), and my OpenID is hallam.pip.verisignlabs.com.

As with CardSpace, OpenID allows me to control the information I reveal to a site. I can even manage independent personas for different sites.

SAML was designed before the emergence of blogging and before the emergence of professional Internet crime had been widely acknowledged. The specification was designed to meet the concerns of enterprises that had made significant investments in IT infrastructures and were looking to make sense of them. In particular, the enterprises wanted to eliminate the error-prone process of managing authentication and authorization data separately for each IT system.

Single Sign On systems were available from many vendors, but deployment was a serious headache requiring each IT system to be individually “integrated” into the Single Sign On system, work that might need to be repeated if a system was upgraded. Instead of enabling the enterprise to become more flexible, the IT infrastructure was making it more difficult to change.

SAML was designed to provide a standards-based access control infrastructure that would allow enterprises and the vendors of Single Sign On systems to push the cost of integration onto the application providers. Enterprises with SAML deployed would insert the question, “Does the vendor’s product support SAML?” in the Request For Proposals (RFP) they issued at the start of a purchasing process. A feature that is regularly requested in RFPs is likely to become part of a vendor’s product roadmaps. And new versions of their products would come with a SAML “socket” for the customer to “plug” their enterprise SSO system into.

The concept of a network authentication service was not new; the RADIUS and Kerberos standards were introduced in the mid 1980s. LDAP and X.500 directory allowed for publication of attributes. Various proprietary schemes were being marketed for network authorization services. Each infrastructure served the limited set of functions it was designed to perform, but each worked in a completely different way.

SAML brought together all the component parts of the access control problem—authentication, attributes, and authorization—as consistent standards-based network-accessible service.

The principal building block in the SAML architecture is the assertion. An assertion has a specified issuer and contains three types of information: statements, conditions, and advice.

A SAML assertion is not simply a set of claims; it is a set of claims that can be subject to conditions. Conditions allow the scope of a claim to be bounded in time and by audience. This is important from a legal point of view. Many of the legal complications raised in X.509 are because an X.509 certificate is simply an assertion made to the world in general; the issuer in effect writes a statement headed “To whom it may concern.” In SAML, the issuer can direct an assertion to a specific audience, thus limiting and possibly eliminating unintended liability to parties outside that audience.

The core SAML specification defines three types of statement:

In the classic SAML architecture, assertions containing these assertion types are issued by separate services (see Figure 14-7). These services allow each part of the infrastructure to obtain exactly the information required to do its function.

Figure 14-7. Classic SAML architecture

The relying application has a decision to make: Should it permit access to a resource or not? The application does not want to manage the information necessary to answer the question, so the question is handed to an authorization service, which answers it by means of an authorization statement . To issue the authorization statement, the authorization service consults some form of authorization policy . The SAML specification does not address authorization policy, but the sister specification, eXtensible Access Control Markup Language^[4] (XACML), does.

An authorization policy can be written using statements of the form, “Alice is allowed to access the accounts file,” but working at this level of detail is time consuming, error prone and, in almost all cases, unnecessary. Security policies are easier to maintain in terms such as, “Members of the finance department may read files with the finance attribute” and “The accounts file has the finance attribute.” To resolve a policy of this type, we need an assertion containing an attribute statement such as, “Alice is a member of the finance department.”

Before allowing “Alice” to access the accounts file, we do, of course, need to be sure the request actually comes from the real Alice. This decision must ultimately be taken by the application that controls the requested resource, but again the application does not want to have to support every possible method of authenticating Alice. This question is much better handled by an authentication service, which authenticates the party purporting to be “Alice” by any of the authentication mechanisms it supports and returns an authentication statement that states, “Alice was authenticated using mechanism X and may be reauthenticated by mechanism Y by proof of possession of credential Z.”

I intended the assertion structure of SAML to be both a critique of and a bridge toward the Semantic Web. The Semantic Web is a vast topic that demands at least a book in its own right.

Today, the Web provides vast quantities of raw information, much of which cannot be used. The aim of the Semantic Web is to build a Web of “knowledge,” which I define as information that can be used.

In the “layer cake” model of the Semantic Web set out by Sir Tim Berners-Lee, trust is the apex of a pyramid built layer on layer, with logic at the base. In my view, trust must be the foundation; before we decide whether to read the statement, we first decide whether it is worth reading (see Figure 14-8).

Figure 14-8. Semantic Web layer cake model

This conventional model is not entirely wrong; trust is not just the foundation. Trust is also one of the types of information we want to deduce using the Semantic Web. As children, we trust information provided by a small circle: our parents, teachers, and friends. Over a lifetime, our circle of trust changes as a result of our experiences.

SAML 1.0 is agnostic on the subject of identifiers. This appeared to be a good idea at the time, but it has since proven to be a mistake.

Failing to commit to a particular identifier scheme has meant that SAML cannot commit to a discovery scheme which in turn means that SAML provides us with most of the necessary components to build identity systems but falls short of providing an identity system.

OpenID does define both an identifier format and a discovery mechanism. When I claim my OpenID hallam.pip.verisignlabs.com at a Web site, the site applies the rules set out in the OpenID specification to discover the location of the authentication server it should use.

When employees require access to valuable assets to perform their jobs, employers need reliable means of controlling access and establishing accountability. Strong authentication is an essential requirement in both cases.

SAML was originally designed to meet the expanding needs of enterprise authentication, authorization, and accountability. The cost of managing a proliferation of authentication systems was widely understood but, for most enterprises, “Single Sign On” (SSO) remained a pipe dream.

The problem was not a lack of SSO solutions; a cornucopia was on offer. But SSO was a moving target with new applications springing up as fast as the old were integrated. And the integration process began again whenever two enterprises with SSO solutions from different vendors merged.

As soon as it appeared that SSO was finally becoming a solved problem in the enterprise, the extranet hit. Each outsourced service required employees to manage a fresh set of accounts: telephone conferencing, Web conferencing, travel, 401K, stock options.

Secure identity based on CardSpace and SAML puts SSO within the reach of the enterprise once again: one employee, one account. Instead of starting with the authentication solution, enterprises can issue each employee with the credential that is most appropriate to manage cost, convenience, and risk.

Blogspam is the pain point that drove the evolution of OpenID, which is somewhat curious since we could eliminate 99% of current spam appearing on blogs without using any form of authentication at all.

Most spam appearing on blogs today is linkspam. Unlike e-mail spam, the target of linkspam is not the reader of the blog; it is the search engines that use Web links to rank the relevance of sites. In particular, the target is Google.

All we need to do to eliminate the incentive to post linkspam is to mark the Web page so that the search engines know which parts were written by the blogger and which contain third-party comments. The search engines can then either ignore the comments entirely when computing rankings or use the information to identify linkspam sources and apply appropriate penalties.

Of course, the day that the spammers stop targeting the search engines will be the same day they begin targeting the user. Dealing with the replacement spam will require the same accountability-based approach of authentication accreditation and consequences. Strong identity provides the tool we need to begin.

The necessary information could be encoded by extending the Web page markup language HTML. However, this would take a lot of time. A much better approach is to use a technology called RDFa, which allows an HTML document to be annotated with Resource Description Framework (RFF) attributes. RDFa is currently being developed by the World Wide Web Consortium as part of its Semantic Web initiative. It is a much better solution because it allows the information to be encoded without changes to the Web infrastructure.

Figure 14-9 shows an example of how RDFa markup might be applied to a blog. The objective is to encourage search engines to use only the parts marked in bold to calculate search rankings. The page is written in normal XHTML. The RDFa markup is contained in the <span> elements.

Figure 14-9. RDFa markup

The first span element declares that all the markup in the comment area has come from an external source. There are two comments, each of which is marked with a span declaring it a separate contribution and a second span that identifies the poster. The first comment is linkspam from an unknown source. The second comment comes from an authenticated source and might be acceptable to the page ranking engine if both the blog hosting the comment and the individual commenter are considered trustworthy.

Semantic markup allows us to do much more than control blogspam. Knowing the purported identity of the commenter and the means of authentication allows tools to be built that aggregate comments from multiple blogs in interesting ways. A personal blog might have a link to a page listing all the comments that the blogger had posted on other blogs.

Applying semantic markup also allows us to build moderation schemes that work across the blogosphere as a whole instead of being confined to individual sites.

Secure identity provides the necessary authentication infrastructure to secure transactions.

Earlier in this chapter, we saw how banks today use machine verification techniques as a key input to their risk mitigation strategy. Today these systems rely on HTTP cookies—pieces of data that a Web server sends to a browser and the browser returns on its next visit. HTTP cookies are a notoriously problematic technology from the privacy point of view; they provide too much information on where a user has been. On the other hand, cookies offer much less than we would like from a security point of view. Although Web browser security architects take the need to protect cookie data very seriously, the application designer is always at a disadvantage to the authors of malware in all its forms.

You can think of CardSpace as providing a “super cookie” answering both the security and privacy concerns. Working within the security context of the platform, the CardSpace implementers start with an advantage over the providers of malware, which will become even stronger as technologies such as trustworthy computing are deployed. User-centric design addresses the principle privacy concerns that cookies raise. The user is always in control and must give explicit approval each time a card is used.

Customers want banks to protect their confidentiality, but their customers much bigger concern is for the banks to protect their money, which is also the principle concern of the banks.

A criminal market for confidential information certainly exists, but the opportunities for the criminal who steals money are considerably greater than the opportunities for the criminal who steals information.

The essential concern, therefore, is to control the means by which the criminals can transfer money out of the account:

As we saw in Chapter 9, “Stopping Botnets,” the emperors of ancient China understood this problem; the Great Wall did not stop barbarians from getting in, but it did prevent them from getting out with the loot.

The principal tools used to control transaction fraud today are risk assessment and velocity controls. The more that is known about the recipient of the transaction, the more effective these tools become.

In particular, most bill payment transactions are used to pay utilities for the telephone, gas, or electricity. The actual risk involved in this type of transaction is essentially nil: If a payment is made by mistake, the bank knows that the recipient is unlikely to disappear before the money can be recovered. The problem we face today is the lack of an effective and scalable mechanism for identifying the low-risk transactions from those that are potentially higher risk.

Extended Validation is likely to play a key role in developing a next-generation infrastructure for secure transactions, as are CardSpace-like protocols and platform infrastructures, which securely bind a transaction authorization to a specific recipient and a specific amount.

Recently, I talked to an old friend who was complaining that the system which remembers the position of the seat on his BMW had only three positions. This would not be a problem for him as such, except that his wife often lends the car to her parents and, won’t he please just fix it so that there is a fourth position?

A fourth button would meet the immediate need, but what will happen when the children want to drive? And the aunt from out of town?

In the future, we will increasingly expect and demand that machines accommodate themselves to us. Machines must anticipate and adjust to our needs.

An identity infrastructure would play a critical role in such an infrastructure. Instead of limiting the car to three, four, or even fifty seat positions, you could store each user’s preference on his identity token. The same token would be used to start the car, to set the temperature preferences, and to tell the radio which stations the driver likes to listen to. If it was a preplanned trip, the satellite navigation system would be automatically programmed with the route and know which places it should suggest stopping at for a break.

As we saw in Chapter 1, “Motive,” the risks of online dating, or for that matter dating of any kind, do not stop when a child reaches the age of 18. Security education for children must teach lifelong skills, not just how to survive until adulthood. A 120-pound thirty-something woman must treat personal security with at least the same degree of concern as a 120-pound teen when meeting a six-foot tall, 250-pound male that she only knows through meeting in an Internet chat room. Does someone know where she is? Is the place where the couple is to meet public? Does she have an escape route planned?

The security concerns of kids are not very different from the security concerns of adults. The chief difference is the resources available to them. Adults are more likely to have a car or other means of personal transport that provides them with an escape route. Adults are more likely to have cash available in case of emergency.

Another difference between adult and child safety is that we consider consenting adults to be safe when they are only meeting online. A child who is chatting online with a person she believes to be a child but is in fact an adult pedophile is very much at risk.

A secure identity infrastructure would allow “children only” chat rooms to be established, where anyone posting as a minor must be accredited by his school or other trustworthy youth-centered organization. Such a scheme is hardly a panacea; children pose at least as great a threat to each other as adults do. But it does help control the risk of adult predators and does not appear to significantly increase other types of risk.

Schools are not in the business of operating an identity infrastructure, but the architecture of Identity 2.0 means that they can provide the necessary proof of age accreditation information without doing so. Extended Validation provides us with the necessary infrastructure to authenticate the schools as credential issuers. All we are lacking is the necessary political imperative to put the pieces together and deploy.

The proposed UK national identity card is officially estimated to cost $5.5 billion,^[5] with realistic estimates running at up to three times that amount.^[6] If past experience of IT project contracting is any guide, the actual costs will exceed even the most pessimistic estimates. Her Majesty’s Government has not yet noticed that the minimum number of consultants required to implement an IT system is the square of the number contracted to design it.

Worse still, all the costs will be incurred up front before the government agencies see any of the purported cost savings and the entire project rests on a meager base of political support.

The biggest cost in the scheme is registering and authenticating the 45 million or so citizen cardholders. Every cardholder must be authenticated using a procedure that meets the needs of the agency with the most demanding needs. So 30 million citizens who will never draw unemployment benefits will have to be authenticated as if they will.

The SAML architecture allows the process of authenticating and registering identity claims to be deferred until they are needed. The citizen could receive the card in the mail or buy one over the counter from a supermarket as they would a SIM card for their mobile phone.

Authentication would only take place as and when required. If the citizen wanted proof of age accreditation, for example, he would present his card and proof of age at a post office. Biometric techniques only provide an effective control in limited areas such as preventing benefits fraud. It makes no sense to require millions of citizens who are unlikely to require these services to present themselves for a biometric registration process, which will inevitably be expensive as any process requiring millions of unwilling and uncooperative individuals to comply will be.

If Alice enters a British pub, the barmaid only needs to know that Alice is over 18 to serve her. He does not need to know her name, address, or anything else about her.

The SAML architecture allows the identity of the party making the request to be concealed from the relying application. Only the attribute server and the authentication server need to know who is making the request; these services do not need to know what is being requested.

We can take the principle of minimizing the amount of information disclosure a stage further. Using traditional authentication approaches, we can hide Alice’s name from the barmaid, but the barmaid can still keep a record of the number of times a person has visited previously. If we want to be serious about privacy, we should ensure that the barmaid only knows that Alice is over 18 and nothing more.

SAML does not support this type of interaction. We can replace the name “Alice” in an SAML assertion with a random string of bits, but the random string of bits is constant each time it is presented. We can eliminate the identifier altogether, using a fresh random string on each use, but this does not help us unless all the information that Alice presents to the relying party is random and unlinkable, including the authentication credentials.

This type of interaction has been studied at length by the cryptographers who have proposed a range of sophisticated schemes that simultaneously provide strong authentication and complete anonymity. The work of David Chaum and Stefan Brands is particularly interesting.

My approach to this problem is rather more pragmatic. I like the protections provided by exotic cryptography, but not the constraints they bring. In particular, every system I have ever built that has been successful has been used in ways that I never anticipated during the original design. Using exotic cryptography tends to result in a scheme without any “slack” necessary to adjust to real-world circumstances.

This is particularly the case in a national identity card scheme. Without the ability to adjust and adapt the scheme to the needs of preventing terrorism and emergency needs such as imposing rationing, an identity card scheme has little value. Her Majesty’s Government is not going to accept a scheme that is expressly designed to shut the door on these requirements—not least because its members remember that terrorists attempted to murder the entire British cabinet in 1984.

A simpler solution to the problem is to use conventional cryptography to encrypt the information exchanged between the cardholder and the relying party such that only the authentication authority can determine the cardholder’s identity. The communication between the authentication authority and attribute authorities is then carefully designed so that these interactions—including legally authorized exceptions—are effectively subject to civil accountability.