Incentives in Centralized and Decentralized Identity Systems
by Rainer Hörbe
In an ideal Internet users would freely roam the prairies of abundant services, where interactions would be secure and privacy-preserving by default. Parties would know about each other whatever is necessary for the particular exchange without any hassle and burden for registration and management of multiple keys, tokens and passwords. Given the status quo, another great philosopher has yet to come, to write a manifesto that will lay foundation for a Classless Internet Society, where private property of identity, data and services has been transferred to common ownership, and enlightened leaders (“the party”) will manage the migration to the desired state.
Let us turn to the real Internet. Communism has failed, and the Internet reflects that our society is governed by markets, and the regulations to protect markets. Identity ecosystems as part of the Internet are subjected to these mechanisms, and taking an economic perspective can help to understand how identity systems work, or do not work.
Application Providers, from certain view points congruent with Service Providers (SP), need to know some data about users. However, the popularity of an application is spoiled by significant drop-off rates during registration and authentication. First, this is to the disadvantage of users, who might fall back to lesser means such as email or messengers mounted on horseback, and second to SPs, who lack the user base to nurture their offering. Therefore the reuse of registered identities and authentication vehicles across applications has been identified as a remedy to siloed identity and access management at least since the introduction of RACF on IBM mainframes in the 1970s. Although we could argue that the use of the lettera di cambio in 13th century Italy would qualify as a bearer token, being an artifact of delegated identity and privilege management.
While X.5xx, PKI, MS Passport, Liberty Alliance, public eID and social logins promised to make electronic identities universally interoperable, the world of on-line identity is by and large still in a suck state, with pessimists claiming that the growth of silo-identities outpaces that of interoperable ones.
The motivation to improve identity interoperability is with stakeholders expecting direct benefits. These are primarily users and non-dominant SPs, then everybody else who might see a profit like governments willing to advance the local economy, IT-vendors and Identity Providers. On the other hand SPs dominant in their respective niche have little incentive to cooperate, neither for potential competitors to catch up nor for spending resources on a topic that is not their core business. One exception are use cases where organizations need to provision their users in a consistent way across internal and external resources for regulatory compliance and to reduce the administrative effort.
The primary lever to change the state lies with SPs. Users, although affected, are neither organized nor appropriately represented. Most users perceive identity, security and privacy as an afterthought to their actual goal in online-applications. Reusing a single password across many sites is still the #1 identity technique for a majority of users, based on surveys, breach analysis and anecdotal evidence[1]. Even if users claim to be concerned about threats from the Internet, it does not translate into conclusive action. Therefore, user centricity in projects and operations has a similar status as mission statements on a poster in the meeting room with a soaring eagle.
While the primary drivers of identity interoperability are SPs, the key question is how collaboration between the stakeholders can be pulled off. Collaboration patterns vary between centralized and decentralized. On the centralized side we find supply chains, eID systems and social platforms, on the decentralized side Self-Sovereign Identity (nascent) or InfoCards (R.I.P.). Federations are in-between, frequently by having member representation on a federation’s governance board. The fundamental ingredient to a successful collaboration is an incentive scheme for all required stakeholders. The research in blockchains (the variety with a token economy) has raised awareness that the mechanism design is key for a successful system that wants actors to contribute to a system or use its resources, and to make it expensive for adversaries to exploit it.
Centralized systems are limited by the design that is dominated by the platform owner. The functionality is optimized for the owner’s use cases. For example, social networks are highly scalable, but do not offer any reasonable KYC or account recovery. On the other hand, government eID-system have more polished provisioning processes, but generally lack the focus on private-sector uses cases, because government usually have no mandate to intervene in commercial activities.
User-centric or fully decentralized identity systems have not taken off yet, and I doubt they will for several reasons. First, convenience dwarfs security and privacy risks. There is the lack of interest, attention and follow-up action of the vast majority of users. Second, identity data is about relationships and not ownership. Relying on the term “controller” as opposed to “owner” was a major insight when DP-legislation was developed in the 1970ies, and it still applies. SPs have a valid need to know certain user attributes. Almost any online interaction with properly minimized data and purpose limitation will either require the release of user attributes or deny the service. The exception to the rule is when users pay with their data for content or service. There are still areas to be improved (like getting rid of stupid consent, restrict the collection of metadata), but in general data protection regulation does limit the user’s exposure, except the spotty regulation in the U.S. Third, I doubt that economic incentives will support effective decentralization, but rather lead to a concentration of identity services and trust issuers.
Federated systems feature a certain degree of decentralization, as they are operated by autonomous organizations. While some federations have been groomed to relay millions of users to thousands of services, they have not had revolutionary break-through. A universal identity system is bound to fail, because trust in identity is contextual. But more specific systems that provide a defined service to SPs with comparable requirements should be able proliferate in their respective area, if a model offers a useful and affordable service that is beneficial to all stakeholders that are required to participate.
The analysis of incentive structures using value chains is helpful to align motivations and actions in a system. It can help to distribute the benefits, risk and cost of a federation to all actors. The goal should be that the subjective benefit is significantly more than the status quo or the perceived risk and cost, because a cooperation with a minor benefit will have a hard time to compete against a local optimum, and priorities in core business processes.
In a general value chain analysis the focal point is on the value that each process contributes to a product or service delivered to a customer. While its primary use is for cost optimization, it can also be used to distribute incentives and risk. The tool can be expanded to a cross-organizational view, also called value system. While a full analysis with the cost, quality and compliance factors is costly, the basic concept of tracing a the value stream through an organizational structure may provide insights into the viability of a concept, and potential bottlenecks.
To get started with value chains, it might help to take the original schema from Michael Porter and apply it to an Internet company. Figure 4 in “Amazon.con’s Digital Strategies Amazon.com Case Study” [2] does this for Amazon.com. It depicts the contribution of primary and supporting processes to the generation of value for Amazon’s customers. In this schema Identity Management is just one of many support activities. However, we want to apply value chains to model identity systems, in particular federations. This requires to converge on Identity and Access Management as a stand-alone value chain, that is part of a larger system.
How can customer value be assessed? As argued above, users have little participation in decisions about identity systems, hence customer value must be searched somewhere else. The alternative approach proposed here is to distribute the value creation across the system such as in the example below representing a simple IDP/SP system:
| Enrollment | Provisioning | IAM | IAMG | Policy Enforcement | App-Providing | Value/Risk/Cost |
| Undesirable in this context | User data monetization | |||||
| +++ | Reduced registration drop-off | |||||
| + | Improved UX | |||||
| + | Better service discovery | |||||
| ++ | Improved privacy compliance | |||||
| ++ | Improved KYC compliance | |||||
| — | IDP liability for incorrect user data | |||||
| – | IDP liability for privacy breach | |||||
| + | Reduced user data set | |||||
| – | SP dependency on IDP availability | |||||
| – | Drop-out of federation | |||||
| + | + | Service for own constituency, employees, .. | ||||
(The scoring in the example is random and has to be decided case-by-case.)
When analyzing a value chain for identity federations, the structure should recognize both organizations and entities within organizations, such as IT-departments. Cost and risk can be included and viewed as negative values.
The values for the system under discussion need to be recognized and attributed to the specific actors and stakeholders. Vendors of IAM-systems have a list of benefits, such as reduced authorization cost (passwords), lower drop-off rate on application sign-on, improved compliance etc. It is then important to relate these gains to the identified actors.
The valuation should rather not be done in currency units, but rather as intelligent human guessing to allow comparing apples with oranges. A simple approach taken from the group moderation technique is to ask a group of affected people to assign points to each benefit from a limited set of points per member. This is a replacement for a real market that can inform prices, but unless somebody invents a blockchain with an identity coin that could really work, a market simulation is the second best approach.
The approach described above can be used as a modeling tool, or in group meetings to support the analysis process for federated identity systems. The outcome can be used as a baseline to agree on cost and risk sharing in a federation.
References
[1]https:/xkcd.com/792 [2] Bahadir M. Kandermirli, AMAZON.COM’S DIGITAL STRATEGIES, 2018. https://www.researchgate.net/publication/326132044_AMAZONCOM%27S_DIGITAL_STRATEGIES_AMAZONCOM_CASE_STUDY