i-data-recovery.com

What is Digital Identity Lifecycle?

Provisioning

Provisioning is the process of preparing an IT system to provide service to a client, customer, or other user. From the perspective of digital identity, provisioning is the creation of the identity record and its population with the correct attributes. These attributes might be standard items, such as name, location, email, and phone, as well as items more specific to the system. For example, the identity system that feeds the custom page presentation system for My Yahoo! contains attributes such as page color, positioning, and so on.

Provisioning can be done through the action of an administrator, or it can be self-service, occurring as a result of user actions. When a new employee joins a company, administrators, usually on multiple systems, provision identities for that employee so that she can be assigned an office, get on the payroll, get a computer, get a badge, become part of the health plan, and so on. One of the trends in enterprise computing has been termed “zero-day start,” meaning that the enterprise links all of these systems so that when a new employee starts, all of the systems, permissions, and infrastructure are set up and ready, allowing the employee to start work the first day and have access to all of the resources, physical and virtual, that she needs to be productive.

We’re all familiar with self-service provisioningwe see it every day on the Web as we visit web sites and sign up for services, both paid and free. For example, I’ve had a virtual server account with Verio for six years, and I’ve never talked to a human. I signed up online, and I manage the account entirely online. Self-service provisioning is a hallmark of the Internet age and perfect for services that are delivered over the network. Self-service provisioning works well where there is little need to verify credentials other than perhaps a credit card.

Propagating

Depending on the nature of the system on which the identity is created, the identity record may need to be propagated to other systems as part of its lifecycle. For simple systems, the propagation is as simple as writing the identity information to the filesystem or storing it in a local database. More complex systems may provide some sort of shared identity directory where the identity created in one place is used by multiple systems.

When I was CTO of iMall, we built a large e-commerce system that allowed small merchants to sign up for an account and then create a full-service online store. The system had a self-service account management system that allowed merchants to provision an account. Once the account was created, the identity information was propagated so that the system could create directories and files on numerous systems, add records to databases on other systems, and even establish a merchant banking account through an outside partner. This propagation of identity information was critical to the overall functioning of the system.

Propagation must occur after each change to the identity records, and the propagation must happen reliably. Because not all of the systems interfacing with the identity infrastructure support the notion of transactions (atomicity across multiple independent actions), this can be a challenge. To see why, consider the example I gave in the last paragraph. Suppose you create an account and the system creates files and database records, only to discover that the customer’s payment has been declined. The system is in a state of partial completion, and backing out to a clean state is often nontrivial. The more actions involved in a single propagation, the more difficult this problem becomes. For such systems, the only alternative is to carefully think through compensating actions and when they should be applied.

Using

The use phase is probably the most obvious of all the phases in the lifecycle. Once the identity has been provisioned and propagated, the identity is used by various systems and agents. This might be as simple as consulting the identity to authenticate and authorize user actions against resources, or it could include more complicated actions, such as billing or payroll.

Maintaining

Regardless of the nature of the identity, the attributes will change from time to time, either because the base attributes of the entity change (e.g., a new home address) or because roles and assignments change. Often, to support new business opportunities, the schema of the identity record may need to be changed to add new fields to or include entirely new systems.

We’ve seen that identities are often about things other than people. In these cases, it’s possible that the entire entity referred to by the identity is changed. As an example, consider upgrading the departmental laser printer. The name and IP number for the printer may be the only attributes that remain the same. This same phenomenon occurs when people occupy positions with strong role-based identity (e.g., the on-call duty officer).

All of these actions result in changes to the identity that, after completion, must be repropagated to the affected systems.

Maintenance of identities is one of the most costly activities that an IT help desk deals with day to day. Users frequently lose or forget passwords to systems. They change roles or move. The more things users can do on their own, the more money the company can save in maintenance calls to the help desk. Password reset has become of one of the driving forces behind enterprise identity management systems for this very reason. Often, an identity management project can be justified on the basis of savings from building a self-service password system alone.

Maintaining

Regardless of the nature of the identity, the attributes will change from time to time, either because the base attributes of the entity change (e.g., a new home address) or because roles and assignments change. Often, to support new business opportunities, the schema of the identity record may need to be changed to add new fields to or include entirely new systems.

We’ve seen that identities are often about things other than people. In these cases, it’s possible that the entire entity referred to by the identity is changed. As an example, consider upgrading the departmental laser printer. The name and IP number for the printer may be the only attributes that remain the same. This same phenomenon occurs when people occupy positions with strong role-based identity (e.g., the on-call duty officer).

All of these actions result in changes to the identity that, after completion, must be repropagated to the affected systems.

Maintenance of identities is one of the most costly activities that an IT help desk deals with day to day. Users frequently lose or forget passwords to systems. They change roles or move. The more things users can do on their own, the more money the company can save in maintenance calls to the help desk. Password reset has become of one of the driving forces behind enterprise identity management systems for this very reason. Often, an identity management project can be justified on the basis of savings from building a self-service password system alone.

Tags: Digital Identity

Posted in Digital Identity, Information Security | No Comments »

Privacy and digital identity in digital world

You might be asking, what principles can I use to make sure I’m acting in good faith with respect to the personally identifying data of my employees, customers, and partners? The Canadian Personal Information Protections and Electronic Documents Act contain 10 principles that, if modified slightly, can serve as a guide:

Accountability

Your organization is responsible for the personal information under its control and must designate someone who is accountable for complying with these principles.

Identifying purposes

Any project must specify why it is collecting personal information at or before the time it does so.

Consent

The subject’s consent is required for the collection, use, or disclosure of personal information. Exceptions should be documented.

Limiting collection

Projects may collect only the personal information that’s necessary for the purpose they’ve identified, and must collect it by fair and lawful means.

Limiting use, disclosure, and retention

Unless a project has the consent of the subject, or is legally required to do otherwise, projects may use or disclose personal information only for the purposes for which they collected it, and they may retain it only as long as necessary for those purposes.

Accuracy

The subject’s personal information must be accurate, complete, and up to date.

Safeguards

Security safeguards must be employed to protect personal information.

Openness

The project must make its personal information policies and practices known to people from whom they collect information.

Individual access

Subjects must be able to access personal information about them, and be able to challenge the accuracy and completeness of it. Exceptions should be documented.

Challenging compliance

Subjects must be able to present a challenge about the project’s compliance with the privacy policy to the person that the organization has designated as accountable.

Even though these principles are not the law in the U.S., or even for most industries in Canada, they provide good guidance for how an organization can protect personally identifying information and be fair about the information they collect. If your organization ignores any of these principles, you should ensure that it does so by choice rather than accident and that the risks are thoroughly explored.

Privacy Pragmatism

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 habitsvery 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.

Privacy Audits

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. 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.

Privacy Policy Capitalism

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.
• We use cookies to track the shopping habits of our customers. This data is used to make our search tool better and to help us offer a better product selection. The shopping habits of our customers may be released to partners and suppliers in aggregate, but your individual shopping habits will be released to a third party only with your specific permission, obtained in advance.
• Advertisements appearing on our system may make use of third-party ad response tracking systems that use cookies to track ad click-through and to target those ads to specific customers.

A real privacy policy would be longer, and your lawyers will probably want to fill it with lots of other information. While it’s a good idea to involve lawyers in the process, since it’s ultimately a term sheet between you and your customers, make sure that the privacy policy is readable and understandable by your customers, or it won’t do what you need it to do: inform them in clear language the terms of the bargain that you’re proposing.

If you approach your privacy policy as a term sheet, with a clear understanding of what each side is giving and getting in the relationship, you and your customers will be happier with the result.

Tags: Digital Identity, Information Security

Posted in Digital Identity, Information Security | No Comments »

What is Digital Identity and how it roles?

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 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.

Identity Scenarios in the Physical World

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.

In later chapters, we’ll discuss these terms in detail and see how they apply in less-familiar scenarios.

Identity, Security, and Privacy

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.

Tags: Digital Identity

Posted in Digital Identity | No Comments »