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. Each user can prove to a service provider that they controls a specific Bitcoin Cash address by signing a challenge request, as well as provide optional metadata.
Passwords is an inherently flawed concept based on sharing secrets that is increasingly getting hidden away from the users by means of password managers, permanent sessions and single-signon features. Public key cryptography provides a more secure method for authentication where the users secret is never shared.
Secure authentication with optional metadata is useful, for example to...
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 end-user and allows the them to choose a suitable keypair to represent their identity.
If metadata was requested the identity manager provides the end-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.
Once approved by the end-user, the identity manager signs the challenge request, adds the metadata that was approved by the end-user and sends a **Challenge response** back to the service provider.
The service provider validates the request, public key and signature of the response and if the request is valid the service provider then uses the public key as the users identifier and performs the requested action.
The optional **Action** parameter is used to describe the action that the user authenticates to perform. When a **Data** parameter is present, the **Action** also determines how to interpret it.
update | Informs the service provider about changes to identity, position or contact metadata
#### Custom actions
It is plausible that this document cannot predict all possible usecases it enables, and service providers may choose to use custom non-standard action names and data fields to enable new usercases. If an identity manager parses a request with a foreign action it does not know about, it should inform the end-user and must abort the request.
The **Required** and **Optional** parameters allow the service to request personal information from the user. In order to do this in the least amount of space, the information is shorthanded by a letter and a string of numbers representing various pieces of personal information. For **Optional** metadata, the numbers after a letter can be omitted to request all fields in that category. The same metadata fields can only be requested in either **Required** or **Optional** scope, not both. The field numbers in each category has to be listed in sorted order, starting with the lowest number.
4 | Street name | String | Name of the street, without the street number
5 | Street number | String | The street number
6 | Residence | String | Building or apartment number that uniquely reference a residence
9 | Coordinate | String | Geographical position as specificed in [RFC5870](https://tools.ietf.org/html/rfc5870)<br/>*For example: "geo:13.4125,103.8667"*
The **Nonce** parameter acts as a replay-protection mechanism and is a random number between X and Y formatted as a hexadecimal string (0123456789ABCDEF). Each **Nonce** can only be used a single time during it's lifespan and should expire if left unused.
The **register** action at **example.com** requires **Name**, **Last Name**, **Country** and **Email** to work, and will use **Picture**, **Age**, **Gender** and **City** if provided.
When the identity manager is ready to submit a **Challenge response** it forms a **Request URL** by appending the **Domain** and **Path** components to a **https://** scheme identifier.
*(NOTE: the original spec just dumps all the data into POST, this is not always convenient, so maybe we should change it to url-encoded POST, like I described below)*
Metadata is stored as a JSON object with property names matching the requested field names. Fields that has multiple values (for example social media accounts) is stored as a JSON object with property names matching their identifier and the data matching the field description.
For example, if the request contains **r=i12&o=c** the metadata part of the request answer would look like this:
```javascript
metadata:
{
'name':'John',
'last name':'Doe',
'email':'johndoe@gmail.com',
'social':
{
'facebook':'https://facebook.com/johndoe',
'twitter':'https://twitter.com/johndoe'
}
}
```
*Note that there is two fields for social media presence and no fields for optional contact data the user did not want to supply*
Error codes above 100 are available for custom responses, not specified here. If such a response is received, which IM doesn't recognize, it must simply show the textual error to the user.
