Lately, I’ve been bothered by the word identity. Seems I run into it all the time in reference to identity management, identity resolution, contextual identity, digital identity and even identity theft.
Identity, or the idea of who we are and how we are defined, is an essential concept that has become increasingly important in our digital age. With this comes a great responsibility to protect customers’ personal information and build trust through secure data management and integration practices. In order to achieve this goal, companies must embrace multi factor authentication as an integral part of their security strategy.
Multi factor authentication (MFA) is an identity verification process that requires additional proof beyond usernames and passwords when logging into accounts or accessing sensitive information. It can consist of biometric identification methods such as fingerprint or facial recognition, or virtual tokens like one-time passcodes sent via text message. By layering these extra measures on top of traditional sign-in credentials, businesses can better safeguard their customer data from cyber criminals and other malicious actors.
Maybe it’s a bad case of cognitive dissonance, but there is a lot more dialogue on identity in blogs, conferences, webinars and such these days. And all of it is different, but not different as in different opinions. The conversations aren’t even the same, creating confusion around the whole topic, if not a full-blown digital identity crisis.
Identity appears to be a homonym and, as I will suggest, has another pronunciation. For this reason, we need to disambiguate identity before we can address, well, identity disambiguation, especially when it comes to customer data management and integration.
Here are four conversations on identity. All vary depending on the business circle where you hang out. Each conversation looks at identity from the perspective of three different entities: an account, a role, such as a customer or an employee, and a party, which is a person, an organization or a group.
Conversation #1: Identity equates to account log-on information.
In software, device and online security worlds, identity management basically refers to account log-on information. Multi-factor authentication, such as providing a username and password, is required to prove, verify and authorize access to, say, a software program, an online bank account, or a social networking site.
In this conversation identity management is all about access to account information and associated functionality, not necessarily to the related party’s profile. Consider LinkedIn, Netflix and any on-line bank.
LinkedIn sign-on information primarily enables access to account information and functionality to view, add, edit and delete account and profile data, link to other persons, and so forth. Ironically, name, location, connections and employment history – all seemingly classic elements of a person’s identity – are all out there for others to see.
Where a LinkedIn account corresponds to one person, a single Netflix account is linked to five parties who can simultaneously access and view a movie. Still, like in the case of LinkedIn, Netflix frames identity in terms of account access, not on the attributes of the members’ profiles. In fact, veronymity is not even a factor to have a profile on Netflix.
Banking is a bit more complex than LinkedIn and Netflix. Turns out a party can have multiple accounts, and an account can be related to multiple parties. But again, the focus of identity is largely on account access, not the account owner per se.
Conversation #2: Identity denotes a party’s appearance, behavior, emotions and thoughts.
In advertising and marketing, identity denotes a person’s, an organization’s, or a group’s appearance, behavior, emotions, thoughts and now even current location. Identity has nothing to do with securing access to an account. In this conversation, identity corresponds to a single party’s persona, not to an account.
Identity in the advertising and marketing world is important for segmentation and targeting. In fact, marketers group parties with “common identities” and sell them stuff using the same message.
Consider LinkedIn again, but this time from the perspective of recruitment advertisers. They see a LinkedIn member’s profile, not the account, as the locus of a person’s identity and search out people with particular educational backgrounds and employment experiences.
Advertisers and marketers, however, are discovering that a single party can have multiple “engagement personas” or contextual identities, described in terms of a party’s different roles in transactions and interactions. (Updated 04/26/2017) Contextual identity suggests there is no such thing as a single canonical identity; a party can have more than one engagement persona. (Updated 04/26/2017)
On a final note, as the resolution of personal data increases, some identity data in this conversation may cause privacy concerns. With the arrival of Big Data, we can derive sensitive information from other, seemingly innocuous data, exposing aspects of identity most would prefer hidden.
Conversation #3: Identity designates a single, unique party entity.
The third spin on identity speaks to representing persons, organizations or groups as single, unique entities in a business system, independent of their contextual identity and accounts. The goal is to facilitate data management and integration in terms of all parties, not just those parties designated “customer”.
“Customer” is only one engagement persona attributed to a party in a transaction or interaction. (Updated 04/26/2017) In numerous real-world instances a transaction or interaction involves multiple parties with different engagement personas. (Updated 04/26/2017) Sometimes a party has multiple roles in different transactions and interactions. For these distinct roles and transactions, a party may have separate accounts.
Consider, for example, an enterprise software vendor that has interactions and transactions with a business party in both “partner” and “customer” roles. For each role, the business party requires different profiling data attributes, data relationships and connections to other parties. The business party will likely also have a separate account for each role.
As a partner, the business party may resell, install and implement the software firm’s products. As a customer, they actually use the software firm’s products in their own business. The nature of the transactions and interactions between the software firm and the business party differs for each role.
Ideally, the software firm wants to uniquely represent the business party as a single entity having two roles – partner and customer – with corresponding accounts and transactions. Why? So they can get a full panoramic view of all account transactions and interactions with the business party in all their roles.
For the purpose of this conversation, we might even consider changing the pronunciation of identity to “i•d•en•ti•ty”, or maybe hyphenate the word so we get id-entity. The emphasis is on uniquely designating a person, an organization or a group as a single party entity. Only then can we establish valid connections to related data, roles, accounts and other parties, especially when this information is scattered across multiple systems.
Currently, the challenge is with CRM and MDM systems. Most enterprise software vendors mistake accounts for parties and incorrectly use role data to “id-entity”. Contact points such as locations, phone numbers and email addresses are a good example. These tend to vary by role, particularly when the party is a person. We should associate contact points with roles, not persons.
The only chunk of data that all roles and accounts should have in common is data to singly and uniquely designate a party entity. Data to “id-entity” has to be exactly the same regardless of the party’s roles or accounts. Ultimately, singularly representing a unique person, organization or group, excluding role and account data is a requirement for integrating data across siloed systems and avoiding context collapse.
Conversation #4: A party’s online reputation is an identity matter.
I present a fourth conversation only to further emphasize how identity is a source of confusion. Another manifestation of identity concerns a person’s online reputation. In fact, an entire application area is building around the need for people to manage their online reputations.
As noted in Wired Magazine (August 2009), “The platforms that will become the centrepiece (sic) of online reputation are the ones that create some kind of meaningful relationships, and carry the data on defining who you really are as a person.” This generically speaks to identity and how reputation data is used to make inferences about a person, an organization or a group. I would argue, however, that even a party’s reputation could vary by contextual identity.
In Conclusion
For centuries, philosophers have contemplated the nature of identity. Our identity is hard to express as proven by the variety of conversations on identity in business circles. When discussing identity we have to clearly recognize which conversation we are having and ask: “Are we coming from the standpoint of an account, a role or a party?”
When seeking to visualize data about a party with different personas, whether ‘customer’ or some other role, in different transactions and interactions, we should think of identity as a verb and pronounce it – “id-entity”. Doing this improves understanding how to integrate data across siloed systems, particularly when a person, organization or group has different roles during different transactions and interactions.
