[tep] rename doc and minor edits.

- TEP-asymmetric_key_client_authentication.md -> TEP-0012.md
- Some clarifications and expansions based upon Jose's questions.

Author: da2ce7

TEP-asymmetric_key_client_authentication.md renamed to TEP-0012.md

@@ -119,7 +119,10 @@ The seed words are prefixed with an additional `"torrust"` word, and displayed t
 
 Clients must provide an option for the user to give a seed-password in generation and recovery.
 
-* The client should only need their seed mnemonic code in the case they have lost their other login credentials.
+### Storage of Mnemonic Code
+The client should delete from memory the recovery seed once the user has confirmed that they have backed up the seed, and the key-pair for login has been generated.
+
+This gives the user some forward security. In the future the user may wish to use the same seed to rotate their keys (for example, when logging in on a new computer). Because the seed is not saved in the client, if the users' client is compromised at a later date, the seed itself remains secret.
 
 ## Public and Private Key Derivation
 Deriving the keys according to: [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki).
@@ -130,7 +133,9 @@ m / purpose' / version' / torrust-purpose' / index'
 
 m / "torrust" / 0 / "authentication" / 0
 ```
-The resulting node is a private-public secp256k1 key-pair.
+The resulting node is a private-public secp256k1 key-pair. (the same elliptical-curve as is used in bitcoin).
+
+___Note:__ as an extension, the future client may choose to register a series of public keys with the server, i.e. 0, 1, 2, 3, etc, and only keep the current key in storage, this will allow for easier key-rotation in the future._
 
 ## Login Credential Encoding
 For encoding the secp256k1, we use [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) encoding, 32-bytes for public keys.</br>
@@ -215,9 +220,41 @@ token_auth
 If matching, authorise user according to their user public key. (U_client).
 ```
 
+_The server now can issue a session token to the client accordingly._
+
+## Security Analysis
+
+This scheme is very simple, it would be very good there was some formal security analysis.
+
+The basic protocol follows:
+
+1. Both derive a common ephemeral (temporary) key:</br>
+`client_ephemeral (DH) server_ephemeral -> ephemeral_key`
+
+2. Both derive a common authentication key:</br>
+`client_public (DH) server_ephemeral -> authentication_key`
+
+3. Client derives the common authentication token:</br>
+`sever_uri + ephemeral_key + authentication_key -> authentication_token`
+
+4. Client sends URI and authentication token to server:</br>
+`client: sever_uri, authentication_token => server`
+
+5. Server checks `sever_uri` matches expected value.
+
+6. Server also derives the common authentication token:</br>
+`sever_uri + ephemeral_key + authentication_key -> authentication_token`
+ `authentication_token`
+
+7. Server checks the received `authentication_token` matches self-derived value.
+
 # Compatibility
 
 The updated client will support both login in with the new authentication scheme, and transferring existing users with password authentication to the new scheme.
 
 # Reference Implementations
 
+## Similar Implementations
+This scheme is so simple that I guess there should be!
+
+However, the common ones that I have found are far-more complex than what we use here, (such as getting a CA involved with the authentication).