Many years ago I stumbled upon an idea for authentication with web services that is as brilliant as it is simple - just let users sign their login requests with their Bitcoin wallets.
This idea was called BitID and was implemented as a demo and had basic documentation.
I had high expectations that this system of logging in to websites would catch on and become widely adopted as it solved some important problems, but as time went on the idea ended up being forgotten and only used at a few places here and there.
I think the reason that this idea hasn't catched on more widely is because it was never properly implemented in wallets. I also think the reason that wallets didn't implement it widely is because there was little to no consumer demand and the specification for the system was merely a short draft document that since has barely been updated.

What is needed for wide support for an authentication mechanism?

It's often been said that for a new idea to be adopted by the market, it needs to be much better than the idea that it replaces. This is because new ideas have risks and implementation costs and is never guaranteed to be successful.
When looked at in this regard, BitID seems like a risky bet, as it has almost no wallet support, a small or one-man team building it and the specification draft is incomplete and there is multiple extensions to it that are also drafts.
There are also two parties involved in authentication, a service provider and a service user, and they have different needs and desires. The currently existing authentication schemes work relatively well for the service providers - all users understand them and they are compatible with all users. The drawbacks are known and the costs of those drawbacks are almost entirely on the user side. The service users are rarely technical people and they rarely know there exist better options - all they want is convenience and for things to work with a high degree of stability.
To get a new authentication mechanism to be widely used, it therefor needs to cater to the needs of both groups and needs to deliver value to both groups; it simply isn't enough to be secure, or even convenient.

Meet CashID, a way to create value for both service providers and users

In todays web services, there are known pain points which people are working hard on to try and solve every day. One of these pain points is the registration or sign-up forms, which takes information from a user to set up their account. From a users perspective, giving up information is a privacy risk, but more importantly, it is a tedious and boring chore. With more and more users being mobile and having subpar text-entry mechanisms this problem is compounded.
The service providers response to this has mostly been either reducing complexity, in that they don't request all the information up-front, or increased use of commitment devices, in that they put the most bothersome registration part after you've committed to joining but before you were aware of the registration hurdle at the end.
Both of these can easily be solved with CashID in the form of a single login request, in which the service provider lists the requried and optional data it wants and the user shares that data as part of the login procedure. You don't even need a signup page, it is already part of the login request.
By using CashID to login to web services, there is also other benefits that isn't visible to the users. There is no authentication data to be lost or stolen when a service provider is hacked, and for privacy centered sites it is possible to have no userdata at all stored on the service providers end, and have the user supply it on every login.
It is also possible to create new usecases due to the Bitcoin Cash integration, such as using a payment on-chain as a redeemable ticket, like if you buy entry to the cinema and then authenticate to the popcorn machine to get your included popcorn.
In fact, these use cases are just the tip of the iceberg and with the ability to seemlessly share metadata and payment relations a lot of new usecases will be enabled.

Sounds good, where do I go to start using it?

There is a specification available that is ready to for implementation and an identity manager for android is currently in beta.
Work has begun on making a website on that explains the value proposition in more detail and that has more accessible resources for both developers and users, a demo site with examples and test cases is being built on and an Oath2 service to act as a bridge to the existing infrastructure is planned for later on.
There is a chat topic on and server on discord for those that want to talk about the CashID ecosystem and/or get help with implementation. I will be holding a reddit AMA in r/btc on 2018-10-06 sometime around 10:00 GMT.
This work so far has taken up a lot of my time, and I've asked the Bitcoin Cash Association for project funds to help me realize this potential, but they are not taking new project submissions.
If you think this is a valuable feature, here's a few things you can do to help out:
  • Use the CashID authentication protocol in your services
  • Request CashID support with your wallet vendors and service providers
  • Inform your friends/family/followers about the benefits of passwordless logins
  • Take part in the development of the website, identity manager and oauth service
  • Fund me personally to encourage me to keep working on bitcoin cash projects


8 of 8 reviewers say it's worth paying for

0 of 8 reviewers say it's not worth paying for