The article spans across multiple areas, the agenda outline is below:
- Philosophical underpinnings of online identity. High level view of the evolution of digital identity centralized → federated → self-sovereign (user autonomy).
- A critique of the paymail protocol, its strengths and limitations
- Establish the need for a new naming protocol suite with a fundamental focus on user autonomy.
- An attempt to present dispassionate arguments without social bias
My recent article Digital communications in the Bitcoin era was an exploration of how Bitcoin could disrupt digital communications (unified) - instant messaging (IM), presence, voice (VoIP), voice conferencing, video conferencing, e-mail, desktop sharing, group chats, live streaming, private secure chat, etc. It enables an unified communications ecosystem which is user owned/controlled, gets rid of walled gardens, restores user privacy & consent, offers user mobility (portability), censorship resistant and helps speed-up innovation.
It briefed the different models for online/digital communication and their evolution i.e. Centralized -> Federated -> Self-Sovereign(user autonomy). It compared/contrasted them across the following aspects i.e. Identity, Data, Privacy, Mobility Rights(Portability), Access/Reach, Ownership & Consent, Price Negotiation & Contracts.
It envisioned a heterogeneous network of service providers that supplement the Bitcoin network, leveling the playing field for service providers and shifting the KPI from subscriber-base to actual services offered/through-put. The compounding of network effects leads to a win-win for both Bitcoin & unified communication network thus bringing down the walled gardens hegemonies of Whatsapp, WeChat, Zoom, Telegram, Signal, RingCentral, Vonage, Skype, Slack, Gmail, Outlook/Live, Discord etc.
In this article we are going to take a detailed look at Identity in particular. The next section is mostly excerpts from my earlier article.
The evolution of online identity, the different models are as below:
In this model, the platforms allow self-service account provisioning, typically users are able to choose own username and password, and some trivial configurations, but beyond that everything of value namely data & identity is owned and controlled by the platform. The users on such a system are restricted from freely transacting/communicating with the outside world, essentially forming a self-contained ecosystem of such users.
There is often no mobility rights (portability) and users are stuck on the platform even if it continues to stifle due to valuable legacy data. User could be banned without notice even if the so-called violation of T&C is subjective. Typically they use proprietary closed protocols, many even closely resembling open standards based protocol. These are essentially walled gardens which are interested in growing their user-base. e.g. Whatsapp, Skype, etc.
Federation allows different providers to inter-operate and hence users are free to choose the operator that best meets needs or can become their own provider too. There is no improvement to data and privacy in this model, as the provider still controls it. Also, portability is not seamless. E.g. Gmail provides a take-out service, but what good is it when your email ID's domain is still “@gmail.com”? Hosting on own domain comes at an additional cost, both for domain registration and the monthly email service fee and cannot be an afterthought. Still this is a step forward from the centralized model.
Even though email is still federated in theory and hence we should have a highly decentralized network of email service providers, the reality is very different. Market research shows the top 3 providers namely Gmail, Apple mail & Outlook control well over two thirds of the market. There are various reasons for it, reliability, user experience, cost, come to mind, but I posit the primary drivers are spam filtering & search. In fact spam is the number one reason that deters privacy conscious users from hosting their own email service.
The next stage in this evolution, takes us towards full user autonomy. It enables the concept of self-sovereign identity, where the user owns and controls his/her pseudonymous identity. Bitcoin blockchain can act as a host ledger for registering these identities, a user friendly handle like a SIP (or XMPP) URI, typically in “sip:user@host” (or FQDN) format, used to call or message another person. But the host/domain is not meant primarily to refer to federated service providers, as we are seeking to move from federated to self sovereign model. Yet there is value in host/domain for enterprise scenarios (say an employer issuing handles to nickb@employerdomain.com).
We will defer the concrete structure for such an URI to subsequent sections/articles. We can imagine users registering URIs/handles (for a nominal fee) that are independent and hence transferrable to various service providers not just seamlessly but even without needing human inputs/thought.
Unrestricted universal access to any user will finally be possible, as now handles/URIs are on the global Bitcoin network. Of course the data storage and privacy concerns will be met by storing encrypted data & metadata referenced from or directly on the Bitcoin blockchain and efficiently/economically retrievable via micro-transactions from specialized data storage services that will emerge in the ecosystem.
The real paradigm shift is brought about by how the various service providers are integrated with one another and also to client applications & the Bitcoin blockchain. In contrast to the federated model, here we design a loosely coupled network of service providers that interface with and supplement the Bitcoin network via micro-transactions & payment channels. These service providers specialize in their offerings and can cover the whole spectrum from alias/ID lookups, address generation, sender validation, contact book, communications, media services & a plethora of specialized offerings.
It creates a level playing field, where providers are not fighting for tightly bound subscriber-base market share anymore, and rather are equipping themselves for better service capacity/through-put and actually get paid on the real-time service metrics delivered.
The paymail protocol specification is very well documented and contains a number of interesting features. Its primary goal is to facilitate a user friendly payment destination (handles/aliases), via a network of paymail service providers that provide address generation (actually output script construction) function to sending clients. The paymail service providers are able to achieve this without needing the user’s private keys or wallet seeds with the xPub key derivation feature.
It has other much needed security and usability features too which have been very well designed, as below: ‘Sender Validation’, where the receivers paymail service in response to the request from a sender performs a PKI lookup against the sender to resolve their public key, this primarily prevents sender spoofing. Besides the receiver’s service verifies timestamp in the request to limit replay attacks, and also signs output script to prevent message tampering.
The ‘Receiver approval’ is another important feature that has been incorporated, and it involves an asynchronous flow owing to the user (human) input needed for accepting the potential incoming transaction. Since HTTP doesn’t allow provisional responses, a 202 accepted is used and a subsequent asynchronous independent HTTP callback request is issued to complete the call flow. The motive behind this use-case hasn’t been highlighted in the spec, but I believe (a) prevent money laundering by unsolicited deposits (b) a means to confirm the transaction details are accurate before its made.
They have also defined a ‘payto:’ protocol scheme, which is useful, not sure if its formally registered with IANA yet.
Lastly, all the above magic is made possible by a meta protocol for Service discovery b/w clients and paymail service providers, which seem quite robust and extensible.
paymail is a federated protocol, as we see it fits the characteristics defined above, and unfortunately it cannot provide user autonomy. The below is not a weakness of paymail protocol, the designers have done the best they could with the available Bitcoin infrastructure that currently allows a federated model at best. A new decentralized permission-less naming protocol is needed at the foundation/base layer of Bitcoin for realizing a Self-Sovereign identity, where the user is under no authority.
There are a number of possible ways to support this, some previously discussed, some relatively unknown:
- Merge-mining with Namecoin like chains
- Decentralized oracle network (ChainLink)
- Inter-operate with an independent naming chain like (Handshake protocol)
- Allegory a naming protocol that implicitly associates names to Bitcoin UTXOs [To be defined shortly]
Each of the above methods have its challenges in practically integrating naming feature into Bitcoin, but the Allegory naming protocol that uses implicit name association to Bitcoin UTXOs seems to be the most seamless approach. I am working on figuring out some details of the protocol and intend to publish the protocol suite design shortly. The rest of the article focuses on trying to build a strong case for the need of a workable naming protocol on Bitcoin.
For the time being I request the reader to gloss-over this matter, and hypothetically assume the infrastructural naming protocol will be available in future, so we can understand the benefits and protocol internals of a self sovereign ID.
Bitcoin is a self-serve censorship resistant privacy based ecosystem which with the help of a naming protocol should be expected to disrupt aging technologies like Email, IM, presence, VoIP, etc. Although paymail is not related to Email/SMTP in anyway, it is limited by the email based URI handle and the federated identity model, where each user is still under an authority. It would be great if we can untether from email based ID and soar freely.
Although like most federated services paymail can be self-hosted, in practical world (in other protocols) we witness very few go this far. Also as email service providers became fewer and centralized, a similar outcome can be expected here as well, which brings us to an adverse side effect.
Need for trusted 3rd party (paymail service) with who the user must entrust the Master Public Key for the address generation (xPub key derivation). In a world where data collection agencies, dark entities, surveillance etc exist your entire account transactions (corresponding to all derived keys) can be revealed to such an observer. Even if the service provider is going to honor user privacy, there are no guarantees it will not be mismanaged or worse stolen by hackers with criminal or political intentions. This problem will be exacerbated with centralization of service providers. One way to work around it would be use multiple paymail IDs and multiple accounts, probably across providers, but its not scalable or user friendly.
Also by basing the paymail ID on email URI, due to the domain/host resolution involved, inevitably introduces the weak link of DNS into the protocol. DNS was designed in the 1980’s when the Internet was a very different place but in this generation DNS is very vulnerable. Yes, we have DNSSEC which was a later improvement which brought in a chain-of-trust based model with zones (root→TLD→domain→subdomain→…) and authorized signatories up the hierarchy where the parent signs the child records. Although it is completely centralized it makes the web much secure, but unfortunately due to a variety of reasons DNSSEC is not widely adopted. The web is still an insecure place, and very serious attacks like cache-poisoning-attack are common (see appendix).
But we may not have personally fallen victim to this as we generally secure our online accounts email, crypto exchanges, etc with multi factor authentication (2FA), browser token caching, OAuth 2.0. etc. As far as I understood the paymail call flow none of these mechanisms are involved (or feasible) except plain SSL. So given that Bitcoin use-case is primarily financial in nature DNS security limitation is an important factor to consider.
User/ID portability is restricted as the domain is an integral part of an paymail handle. User is locked in to the service provider.
Also as the name suggests ID seems to be primarily limited to payment use-case and some digital signature extensions, its not a fully extensible ID which can be used for other completely new services like say for unified communications.
So paymail core focus is on improving the wallet experience, but it comes at a cost of privacy, lack of user autonomy and full extensibility.
It would be ideal if we could have a identity protocol that works seamlessly on chain without the need for trusted 3rd parties, offering complete privacy, user autonomy features like mobility and greater extensibility.
In my next article I will provide a comparison of popular naming protocols like Namecoin, Handshake, Blockstack & ENS and further propose a new naming protocol suite:
- Allegory: the base naming protocol that can be seamlessly integrated into Bitcoin, also supports efficient SPV name resolution without the need of a trusted full node.
- Allpay: a payment protocol for wallets that works over the Allegory base protocol.
We shall then explore how this protocol suite addresses some of the user autonomy concerns expressed above. The Allpay protocol will offer multiple modes/call flows, namely public mode, authorized contacts mode, whitelisting flows, each having different objectives that might appeal for different types of users i.e. individuals, merchants etc.
- The Path to Self-Sovereign Identity by Christopher Allen, it comprehensively defines the 10 principles of self-sovereign identity: http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html
- The paymail protocol specification: http://bsvalias.org
- DNS hijacking report: https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html