commit 26758b7a397aa9872e50beb949d87d4f030bf86f
parent 7989e0ec611393f2491049de17a0e18f40a6023a
Author: Christian Grothoff <christian@grothoff.org>
Date: Sat, 6 May 2023 19:27:21 +0200
write README
Diffstat:
| M | README | | | 101 | +++++++++++++++++++++++++++++++++++++++---------------------------------------- |
1 file changed, 50 insertions(+), 51 deletions(-)
diff --git a/README b/README
@@ -1,81 +1,80 @@
-About SYNC
-----------
+About CHALLENGER
+----------------
-Sync implements an HTTP server that allows clients to backup data.
-Envisioned use-cases are the creation of backups for Taler wallets and
-(GnuPG) key rings and other small but essential sensitive information.
+Challenger implements an HTTP server that allows clients to validate
+that a user is able to receive PIN/TAN codes at a given address using
+OAuth 2.0-style authorization.
+
+Envisioned use-cases are KYC checks where a user must prove that they
+are able to receive SMS, e-mails or physical mail.
Accountability:
===============
-Client accounts are identified by a public key. For each client, at
-most one backup can be stored at any given point in time. To create
-an account, the service may require payment using GNU Taler when the
-first upload is attempted.
-
-
-Availability:
-=============
-
-The Sync service may impose a limit on the maximum size of the backup
-that is supported. The /terms API lists the specific terms of
-service, including the maximum size and the payment required for a
-year of backup service.
-
-
-Integrity:
-==========
-
-All uploads must be signed with the respective private key of the
-account. Clients must know their public key to download the latest
-backup.
+Clients must be registered before they can use the service. To
+initiate an address verification, clients must first setup an
+authorization session before directing the user agent towards the
+``/login`` endpoint. The system automatically tracks how many address
+verification session a particular client has authorized. This is
+expected to be useful in cases where address verifications have
+non-negligible cost. The system also limits how often a user-agent
+may change the address per authorization session as well as the number
+of times the PIN/TAN code is transmitted to each address. Finally, it
+of course also limits the number of times a user may enter a PIN/TAN
+code.
-Confidentiality:
-================
+Time limits:
+============
-Clients are responsible for confidentiality and key management.
-All data uploaded should be encrypted by the client first.
-For key management, please consider Anastasis.
+Once authorized, a client has limited time to use the user agent's
+authorization code. The resulting grant also has limited lifetime
+during which the client must download the verified address of the
+user.
-Consistency:
+Flexibility:
============
-Uploads that replace an existing backup must acknowledge the previous
-version by including the hash of the previous version in the backup
-request. This ensures that multiple clients working on the same
-account never accidentally overwrite data from another client.
+The actual transmission of the PIN/TAN code is done via a separate
+binary that is simply invoked by the challenger service. This makes
+the code useful for all types of address validations. Simple shell
+scripts are provided for SMS, e-mail and physical address validation.
+
+All user-facing forms are fully customizable and provided as Mustach
+templates. By changing the templates, the look-and-feel of the
+service can be freely adapted.
Usability:
==========
-Sync uses a simple REST-based API documented at
-https://docs.taler.net/.
+Challenger uses a simple REST-based API documented at
+https://docs.taler.net/. The authorization flow is believed
+to be fully compatible with OAuth 2.0.
-Operation:
-==========
+Limitations:
+============
-Sync does at this time not include HTTPS support. While this could
-be trivially added, we expect Sync to be run behind a reverse proxy
+Challenger does at this time not include HTTPS support. While this could
+be trivially added, we expect Challenger to be run behind a reverse proxy
that terminates TLS.
-At this time, Sync only works with a Postgres database. Other database
+At this time, Challenger only works with a Postgres database. Other database
backends could easily be written in the future.
Dependencies
============
-See INSTALL for generic installation instructions. In addition, Sync
-requires GNUnet, Taler Exchange, and Taler Merchant libraries. If these
-are installed in a non-standard place, use the configure script options
---with-gnunet=DIR, --with-exchange=DIR, and --with-merchant=DIR,
-respectively.
+See INSTALL for generic installation instructions. In addition,
+Challenger requires GNUnet, GNU Taler Exchange, and GNU Taler Merchant
+libraries. If these are installed in a non-standard place, use the
+configure script options --with-gnunet=DIR, --with-exchange=DIR, and
+--with-merchant=DIR, respectively.
The following are likewise required:
@@ -89,7 +88,7 @@ in the "./configure --help" output.
License:
========
-Sync is released under the Affero GPL v3 or later.
+Challenger is released under the Affero GPL v3 or later.
-The primary source code is maintained at https://git.taler.net/sync.git
-by the GNU Taler team.
+The primary source code is maintained at
+https://git.taler.net/challenger.git by the GNU Taler team.
