[taler-docs] branch master updated: adjust to latest implementation changes

[gnunet]

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

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 01a8c158 adjust to latest implementation changes
01a8c158 is described below

commit 01a8c1581a266d12af0d074c5d31c5dba37d51a5
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Nov 2 22:30:25 2023 +0100

    adjust to latest implementation changes
---
 core/api-challenger.rst         | 15 +++++++++++++--
 manpages/challenger-admin.1.rst |  9 +++++++--
 manpages/taler.conf.5.rst       |  2 +-
 taler-challenger-manual.rst     |  4 ++--
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/core/api-challenger.rst b/core/api-challenger.rst
index 265ad5a6..3047ebb0 100644
--- a/core/api-challenger.rst
+++ b/core/api-challenger.rst
@@ -49,9 +49,9 @@ particular address.  However, asking a user to prove access 
to a particular
 address can be expensive as it may involve sending an SMS or even postal mail
 depending on the type of address.  Thus, challenger does not allow a user
 agent to begin an address validation process without prior approval by a
-registered client.  Thus, the process begins with a ``/setup`` request where a
+registered client.  Thus, the process begins with a ``/setup/$CLIENT_ID`` 
request where a
 client requests challenger to begin an address validation request.  The
-``/setup`` response contains a ``nonce`` which is then used to construct the
+``/setup/$CLIENT_ID`` response contains a ``nonce`` which is then used to 
construct the
 URL of the endpoint to which the client must redirect the user-agent to begin
 the address validation and authorization process.
 
@@ -327,6 +327,17 @@ Info
   .. ts:def:: ChallengerInfoResponse
 
     interface ChallengerInfoResponse {
+      // Validation status.
+      status: "success";
+
+      // Details about the validation.
+      data: ChallengerInfoData;
+
+    }
+
+  .. ts:def:: ChallengerInfoData
+
+    interface ChallengerInfoData {
       // Address that was validated.
       address: string;
 
diff --git a/manpages/challenger-admin.1.rst b/manpages/challenger-admin.1.rst
index af4508ea..bdb7687c 100644
--- a/manpages/challenger-admin.1.rst
+++ b/manpages/challenger-admin.1.rst
@@ -19,7 +19,9 @@ Synopsis
 [**-h** | **--help**]
 [**-L** *LOGLEVEL* | **--log=**\ \ *LOGLEVEL*]
 [**-l** *FILENAME* | **--logfile=**\ \ *FILENAME*]
-[**-v** | **--version**] CLIENT_URL
+[**-q** | **--quiet**]
+[**-v** | **--version**]
+CLIENT_URL
 
 
 Description
@@ -48,7 +50,10 @@ Its options are as follows:
 **-l** *FILENAME* \| **--logfile=**\ \ *FILENAME*
    Configure logging to write logs to *FILENAME*.
 
-**-v** \| **–version**
+**-q** \| **–-quiet**
+   Be less verbose in the output. Useful in shell scripts.
+
+**-v** \| **–-version**
    Print version information.
 
 
diff --git a/manpages/taler.conf.5.rst b/manpages/taler.conf.5.rst
index 077ff64d..0bbff9ad 100644
--- a/manpages/taler.conf.5.rst
+++ b/manpages/taler.conf.5.rst
@@ -287,7 +287,7 @@ KYC_OAUTH2_VALIDITY
   Duration (e.g. "12 months") of the validity of the performed KYC check. Can 
be "forever".
 
 KYC_OAUTH2_AUTHORIZE_URL
-  URL of the OAuth2 endpoint to be used for KYC checks. The authorize URL is 
where the exchange will redirect the client to begin the authorization process. 
 Example: "http://localhost:8888/oauth/v2/authorize";. To use the plugin in 
combination with the Challenger service's ``/setup`` step, append "#setup", 
thus "https://challenger.example.com/authorize#setup";.  Here, "#setup" is not a 
fragment but merely a hint to the logic to determine the full authorization URL 
via the ``/setup`` handler.
+  URL of the OAuth2 endpoint to be used for KYC checks. The authorize URL is 
where the exchange will redirect the client to begin the authorization process. 
 Example: "http://localhost:8888/oauth/v2/authorize";. To use the plugin in 
combination with the Challenger service's ``/setup`` step, append "#setup", 
thus "https://challenger.example.com/authorize#setup";.  Here, "#setup" is not a 
fragment but merely a hint to the logic to determine the full authorization URL 
via the ``/setup/$CLIENT [...]
 
 KYC_OAUTH2_TOKEN_URL
   URL of the OAuth2 endpoint to be used for KYC checks. This is where the 
server will ultimately send the authorization token from the client and obtain 
its access token (which currently must be a "bearer" token). Example: 
"http://localhost:8888/oauth/v2/token"; (or just "/token")
diff --git a/taler-challenger-manual.rst b/taler-challenger-manual.rst
index ae7eb047..004d8e91 100644
--- a/taler-challenger-manual.rst
+++ b/taler-challenger-manual.rst
@@ -423,7 +423,7 @@ three options from the previous section, but also the 
authorization, token and
 info endpoints.  For Challenger, these are ``/authorize``, ``/token`` and
 ``/info``.  However, the ``/authorize`` endpoint is special, as it is actually
 ``/authorize/$NONCE`` where ``$NONCE`` is a nonce that must be first requested
-by the client using the ``/setup`` endpoint!
+by the client using the ``/setup/$CLIENT_ID`` endpoint!
 
   ..note::
 
@@ -433,7 +433,7 @@ by the client using the ``/setup`` endpoint!
     validation could be expensive.
 
 Thus, to generate the authorization URL, a client must first POST to
-``/setup`` using their client secret in an ``Authorization: Bearer $SECRET``
+``/setup/$CLIENT_ID`` using their client secret in an ``Authorization: Bearer 
$SECRET``
 HTTP header to obtain a fresh ``$NONCE``.
 
 In the GNU Taler exchange configuration, this is indicated by appending

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