[taler-anastasis] branch master updated: fixes

[gnunet]

This is an automated email from the git hooks/post-receive script.

ds-meister pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new 77fe053  fixes
77fe053 is described below

commit 77fe0532776a7175df57611a74ebf80065b4cb19
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Thu Jun 11 11:51:45 2020 +0200

    fixes
---
 doc/thesis/images/recovery_process.png | Bin 67810 -> 56690 bytes
 doc/thesis/images/secret_split.png     | Bin 85527 -> 71801 bytes
 doc/thesis/implementation.tex          |  10 +++++-----
 doc/thesis/server_architecture.tex     |  16 ++++++++--------
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/thesis/images/recovery_process.png 
b/doc/thesis/images/recovery_process.png
index 063d055..af2de2d 100644
Binary files a/doc/thesis/images/recovery_process.png and 
b/doc/thesis/images/recovery_process.png differ
diff --git a/doc/thesis/images/secret_split.png 
b/doc/thesis/images/secret_split.png
index 604a231..876bfdf 100644
Binary files a/doc/thesis/images/secret_split.png and 
b/doc/thesis/images/secret_split.png differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index d347ace..c7563ec 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -108,8 +108,8 @@ process.
 \item After the user has generated the public key, per will create a
   truth object on the client. The truth object contains all the needed
   information for the recovery for this key share. This truth object
-  is sent encrypted to the server and stored under a UUID the client
-  generated (POST /truth/\$UUID).
+  is sent encrypted to the server and stored under the TRUTH\_PUB the client
+  generated (POST /truth/\$TRUTH\_PUB).
 \item In this scenario the client has not jet paid for the
   upload. This means the server will respond with the HTTP status code
   \texttt{402 Payment required}. The client first must do a payment with our
@@ -156,7 +156,7 @@ Figure~\ref{fig:recovery_process} illustrates the recovery 
process.
   policies and authentication methods. The user now has to solve these
   challenges. In this example the user has to answer a secure question
   which was sent to them in the recovery document. (GET
-  /truth/\$UUID?response=\$RESPONSE) \\
+  /truth/\$TRUTH\_PUB?response=\$RESPONSE) \\
 \item Note the server can define that a challenge has a certain cost,
   in this scenario the server rejects the first request because the
   user has not yet paid for recovery.  After the payment the user can
@@ -170,10 +170,10 @@ Figure~\ref{fig:recovery_process} shows the flow using a 
secure
 question for the authentication challenge. If the user would have
 chosen a complex authentication method like SMS or E-Mail, the client
 would first need to start the challenge with the request (GET
-/truth/\$UUID). The server would then notify the user that per will
+/truth/\$TRUTH\_PUB). The server would then notify the user that per will
 receive some token out of bounds. After that, the user would have to
 provide for example the PIN sent to them via SMS with the same request
-as before (GET /truth/\$UUID?resonse=\$RESPONSE).
+as before (GET /truth/\$TRUTH\_PUB?resonse=\$RESPONSE).
 
 
 \subsection{Client Application Command Line Interface (CLI)}
diff --git a/doc/thesis/server_architecture.tex 
b/doc/thesis/server_architecture.tex
index 21e8c88..7641029 100644
--- a/doc/thesis/server_architecture.tex
+++ b/doc/thesis/server_architecture.tex
@@ -70,18 +70,18 @@ how they would be implemented.
 
 In all cases, the authentication process begins by the user decrypting
 their (encrypted) recovery document, which contains a list of Anastasis
-providers, associated authentication methods, \$UUIDs and associated
+providers, associated authentication methods, truth\_seeds and associated
 truth encryption keys.  The recovery process than varies slightly
 depending on the authentication method.
 
 \paragraph{SMS (sms)}
 
 The user tells the server with a request that they wants to authorize
-key recovery (via GET /truth/\$UUID), providing a way to decrypt the
+key recovery (via GET /truth/\$TRUTH\_PUB), providing a way to decrypt the
 truth with the phone number. The server will then generate a \$PIN and
 send it via an SMS provider to the stored number in the truth
 object. The client then must send another request with the sent \$PIN
-(via GET /truth/\$UUID?resonse=\$PIN). The server can now check
+(via GET /truth/\$TRUTH\_PUB?resonse=\$PIN). The server can now check
 if the two PINs match. Upon success, the server returns the encrypted
 key share.
 
@@ -96,7 +96,7 @@ result in accidental information leakage about the user from 
the image
 before encrypting and uploading it to the Anastasis provider.
 
 For recovery, the user must first send a request to server that they
-wants to authorize recovery (GET /truth/\$UUID).  The Anastassis
+wants to authorize recovery (GET /truth/\$TRUTH\_PUB).  The Anastassis
 provider will then decrypt the user's image and send a request with a
 \$TOKEN to a video authentication provider that a user wants to
 authenticate, and respond to the user with a link to a video
@@ -104,18 +104,18 @@ conference.  The video authentication provider then 
checks via video
 conference that the user in the image is the same that they have on
 the video link. Upon success, the video provider releases the \$TOKEN
 to the user.  The client then must send another request with the
-\$TOKEN (via GET /truth/\$UUID?resonse=\$TOKEN). The Anastasis
+\$TOKEN (via GET /truth/\$TRUTH\_PUB?resonse=\$TOKEN). The Anastasis
 provider checks that the tokens match, and upon success returns the
 encrypted key share.
 
 \paragraph{Post identification (post)}
 
 The user tells the Anastasis provider with a request that they want
-to authenticate using Post identification (GET /truth/\$UUID).  The
+to authenticate using Post identification (GET /truth/\$TRUTH\_PUB).  The
 Anastasis provider uses the request to decrypt the user's truth to
 determine the user's postal address, and sends them letter containing
 a \$PIN.  Upon receiving the letter, the client then has to send
-another request with the \$PIN (GET /truth/\$UUID?resonse=\$PIN). The
+another request with the \$PIN (GET /truth/\$TRUTH\_PUB?resonse=\$PIN). The
 server can now check if the two PINs match. Upon success the server
 will release the encrypted key share.
 
@@ -131,6 +131,6 @@ either.
 
 If the user wants to recover the key share from the server, they must
 provide the (salted) hash of the answer to the security question (via
-GET /truth/\$UUID?response=\$HASH). The server then checks if the
+GET /truth/\$TRUTH\_PUB?response=\$HASH). The server then checks if the
 stored and the provided hash match. Upon success the server responds
 with the encrypted key share.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.