Confused by the title of this post? Not to worry, it will become clear.
As a long term believer that individuals should have the capability to manage their own data, I was delighted to see the recent white paper from Microsoft entitled ‘Decentralized Identity – Own and Control Your Identity'
That paper builds on the work of many over the years, and specifically leverages an emerging W3C standard.
Why does this matter? Because ‘big tech’ has finally validated the concept that individuals should be able to manage and use their own identity and data.
As a result, this can now be discussed much more easily within large corporates and the public sector.
It is an idea whose time has come. There are two reasons for that:
The current model has reached the limits of its ability to scale – people have too many suppliers, too many user names and passwords, too many connected things, too many trackers, too many unread privacy policies; too many meaningless/ dangerous checkboxes, too many data breaches, and too many regulations.
The decentralized model offers new capabilities, and big wins for all parties. Benefits ascribed to this model in the Microsoft white paper are:
For everyone (individuals)
- Enable all users to own and control their identity
- Deliver secure experiences that incorporate Privacy by Design
- Design apps and services with users at the centre
- Deliver personalised experiences while respecting user privacy
- Market apps where creators and consumers exchange data directly
- Build true serverless apps that let users store data locally
- Engage with users while minimising privacy and security risks
- Transact with customers, partners and suppliers over a unified protocol
- Improve transparency and auditability of your business operations
That’s a compelling set of benefits, particularly in light of the growing negative perceptions of ‘surveillance capitalism’ now ubiquitous on the Internet.
So how might decentralised identifiers emerge into mainstream, and what’s with the weird blog title, anyway?
Firstly, decentralised identifiers will soon be seen in the same way as BYOD (Bring Your Own Device). Ten years ago it was not the norm for people to bring their personal tech to use in the workplace. That has changed completely. There was no big bang, just a gradual change in attitude within corporate IT. Developers recognised the need for personal devices to be able to play nicely and safely with corporate requirements, without significantly changing the user experience, and began building a new generation of apps.
So, I contend that BYOI (Bring Your Own Identifier) will work the same way – no big bang, just a gradual use case by use case, system by system switch on of a new, optional capability. As with BYOD there will be a spectrum from early adopters prepared to take the risk and reap early rewards, all the way through to laggards who have yet to entertain the concept.
In system terms, early candidates to connect to BYOI initiatives would be:
HR Systems (Human Resources)
There is clear logic in an individual being able to present their own useful, usable identifier to the HR system. Doing so would provide the individual with some very important and useful employment-related data that typically they have had to re-create for themselves, or do without, up until now. This would enable the corporate HR system to much more easily meet its various compliance obligations, not least GDPR and similar. I would also contend that once there is the ability to blend both an individual’s and employer’s data-sets and share that in very fine-grained, permissioned ways, that we’d see an explosion of opportunity in that space. Think LinkedIn on steroids.
CRM Systems (and their relatives in E-commerce)
Marketers and CRM managers have long understood and used the concept of customer identifiers (and the often related product/ service identifiers). For good and not-so-good purposes, their use is boiled in to pretty much every CRM system and customer engagement process from prospecting, through customer onboarding, operational service delivery, customer service, compliance data management reporting. In fact, in CRM systems there can be many separate customer identifiers used for different reasons, most typically to integrate with another system to read, write data or edit data that is used in CRM processes. So another identifier that happens to be brought to the party by the customer/ prospect themselves is just business as usual from the technical perspective. But real change will emerge not because there is a new identifier, but because it brings with it the possibility of much improved, trustworthy and inherently compliant data sharing relationships.
So where does ‘CX Max’ come in and what does it mean for each of the parties?
CX is short for Customer Experience. It is the recent layer on top of CRM. Most large organisations have customer experience programmes designed to optimise each of their interactions between customer and supplier. That’s fine so far as it goes, but the giant elephant in the room is that organisations can only optimise CX within their own silo, or at best, their immediate sphere of influence (e.g. a close partner network). But a significant proportion of the things that individuals are trying to get done necessitate working across multiple organisations.
The actual customer experience can only be improved by working across silos, not just within them.
In practice, what does this mean, and how will it work? Here's how. In the decentralised identity model, the individual won’t just come with a string of numbers and letters. They will ultimately come with tools and agents on their side that help them get stuff done.
The individual equivalent of a CRM system might best be seen as a Supplier Relationship Management (SRM) system. Although that is not likely the term that will stick on the individual side; the underlying tasks supported are relationship management between an individual and various suppliers, products, services, and all of the data sharing that surrounds them.
Whilst that terminology has yet to solidify, it might be helpful to think of the individual having a digital wallet that holds data, or links to data. In addition to the data and links, the wallet holds keys to data that can be handed to whomever the individual wishes to enable to read, write, edit or delete data in their wallet.
In practice, the keys are the decentralised identifiers.
If we look beyond the metaphor of the individual having a ‘wallet’ to the individual having an ‘agent’; the difference might be become clear as the agent is a more active concept. The individuals’ agent might be running workflow, decision support or even artificial intelligence – the critical point being that all of this works on behalf of the individual under their control.
So what might that mean over the next few months and years? The visual below shows a record in a standard CRM system (in this case, Salesforce), which has been connected to an individual using the JLINC Protocol. In practice this means the individual is bringing a decentralized identifier and related data to the relationship; the organization is providing a decentralized identifier and related data to the individual and the individual’s agent is establishing and maintaining a trusted data pipe between the two.
Critically, this relationship and the data that moves backwards and forwards within it are governed by an information sharing agreement that both parties understand, sign and hold. To make that even more meaningful, a full audit trail of every data transaction is also retained by both parties.
This enables the good aspects of CRM whilst minimizing the downsides. That is to say, both parties benefit considerably when the right data is able to flow to and from the right parties, at the right time, for use in the right process. Just as importantly, data does not flow from or to places where it should not, for use in processes that are not positive for both parties.
- Individuals should be able to make their buying interests visible to a range of suppliers around a specific product/ service need.
- Organisations should be able to write data to the personal data services of their customers efficiently and securely, and in doing so add value to the overall relationship.
- Intermediaries or other third parties can access accurate, verified data from either or both parties in order to run value-adding services; e.g. ‘aggregate my data with that of others, run AI/ decision support across the combined data-set, and then give me back the recommendations specific to me’.
The above is certainly not the case in the current model, which is charcterised more by over-sharing (through general surveillance and related guesswork), which leads to lack of trust, and, in turn, less specific data being shared than would be the case in a more trustworthy relationship.
While it may be too early to know how decentralized identity will pan out in the long term, we can say with certainty that the current model is going to run out of steam if it has not done so already; and that letting individuals be both the point of integration and point of origination for data about themselves is an architecture that can scale.
JLINC Labs has deployed the decentralized identifier DID-spec in both our core personal data management platform, and in our Salesforce Contact app that now integrates decentralized identity with the world's largest CRM platform.
Through 2019 we intend to run a pilot programme with one participant per vertical industry sector that has an interest in selling to and directly connecting with individuals.
To find out more or discuss participating contact info at jlinclabs.com