CashID Review: New Bitcoin Cash-Based Authentication Solution With Optional MetaData
CashID is an open protocol that allows secure authentication based on the public key cryptography infrastructure that is currently present in the Bitcoin Cash ecosystem.
The idea had been tried before. 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. However, this did not catch on.
The reason that this idea hasn't caught on more widely is that it was never properly implemented in wallets. I also think the reason that wallets didn't implement it widely is that 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.
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, therefore, 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.
CashID Provides A Solution
In today's 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 respond 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 required 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.
How CashID Works
When a user needs to access a physical or digital restricted area they are given a Challenge request by the service provider. The identity manager presents the request to the user and allows them to choose a suitable keypair to represent their identity.
If metadata was requested the identity manager provides the user the option to select which data to use for each metadata field, as well as the option to not supply information for any given field. If the user denies sharing of metadata for a field marked as required, the identity manager aborts the request.
When the user has chosen an identity, the identity manager signs the challenge request adds the metadata that was approved by the user and sends a Challenge response back to the service provider.
The service provider validates the response and returns a Confirmation status. If the confirmation contains a status message it is shown to the user.
The service provider can now use the address as a user identifier and perform the requested action.
Work has begun on making a website on cashid.info/ 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 demo.cashid.info/ and an Oath2 service to act as a bridge to the existing infrastructure is planned for oauth.cashid.info/ later on.