commit 07278834c597f9122be600aae80fa5c738da54bd
parent b8abc72adace7cb7585f684db805ec26a9d055fb
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Mon, 18 Dec 2023 17:09:46 +0800
document challenger architecture
Diffstat:
1 file changed, 30 insertions(+), 0 deletions(-)
diff --git a/taler-challenger-manual.rst b/taler-challenger-manual.rst
@@ -45,8 +45,38 @@ or learn about known limitations, please check our
Architecture overview
---------------------
+The following picture gives an overview of the Challenger
+architecture and the main interactions:
+
.. image:: images/challenger.png
+Here, the *resource owner* is a user that is in control
+of some *address* at a messaging service. This could be
+an e-mail account, a mobile phone number (for SMS), or
+a physical mail address (using the post office as the
+messaging service).
+
+The *resource owner* makes some request that requires
+some *client* to be in need of address validation. The
+*client* is registered with the Challenger OAuth 2.0
+service and first authorizes an address validation to
+be initiated. The client then redirects the resource
+owner to the Challenger service. In step (2), the resource
+owner submits the address that they claim to own.
+
+The Challenger service then creates a TAN code and
+submits it to the given address via a configurable
+*helper script* that is specific to the type of address
+being validated. When the resource owner submits the
+correct TAN code in step (6), they are given a token
+that they can provide to the client. Using this token
+the client can then finally obtain the now validated
+address in step (8).
+
+Address data, TAN codes and meta-data such as the number
+of failed attempts to submit a TAN code are recorded
+in a Postgres database by the Challenger service.
+
.. _ChallengerInstallation:
Installation
