adjust to latest implementation changes

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_ID`` handler.
 
 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