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 user and allows the 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.
Once approved by the user, 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 request, public key and signature of the response and returns a confirmation response. If the confirmation response contains a status message it is shown to the user.
The service provider can now use the public key as the users identifier and perform the requested action.
The **Nonce** parameter acts as a replay-protection mechanism, by making each request challenge and response unique. Each **Nonce** can only be used a single time during its lifespan and should expire if left unused for a significant amount of time.
The service provider should not process requests that it has not issued nonces for, except for **User actions** that have a valid and recent **Timestamp** as their nonce value.
The optional **Action** parameter is used to describe the action that the user authenticates to perform. Identity managers may implement any number of **predefined** and **custom** actions, but must implement the default **auth** action. When a **Data** parameter is present, the **Action** also determines how to interpret it.
**Custom actions** may be used to enable more usecases. If an identity manager parses a request with a custom action it does not understand, it should inform the 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"*
When the identity manager is ready to submit a **Challenge response** it forms a **Response URL** by appending the **Domain** and **Path** components to a **https://** scheme identifier.
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*
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.
In order to reduce implementation costs and increase implementation conformity, this specification supplies extra material that can be helpful to developers.
