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. By authentication we mean to prove to a service provider that we control a specific Bitcoin Cash address by signing a challenge request that links the users address and optional metadata to a task or session with the service provider.
Passwords is an inherently flawed concept (based on sharing secrets) that is increasingly getting hidden away from the users by means of password managers, 'remember me' and single-signon features. Public key cryptography provides a more secure method for authentication where the users secret is never shared.
The problem with public key infrastructure is that managing private keys securely is complex, but this complexity is now being addressed in the cryptocurrency ecosystem which makes it possible to safely implement a better authentication system.
When a user needs to access a restricted area (physically or digitally), they are given a **Challenge request** by the service provider. This request can be transmitted as QR code, by NFC touch or by any other implementation specific transmission method. The identity manager presents the request information 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 full **Challenge request**, adds the metadata that was approved by the end-user and sends a **Request response** back to the service providers **Request URL** as a **POST** request.
The service provider validates the request, public key and signature of the response. If the request is valid the service provider then uses the public key as the users identifier and performs the requested action.
Parameters | ?a=action<br/>&d=data<br/>&r=required<br/>&o=optional<br />&x=nonce | These are settings that a service provider <br /> can use to inform the identity manager <br /> about what expectations the service provider <br /> has with regards to the response data
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.
#### Service actions
The following is a list of common actions that a service provider can offer to users:
login | Identifies the end-user to the service provider and grants access to digital services | Session identification ID used to link the login request with an active anonymous session
sign | Asks the end-user to cryptographically sign a message | Message text that the identity is requested to sign
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 **Request 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.
