Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In medieval times, strong walls and moats surrounded great cities. Guards were posted at the gates of the city, and everyone coming or going was inspected and questioned about their purpose for entering or leaving the city. At the same time, cities were where the markets were held. You can imagine the crush at the gates on market day with peasants bringing their goods into the city from outside and visitors clamoring to get to market. After market was over, the process was reversed. With our modern eyes, we can see what an impediment to commerce the walls were, yet at the time, city residents were thankful for their security.

The walls were not broken down by enlightened thinking about of how markets should work, but rather a weapon for which the walls were no match: the trebuchet (see ). A trebuchet is a gravity-powered catapult that is vastly superior to its torsion-powered cousins. The trebuchet revolutionized medieval siege warfare and eventually spelled the end for city walls. The result not only forced an alternative strategy for security, but also had the pleasant side effect of increasing commerce.

I recently had the opportunity to sit with a group of CIOs and discuss digital identity. What struck me was how much of the conversation was about security and liability rather than identity and opportunity. They had a siege mentality and their security planning showed it.

Modern corporations are the walled cities of our time—sitting behind firewalls and defending themselves from attack. What these CIOs and others can't see is that their security implementations are restricting their company's opportunities in the same way that ancient walls restricted commerce in their day. Fortunately, commercial enlightenment, rather than a weapon that cannot be withstood, is awakening a desire in corporations to rethink how we provide security so that our interactions with customers, employees, partners, and suppliers are richer and more flexible.

Figure 1-1: Trebuchet

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Business Opportunity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The economic shifts that have occurred over the last decade have changed how businesses operate and the expectations of customers. One of the most dramatic shifts has been the rise of network-based, automated services. In many cases, we're "spending more and owning less," in the words of Jeremy Rifkin. When I fly, I almost always purchase tickets online, but more than that, almost all of my needs as a customer of the airline are self-serviced, using online web applications. I can check flight schedules, be notified by SMS if my plane is running late, check my frequent flyer account balance, and even redeem upgrade points and change my seat online. The changes underlying these trends have profound implications for businesses and customers alike.

For businesses, a service-oriented economy means that they must adjust to entirely new ways of relating to their customers. The World Wide Web changed the way companies market their products. But more importantly, the products themselves have changed. Perhaps the most significant change is that there is no longer a human in the loop to create a trust relationship with the customer, make up for process deficiencies, and represent the company. When two businesses merge, they often find that they have very different approaches to knowing their customer and that this makes leveraging the combined operation almost impossible.

For customers, the changes are equally dramatic. Where they used to purchase things from people at physical locations, they now purchase or use services delivered to them electronically on their computer, PDA, and even their phone. The usual trust marks that customers have relied on in the past are either missing or easily forged. As the number and breadth of services that people use grows, they find that they are inundated with requests to identify themselves and to divulge information they consider private.

In addition to their customers, businesses have relationships with partners, suppliers, and employees. Networks have changed those relationships as well. Just as with the business-customer relationship, these relationships are increasingly moving to the electronic world and being mediated by automated processes rather than people.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Digital Identity Matters

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At the heart of this service-oriented economy are network-based, automated transactions. Automated transactions are fundamentally different than the transactions that occur in the physical world. When I stop by the convenience store to buy a snack, I can exchange cash for peanuts. Unless the clerk happens to know me, the transaction is anonymous. In contrast, in the service-oriented economy, anonymous transactions are rare, because delivering service automatically almost always implies that you have to know something about who's receiving the service—if not their names, then at least their preferences or other attributes. This identifying information is usually transferred digitally, across the network. In a service-oriented economy, digital identity matters.

Of course when we talk about the service-oriented economy, we're not just talking about e-commerce. Note that my example with the convenience store involved a small cash purchase. But imagine the same scenario, except this time I use a debit card, credit card, or check. In any of those cases, I've invoked a network-based financial service as part of the overall transaction. Network-based services are as pervasive in transactions that occur in the physical world as they are in online interactions.

In an automated, network-based service, I have to know who you are in order to sell you access to my service. Since these services are increasingly delivered over digital networks, businesses need reliable, secure, and private means for creating, storing, transferring, and using digital identities. Network-based, automated services are not just delivered to customers—employees, partners, and suppliers also interact with the enterprise via services. In many cases, anonymous service is impossible or undesirable, and as a consequence, digital identities must be assigned and managed.

In addition to identifying customers to sell them services, business have an increasing need to identify employees, systems, resources, and services in a systematic way to create business agility and ensure the security of business assets.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using Digital Identity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Digital identity is the lynch pin in each of the activities we have just discussed, along with a wide variety of other activities important to business. Consequently, how your organization manages digital identities will have a great impact on whether you are constantly fighting problems brought on by a lack of attention to managing identity, or whether you are exploiting opportunity enabled by a flexible and rational digital identity infrastructure.

The common ATM machine is a great example of how digital identity enables new business opportunities. Before ATMs were invented, a bank's customers took care of their banking needs by presenting pieces of paper to a human teller. The papers included instructions to the bank (e.g., deposit slips), cash, checks, and other financial instruments. Unless the teller personally knew the customer, the customer usually also presented some kind of identity credential, such as a driver's license. The teller was able to verify the identity of the customer and the validity of the various pieces of paper.

The ATM was possible only because banks created a means of identifying their customers digitally. We're all familiar by now with the debit card and PIN that ATMs require from us before service. The card carries identity information and the PIN tells the bank that the person presenting the identity is entitled to use it. With the advent of a digital identity infrastructure, banks no longer needed a human in the loop to verify the customer's identity.

From the bank's perspective, the most obvious benefit from an ATM is to reduce the cost of employing the teller, but there are other benefits as well. I lived in Japan for two years during the 1970s and experienced ATM machines there for the first time. I'd never even heard of ATM machines before that. I had a chance to visit Japan again in 1996 and found something strange. There were still plenty of ATM machines, but they operated only when the bank was open. You you could only receive during banking hours.

Japanese banks, at least in 1996, still viewed ATMs as simply "teller replacements." But in the U.S., something more interesting had happened: ATMs were used to extend service in ways that went beyond merely replacing the teller in the branch. ATM machines extended service in three fundamental ways:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Business Context of Identity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Like medieval city planners, IT professionals and others have traditionally thought of security as an edge game. Given a firewall and access control to the network, we can do a reasonable job securing a business. However, the economic shifts spoken of previously have driven the need to integrate systems not only internally, but with trading partners and customers as well. This trend is fueled by XML and the creation of standards for exchanging data and the increasing trend to decentralized computing that is embodied in service-oriented architectures (SOAs) and web services. But this trend has ramifications for business security: we can no longer treat the edges of the network as a secure perimeter.

When integration is driven by business, rather than IT needs, security policies need to talk about documents, data, actions, people, and corporations instead of machines and networks. This new security model is infinitely more complex than the old "secure perimeter" model. But even if you can define your identity strategy, how do you ensure that it is properly implemented across dozens or even hundreds of systems, and, at the same time, control access to fields of a database or paragraphs of a document?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Foundational Technologies for Digital Identity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Understanding how your organization can make use of digital identity requires understanding concepts such as trust and privacy. Moreover, digital identity is built on a set of technologies that includes cryptography, authentication, authorization, identity provisioning, directories, digital rights management, identity federation, and interoperability standards. Later chapters in this book will discuss these concepts and technologies in detail, and show how they fit into an overall identity management strategy.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Identity Management Architectures

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The most difficult part of getting identity management right isn't technical. Management, policy, and even political issues are more likely to be the things that stand in the way of success. To that end, the final section of this book will describe a methodology for creating what I call an identity management architecture (IMA) that can help you overcome these challenges.

An IMA is unique to each organization. Creating an IMA for your organization requires a firm framework for governance and understanding the business context within which it will operate. To that end, the methodology in this book includes detailed ideas about how you can document, analyze and understand the business context that your identity infrastructure will have to support.

An IMA has three primary components:

Process Architecture

The process architecture is a methodology for determining how your business accomplishes identity related tasks now and how they should be accomplished in the future. The architecture is based on an identity infrastructure maturity model that lays out how processes can be changed to make them more effective in supporting the identity needs of the business.

Data Architecture

The data architecture is a model of the identity data in your organization. Recently, a number of news stories have highlighted organizations that lost control of identity data and were publicly embarrassed over the resulting privacy concerns. Getting a handle on where your identity data is and what processes affect it will help you avoid these problems and help you build an infrastructure that is responsive to business needs.

Technical Reference Architecture

The technical reference architecture is how the IMA communicates implementation guidance to system architects, the people who design the systems that use identity processes and data.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Defining Digital Identity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In 1974, the family therapist Salvador Minuchin declared that "The human experience of identity has two elements: a sense of belonging and a sense of being separate." This is as good a description of digital identity as it is our psychological identity. A digital identity contains data that uniquely describes a person or thing (called the subject or entity in the language of digital identity) but also contains information about the subject's relationships to other entities .

To see an example of this, consider the data record, stored somewhere in your state or country's computers, that represents your car. This record, commonly called a "title," contains a VIN (vehicle identification number) that uniquely identifies the car to which it belongs. In addition, it contains other attributes of the car such as year, make, model, and color. The title also contains relationships; most notably, the title relates the vehicle to a person who owns it. In many states, the title is also a historical document, because it identifies every owner of the car from the time it was made.

Digital identity management is about creating, managing, using, and eventually destroying records like the one that contains the title for your car. These records might identify a person, a car, a computer, a piece of land, or almost anything else. Sometimes these records are created simply for inventory purposes, but the more interesting ones are created with other purposes in mind: allowing or denying access to a building, authorizing the creation of a file, allowing the transfer of funds, and so on. The relationships between identities and the authorized actions associated with them make digital identities useful, though, at the same time, difficult to manage.

The world of digital identity has its own nomenclature. Most of the terms are familiar but are used in specific ways. This section introduces some of that terminology.

A subject or entity is a person, organization, software program, machine, or other thing making a request to access a resource. A

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Language of Digital Identity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The world of digital identity has its own nomenclature. Most of the terms are familiar but are used in specific ways. This section introduces some of that terminology.

A subject or entity is a person, organization, software program, machine, or other thing making a request to access a resource. A resource might be a web page, a piece of data in a database, or even a transaction on a credit card. To gain access to the resource, the subject lays claim to an identity. Throughout this book, we'll frequently use the word "subject" instead of "person" to remind us that non-human subjects such as machines or programs often use resources.

In this context, identities are collections of data about a subject that represent attributes, preferences , and traits . Attributes are acquired, describing information about a subject such as medical history, past purchasing behavior, bank balance, credit rating, dress size, age, and so on. Preferences represent desires such as preferred seating on an airline, favorite brand of hot dog, use of one encryption standard over another, preferred currency, and so on. Traits are like attributes, features of the subject, but they are inherent rather than acquired. Another way of thinking about the difference between attributes and traits is that the former may change, but traits change slowly, if at all. Examples of traits include blue eyes for a person, or how and where a company was incorporated. Since the distinction between attributes, preferences, and traits rarely makes a difference in the design of an identity infrastructure, we'll typically use attributes to mean all three unless there's a specific need to distinguish among them.

One of the primary purposes of an identity system is to authorize particular actions. This process is shown in and is broken down as follows:

1. To use an identity to justify accessing a resource, a subject must present credentials along with the request. Credentials are proof that a subject has the right to assert that a particular identity belongs to them. Credentials are a way of transferring

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Identity Scenarios in the Physical World

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The concepts and words used in the last section can seem intimidating, but in reality, most of these concepts are perfectly understandable given our everyday experience in commercial transactions in the physical world. To see how some of these ideas map to our everyday understanding, let's consider a common transaction at a convenience store: buying beer.

When a person (i.e., the subject or entity) wants to buy beer (i.e., perform an action on a resource), he is required to submit proof that he is of legal drinking age. The common way to do that is by presenting a driver's license. A driver's license is a credential that asserts that a person has certain attributes and traits. The license contains authorization to perform certain tasks, specifically to drive a car. The clerk (i.e., security authority) examines the license to see if it looks real (i.e., determines the validity of the credential) and uses the picture (i.e., embedded biometric device) to see if the person presenting the license is the same person who owns it (i.e., authenticates the credential). Once certain that the license is authentic, the clerk reads the birth date (i.e., an attribute) from the license and determines whether the person is over 21 (i.e., consults a security policy determined by the state and makes a policy decision about permissions associated with the identity for a particular resource).

Now, suppose the person pays with a credit card. The credit card (a separate identity credential) is presented to the clerk. The clerk just saw the driver's license and so can establish the validity of this credential based on the first. The clerk, acting as the policy enforcement point, runs the card through the point-of-sale terminal, which transmits identity attributes from the card (the cardholder's name, credit card number, and expiration date) along with the resource to be accessed (credit in the amount necessary to buy the beer) to the bank, which acts as the policy decision point and determines whether or not the subject is entitled to credit in the necessary amount. The clerk receives the credit authorization (authorization decision assertion) and completes the transaction.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Identity, Security, and Privacy

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Digital identity is often thought of as a subtopic of computer or information security. Certainly, digital identity is an important part of security, but digital identity has greater utility than just protecting information. We've already discussed how digital identity enables important business relationships. At the same time, information security is about more than simply performing authorization and authentication. Firewalls, for example, provide security but is not necessarily about identity.

Still, the goal of information security is to protect information from unauthorized access, destruction, or alteration. Privacy is the protection of the attributes, preferences, and traits associated with an identity from being disseminated beyond the subject's needs in any particular transaction. In a circular manner, privacy is built upon a foundation of good information security, which is, in turn, dependent on a good digital identity infrastructure. This relationship is shown in .

Figure 2-2: The identity, security, privacy triangle

We will discuss privacy in some detail in . Computer security, beyond the concepts that it has in common with identity, is beyond the scope of this book.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Digital Identity Perspectives

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We usually speak of identity in the singular, but in fact, subjects have multiple identities. From our point of view, they tend to seem like different facets of our identity, but other entities have a specific view that corresponds to only a subset of those attributes. For example, my bank sees a set of attributes for me that correspond to my credit card numbers, account numbers, credit score, and so on. My employer sees a different subset that overlaps only in a few points such as name, social security number, and the one bank account I give my employer for depositing my paycheck.

My multiple identities are linked by me and little else. They represent different perspectives on who Phil Windley is and what attributes I possess. Most of these attributes are stored in various formats in myriad databases. In the State of Utah alone, there are over 250 different databases in which portions of my digital identity might be stored, depending on my interactions with the State. These multiple identities, or personas, as they are sometimes called, are tied together by a few common data elements that are used, imperfectly, as keys for accessing them: my name, my address, my social security number, and my birthday.

To make sense of all of this, Andre Durand, the founder and CEO of Ping Identity Corp. introduced the concept of "tiers of identity." shows a schematic of these tiers. At the bottom is the first tier, labeled "My Identity." Tier 1 consists of attributes and traits that are associated with the subject and are both timeless and unconditional. For example, my name is Phillip John Windley, I have blue eyes, and so on.

Figure 2-3: Identity tiers and their relationship

Tier 2, labeled "Shared Identity," consists of the attributes that are assigned to us by others. These attributes are shared , because they are used to identify the individual but are temporarily issued based on some kind of relationship. Your wallet is filled with Tier 2 identities; your driver's license, your employee badge, your credit card, your health insurance card, and your library card are all examples of identity information that is assigned to you. Once the relationship that defines the identity is terminated, the attributes associated with it are no longer useful.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Identity Powershifts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

How your employees and customers perceive your efforts to build a digital identity infrastructure depends in part on being cognizant of people's inherent dislike of what we can now classify as Tier 3 relationships and sensitive to their desire that you give them real value in any Tier 2 relationships. The identity problems and potential faced by organizations—the very subject of this book—happen in Tier 2.

For the most part, Tier 2 relationships are dictated on the terms of the business or organization and consented to by the individual. This one-way relationship is likely to change over time as service-oriented businesses become more sophisticated. This powershift is brought on by increased service standards and improved systems that make it easier for customers to switch their allegiances. Also, businesses are beginning to offer more customized services, making it more likely that customers will begin to dictate some of the terms in their relationships. It will no longer be a "take-it-or-leave-it" world, but a world based on what some have called "mass customization."

One of the fallouts from this powershift is identity aggregation . As we've noted, individuals mentally aggregate their Tier 2 relationships much more than is possible in the real world. I don't tend to think of myself as a Key Bank customer; I think of myself in holistic terms, with Key Bank being just one of many relationships that I am party to. Federation and other means of aggregating identity, which we'll discuss in , are one answer to the identity silos created by the multiple Tier 2 relationships. I have completely separate relationships with my airline and my rental car company, and that creates extra work for me each time I travel. Getting back to value, I'm willing to have those identities aggregated if it makes booking travel more convenient.

Another fallout from this powershift is the convergence of Tier 3 and Tier 2 identities. As sophisticated identity systems allow companies to better identify individual customers and businesses adapt by providing more fine-grained service customization, the need to market to broad demographic groups is lessened. I'm not about to predict the disappearance of spam anytime soon, but it and other mass-market approaches are becoming less and less effective. Good businesses will recognize this shift and move their operations away from broadcast and mass marketing and towards more individual-specific marketing efforts.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Conclusion

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I believe that over the next decade we will see brand new mechanisms spring up by which customers can telegraph their desires to businesses, and businesses will find new ways to meet those demands. As an example, not too long ago, I was at a conference and got an email from Doc Searls asking if anyone had a spare power adapter for a Powerbook. He'd forgotten his at home. This simple act was Doc signaling a need to the group he knew was at the conference and used Macs. Later that day, we discussed how it would be nice for Doc to be able to let local businesses know of his need as well, so that they could offer to solve his problem—for a fee, of course. At present, the only way to do this would be for Doc to actually look up local businesses and contact them one at a time. That needn't be the case in a world with good networks and better identity infrastructures. Doc calls this "demand informing supply." I like to think of it as the spontaneous fulfillment of desire.

Regardless of what you call it, business is more than just transactions. Business is about relationships—relationships with customers, employees, suppliers, and partners. These relationships—especially those with customers—have tended to be one-way and very impersonal. Digital identity changes that, and just in time, because customers are demanding better and more customized service wherever they happen to be and exactly when they want it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Trust

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the influential book Trust: The Social Virtues and the Creation of Prosperity, Francis Fukuyama argued that public values, especially trust, shape the direction of national economies. Among other things, Fukuyama shows how trust reduces transactions costs, and ultimately, economic friction. In a smaller way, being able to use a digital identity infrastructure to establish and capitalize on circles of trust within your organization, and between your organization and its partners and customers, may very well shape the direction of its success.

Trust is an important and yet tricky topic. Ultimately, every authorization made using a digital identity infrastructure is dependent on trusting that an identity and its attributes are correct. At the same time, trust is a concept that humans understand implicitly but have difficulty capturing algorithmically. Various mechanisms for establishing trust in identity credentials are available. This chapter introduces the notion of trust and the methods used to achieve it, but details of how those technologies are used to build trust are saved until later chapters.

In a digital identity infrastructure, trust occurs in a variety of places. Here are some examples of trust:

• Trust that the identity credentials are held by the correct entity
• Trust that the system I'm talking to is the one I want to talk to
• Trust that my communication will be unaltered and private
• Trust that the access control policy is implemented consistently throughout the enterprise

When we create a policy about digital identity and the actions available to holders of particular identity credentials, we're setting out a collection of objectives based on the circumstances of the transactions involved, the business requirements, the degree of risk that the business is willing to bear in those circumstances, and the cost the business is willing to pay to reduce the risk to an acceptable level. These objectives drive the level of trust and the amount of evidence we need to collect to attain it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Is Trust?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Trust is a firm belief in the veracity, good faith, and honesty of another party, with respect to a transaction that involves some risk. For example, when you give your credit card to the waiter at a restaurant, you are expressing trust that the waiter will use the credit card to process a transaction that will pay for your meal. You expect that that transaction will be the only one processed and that the waiter won't steal the credit card number for some other purpose. The only time I've ever had my credit card number stolen was in a restaurant, and yet I still blithely hand my credit card over to any waiter who comes along. There is clearly risk, but I take it because I'm convinced that the risk is small. Most of us don't consciously think about the risk of using a credit card to pay for a meal; we evaluate the risk intuitively based on a variety of factors including our previous experience, the way the restaurant looks, and, perhaps most importantly, beliefs about the credit card company indemnifying us beyond a certain point.

There's no doubt that trust is linked to risk when we consider who we're willing to trust with what. I may trust a particular person to fix my car, but not to baby-sit my children. Trust is based not just on the entities involved in the transaction, but also on their roles and the particulars of the transaction.

Trust is something I grant to or withhold from others—they cannot hold it for me. I can adjust it or revoke it completely, at any time. This leads to some important trust properties.

• Trust is transitive only in very specific circumstances. For example, if Alice trusts Bob's taste in music and Bob trusted Carol to select songs for the last party, Alice may be willing to trust Carol to pick the songs for her party.
• Trust cannot be shared. If Alice trusts Bob and Alice trusts Carol, it doesn't necessarily follow that Bob trusts Carol.
• Trust is not symmetric. Just because you trust me, doesn't mean that I trust you.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Trust and Evidence

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One day I went to the store to buy a disposable camera for my son to take to an activity. As I stood before the display rack, I pondered which of several choices I should buy. One bore the brand of a reputable company with a strong reputation in the world of photography. The other camera bore the house brand of the store I was at. The house-branded camera was $1 cheaper than the camera with the national brand. I bought the more expensive camera, even though they may have actually been manufactured in the same facility on the same day. Why? Because the brand was evidence that I could trust that the camera would work and the film would be good quality. The $1 extra that this evidence cost me seemed a reasonable trade-off to avoid the risk of missing the shots.

Just as in the physical world, trust in a digital identity is ultimately based on some set of evidence. For example, when you log into your computer, you present an identity in the form of a user ID and evidence that you are the person to whom that ID refers by typing in a password. The password is evidence that the computer should trust that you are who you say you are.

Sometimes the evidence for trust in a computer-based transaction is explicit and automatically collected as in our password example. At other times, the evidence is present but less visible than in physical situations. For example, when I conduct an electronic transaction at http://Amazon.com, their digital certificate presents evidence to my browser that I'm really dealing with http://Amazon.com and not an imposter just trying to steal my credit card number. While this happens automatically, few people pay much attention to the trust marks that the browser presents (such as the little padlock indicating a secure transaction) and fewer still ever ask to see the details that their browser hides from view. The recent increase in phishing scams, where criminals pose as a legitimate online business in order to steal identity information, is evidence of this.

Passwords, digital certificates, biometrics, and the like are all examples of evidence that can be presented to show authenticity for a particular set of digital identity credentials. discusses the collection, use, and relative merits of the various types of credential evidence used with digital identities. Other systems for recording and measuring trust will be discussed at other locations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Trust and Risk

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Trust can be difficult to quantify. Do I trust Alice more than Bob? Why? Unfortunately, when evaluating the effectiveness of identity policies, we need to be able to quantify the trustworthiness of a system, method, or technique. Fortunately, we don't ultimately have to measure our trust in a system or approach; rather, we can try to quantify the risk of a particular business process and balance that risk with the expected rewards or returns. Businesses have been analyzing risk for years.

Analyzed in this way, for each business process, we have to be able to give a measure of the risk that the digital identity infrastructure will fail to perform as required for that particular business process. To answer these questions, we need to have a detailed understanding of the systems and processes that make up the digital identity infrastructure, including detailed assessments of the required interactions with partners and their ability to perform as required. Further, we have to quantify the potential losses and their probabilities.

Often, for processes that have been in place for some time, we can use historical measurements to determine the expected level of risk. This assumes that the processes used to manage the digital identity infrastructure include system and outcome monitoring and tracking.

The level of detail available for these analyses will depend on the maturity of our identity infrastructure, a topic we will return to in .

One way to manage risk is with service level agreements, or SLAs. SLAs are nothing more than contracts that set expectations around what you are promising and what the consequences will be of failing to deliver. A complete discussion of SLAs and risk management is beyond the scope of this book, but should play a part in your digital identity strategy.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Reputation and Trust Communities

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I just bought a cell phone cover on eBay from someone in Hong Kong. Normally, I'd consider an international purchase pretty risky. But eBay provides a means for me to gain trust in someone living in Hong Kong. The trust is based on feedback from other eBay users. Each time an eBay seller completes a transaction, the buyer can rate the seller on a number of different points. When I bought my cell phone cover, I was able to review the seller's history on eBay and determine that other buyers were happy with their interactions with this seller. In the same way, sellers can see a buyer's reputation to determine if the buyer is trustworthy and therefore likely to complete the transaction. eBay's feedback system creates a social network wherein reputation can flourish. This social network aggregates the reputations of eBay buyers and sellers into a community of trust.

In that way, eBay is like a village where trustworthiness is based on one's reputation. First-time sellers, like strangers in the village, have no reputation and are thus viewed with suspicion. Over time, this changes for better or worse depending on the actions of the person. On eBay, identities, rather than people, gain a reputation over time, and that reputation can be used to judge a particular buyer or seller.

eBay, of course, is not the only example of a system where this kind of trust community has developed. MSN Messenger, for example, serves as the infrastructure that supports a community for securities traders. Over the course of time, individual traders, identified by the MSN Messenger ID, build a reputation based on what they say and do.

Similarly, over time, people build up trust in the email addresses of people with whom they've interacted. Unfortunately, as we've seen, the lack of credible authentication for those identities makes them subject to exploitation by email worms and viruses.

Given that communities of trust are so important to trustworthy interactions, we might ask how they are constructed. As illustrated in , a community of trust has five components:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Conclusion

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We can create digital identities all day long, but they are worthless without authority. As we've seen, authority is established on the basis of trust, but trust is hard to measure. In building digital identity infrastructures, remember that you're attempting to establish a community of trust, even if trust is never mentioned.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Privacy and Identity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Several years ago, General Motors set out to create a company-wide telephone directory. Of course, in the 21st century you don't create a printed phone directory for a company as large as GM; you create an online directory. Two years and numerous legal hurdles later, GM had an online phone directory. This tale is amazing, given that GM wasn't trying to do anything particularly difficult, like aggregate identity pools or implement single sign-on company wide. They were simply creating a phone directory; something companies have been doing for a hundred years.

GM's hang-up was not the technology, but rather the legal challenges presented by differing privacy laws and regulations in each of the many countries where GM has employees. European privacy laws are much stricter than those in the United States. Privacy turned a seemingly simple project into a two-year ordeal.

More and more corporations and government agencies are appointing Chief Privacy Officers, high-level officials whose job is to ensure that identity data is protected. The reason is simple: privacy is a big deal. People believe that their identity data should be private. They don't necessarily believe that everyone else's data should be private, but they want to protect their own identities.

RFID stands for "radio frequency identification device." RFID tags are small integrated circuits that broadcast an identifying code whenever they're hit with radio frequency radiation. The circuit uses the radiation to charge a small capacitor that gives the tag just enough energy to broadcast the identifying code. RFID tags have been used to automate the collection of tolls or access to parking garages.

One of the really interesting uses of RFID tags is to identify things. This has generated significant interest in the retail industry. Imagine if the barcodes on the groceries you buy could talk. Rather than having to scan the items one at a time, the RFID reader could ask all the items in the grocery cart to identify themselves and total up the purchase all at once. An RFID reader in a refrigerator could keep track of what's in the fridge and build your grocery list for you. Smart shirts could tell your dryer how high to set the temperature.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Who's Afraid of RFID?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

RFID stands for "radio frequency identification device." RFID tags are small integrated circuits that broadcast an identifying code whenever they're hit with radio frequency radiation. The circuit uses the radiation to charge a small capacitor that gives the tag just enough energy to broadcast the identifying code. RFID tags have been used to automate the collection of tolls or access to parking garages.

One of the really interesting uses of RFID tags is to identify things. This has generated significant interest in the retail industry. Imagine if the barcodes on the groceries you buy could talk. Rather than having to scan the items one at a time, the RFID reader could ask all the items in the grocery cart to identify themselves and total up the purchase all at once. An RFID reader in a refrigerator could keep track of what's in the fridge and build your grocery list for you. Smart shirts could tell your dryer how high to set the temperature.

Against this backdrop of a consumer Utopia is an Orwellian nightmare of massive intrusions into individual privacy. Who else gets the data from your grocery purchase? When you wear your Gap shirt into Eddie Bauer, do they scan it to know what kinds of clothing to offer you? In general, who else can scan the tags in the things you own?

This debate has created lots of heat over the last few years. Gillette planned a pilot with RFID-enabled shelf displays that would automatically send restocking alerts to the company when a display ran low. They were forced to abandon the pilot because of concerns by privacy advocates. Wal-Mart has led a push for RFID in retail, but so far has limited the roll-out to pallet-level packaging in the supply chain. Part of this is pragmatic: RFID tags are not yet cheap enough to put on everything.

The debate over RFID and privacy highlights a crucial aspect of privacy. People are scared of the theoretical threats to their privacy—especially in technologies they don't understand. At the theoretical stage, privacy advocates are very effective at using this ignorance as a backdrop for painting draconian pictures.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Privacy Pragmatism

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The debate over RFID illustrates the great irony of privacy. As someone who's been involved in online commerce and services for over a decade, I've found that while everyone cares about privacy in the abstract, they're usually willing to trade their personal data for the most trivial of benefits. A cynic would say that this is because people don't really understand digital identity and how their privacy can be eroded, but I think that most people make rational choices. People willingly choose to share personal data if there is a payoff that they understand.

Here's an example: if you've been to a grocery store, you're familiar with their "preferred customer" cards. The premise is simple: scan the card, get a discount. Groceries stores do this, of course, so that they can tie customer identities to purchasing habits—very valuable data for a company looking to drive sales and establish loyalty. Even the most hardened privacy warriors are likely to succumb to a large rebate offer on a TV or a computer and send in the rebate form in order to capture the savings.

While the U.S. has its share of privacy advocates, it has been slow to adopt many of the privacy safeguards that have found a home in Europe and elsewhere (the next section will explore the exceptions). The hesitancy has been partly based on free speech concerns, but often, it is because U.S. legislatures are loath to take action that will have negative impact on business development. Again, the cynic would say that business has bought off the legislative process, but from my experience, both in the private and public sectors, the reason has more to do with legislative concern about regulatory burdens making U.S. industry less competitive.

Even with the pragmatic attitudes of consumers and the business-friendly climate promoted by many legislatures, your organization should be very careful in handling the personal data of employees and customers and the private information of partners and suppliers. While it's true that customers are usually willing to trade identity information for some benefit, they react with anger when they feel like they've had their identity data "stolen." Likewise, legislatures sometimes react with ill-conceived legislation when pressed by anecdotes regarding identity theft, fraud, and misbehaving companies.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Privacy Drivers

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Even with the relatively pragmatic attitude of most U.S. consumers regarding privacy, there are still many significant laws and regulations affecting organizations. shows some of the more prominent laws and regulation concerning privacy. In the U.S. and Canada, those laws tend to be limited to specific kinds of organizations (e.g., health care and financial services), but the European Union directive (the one that tripped up GM in its efforts to build an employee phone directory) is extremely far reaching.

Table 4-1: Some privacy laws and regulations

Law/regulation	Description
Canadian Personal Information Protections and Electronic Documents Act	Applies to employees of firms regulated by the federal government. Recognizes an employee's right to privacy and imposes principles that employers must follow with respect to the personal data of their employees.
Customer Identification Program (Patriot Act)	Applies to financial services organizations in the U.S. Requires the collection and storage of customer data and its verification against government-owned lists of known or suspected terrorists.
European Data Protection Directive	Applies to organizations operating in the European Union. Imposes wide-ranging obligations regarding the collection, storage, and use of personal information relating to employees and customers.
Health Information Portability and Accountability Act (HIPAA)	Applies to any organization that manages health care data in the U.S. Establishes a patient's right to control access and use of personal health information (PHI). Requires that organizations control and safeguard PHI. Imposes technical standards for access control, audit, data integrity, and security.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Privacy Audits

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Chief Privacy Officers and others concerned with privacy in an organization worry about what they don't know. It's not the data you know about that will get you in trouble. In , we'll discuss resource mapping and specifically talk about how to create inventories of the data in your organization. Having these data maps is the first step to being able to perform privacy audits . Here are some of the privacy-related questions you might ask about the identity data in your organization:

• What kinds of identity data are you collecting?
• How is this identity data collected?
• Why was the identity data collected?
• Were special conditions on its use established at any time?
• Who is the data owner?
• Who is the custodian?
• Who uses the data, why, and how do they usually access it (i.e., remotely, via the Web, from home)?
• Where is it stored?
• Is any of the data stored on devices that are routinely transported off-site such as a laptop or PDA?
• Are there backups? If so, you need to answer these same questions about the backups.
• Are there access logs for the data?
• Where are the logs stored?
• Are the logs protected?
• What other security measures (firewalls, intrusion detection systems, and so on) are used to protect the data?

Conducting privacy audits and collecting all of this information may seem like a lot of work, but ask yourself what it means if you don't know the answers to these questions. There's good news and bad news. The good news is that data maps are useful for more than just privacy, so you can balance the cost and effort with other benefits. The bad news is that it's hard to get anyone very excited about data. Applications are the stars of the IT world. In , we'll cover a strategy for moving your organization toward having a better understanding of what data it owns and getting answers to the preceding list of questions.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Privacy Policy Capitalism

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When we view the exchange of identity information through the lens of a transaction where the customer perceives some benefit and thus parts with bits of identifying information in consideration for that benefit, privacy policies take on a new feel. Many companies view their privacy policy as something they have to do to keep their customers from being angry with them, because their industry demands it, or because someone convinced the CEO or CIO that she'd be liable if the company didn't have one. All of these may be true statements, but they're only ancillary to the real reason for a privacy policy: your privacy policy represents the terms of service you're offering for whatever benefit the customer perceives.

For example, say you're an online merchant. You collect identity information from your customers at various stages of the transactions, and the customer receives some benefit. At the most basic level, whenever a customer visits, you install a cookie on his browser so that your shopping cart works. Cookies are a way of maintaining program state across HTTP, an otherwise stateless protocol. In addition to making the shopping cart work, you realize that you can use the cookie to recognize the customer the next time he returns and even to track his shopping habits. When the customer buys something, you collect personal information, such as his name, address, and credit card number, and can link that to the cookie as you create a customer profile.

What should this online merchant's privacy policy say? First, tell the truth. Tell customers what data you collect, why you collect it, and what you do with it. Be specific. In this example, the merchant might say, in part:

• We use cookies. Our shopping cart will not work without them.
• When you make a purchase, your personal information is stored in our system only if you give us permission by clicking the "Save my information" box on the checkout form. When you do this, we can serve you better by automatically filling out some forms for you when you shop.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Anonymity and Pseudonymity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the questions that your business should understand clearly is what level of identity is needed for which relationships. For many purposes, you need specific, authenticated, and detailed identity information from your partners, suppliers, and employees. You may be able to provide service to customers, however, as they remain anonymous or at least pseudonymous.

True anonymity is not realistic for most online services, since they probably have to at least maintain some kind of user state and that requires telling which individual HTTP requests are related. Consequently, the user is not anonymous, because you can distinguish between different users. This leads to the concept of pseudonymity .

In a pseudonymous system, users are uniquely identified, but other identifying information is not shared. Pseudonymous systems give subjects a unique ID with which attributes, rights, and privileges can be associated. Pseudonymity is a term usually reserved for people, since the unique ID and its associated attributes, rights, and privileges constitute an identity as we've defined it. Pseudonymity implies that this identity cannot be tied to other identities that the subject might have without the subject divulging the connection.

Businesses should ask, "What identifying information is required?" early in the design process for an online service. I say "businesses" because this is almost always a business decision, not a technology decision. In keeping with our concept of the privacy policy being a term sheet for an identity transaction, each piece of the customer's identity that is being requested should also be associated with the need for the data as well as the benefit that the customer will receive by giving the data.

This rule is not followed as often as it should be. You've probably been to web forms that ask you for more data than you think the company needs to provide the service. You probably resented it. Adding insult to injury, it's likely that the company collecting the data never made any use of it whatsoever, whether for your benefit or not. Collecting unnecessary data alienate