under constrution


Registration API

Regsitration and authentication the remote party consists of the following scenarios:

Key based register/connect

Covers 2 scenarios mostly the same way: new accoutn creation and accessing registered accout, which private key is already known to the connecting party.

See new account registration and reconnecting the existing account diagrams.

The remote party generates new assymmetric key and password key and creates new account. It takes 2 steps: requesting registration and approving registration. The last steps proves that the remote party has a private key in posession.

auth_key_request(key: <binary>, app_token: <string>)
    -> { encrypted_token: <binary> }

key: packed public RSA key in ATTESTA key format (make a link!). It should be at least 2048 bit string, we recommend 4096+. The key should be new, just generated, and unknow to the system. If it is, the system will attempt to login to the existing account.

app_token: application authentication token, some string that authenticates an application.

WARNING. DO NOT EVER TRANSMIT PRIVATE KEYS IN UNENCRYPTED OR WEAKLY ENCRYPTED FORM OVER THE NETWORK OR STORE IT IN ANY PERSISTENT MEDIA. Attesta service will ban the key ir the private key is received, e.g. it could not be used with the service at all. Be sure to extract the public key, pack and sent it.

Then the client decrypts the encrypted token and pass it back to the service:

auth_key_token(token: decrypted_token) 
    -> { id_new: <boolean>, party_id: <string> }

is_new is set to true if the system has created the new account.

party_id the ID of the party that never changes.

Password login

This scenario is used to connect to the existing account using the password. It is a common situation when connecting new mobile device, new software client and so on. The client at this point has no provate key and therefore above described reconnecting can no be used.

To be able to log in, the client should reguster at least one of: nickname, email or phone number. Latter two should be approved during registraion. Also, the client should have the registry stored to the server. If any of these conditions are not met, the accoutn is not accessbile wothout private key.

The process is described in login diagram and is rather simple:

  • client requests registry (this could be done without registration and authentication)

  • client decrypts the registry using the key derived from password entered by the user (derivation method could be extracted from the registry block format) and then registers with private key. See registry API.