taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 1557e7a3547cfa04b111c40ce0feef9581121635
parent edc84e7c1e3958e58e1e760beedc3c2a90575ecb
Author: Florian Dold <dold@taler.net>
Date:   Mon, 24 Aug 2026 22:51:33 +0200

KYC documentation: describe process expiration settings

Diffstat:
Mcore/api-challenger.rst | 4+++-
Mcore/challenger/post-setup-CLIENT_ID.rst | 5+++++
Mmanpages/challenger.conf.5.rst | 11++++++++---
Mmanpages/taler-exchange.conf.5.rst | 7+++++++
4 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/core/api-challenger.rst b/core/api-challenger.rst @@ -89,7 +89,7 @@ verified address of the user. Version History --------------- -The current protocol version is **v8**. +The current protocol version is **v9**. * The Challenger SPA is currently targeting **v6**. @@ -98,6 +98,8 @@ The current protocol version is **v8**. * ``v6``: add the ``address_type`` field to :http:get:`/config </config>` * ``v7``: adds ``build_version`` to :http:get:`/config </config>` * ``v8``: HTTP status code and error code corrections. +* ``v9``: adds ``expires`` to the :http:post:`/setup/$CLIENT_ID + </setup/$CLIENT_ID>` response. **Upcoming versions:** diff --git a/core/challenger/post-setup-CLIENT_ID.rst b/core/challenger/post-setup-CLIENT_ID.rst @@ -92,4 +92,9 @@ interface ChallengeSetupResponse { // Nonce to use when constructing ``/authorize`` endpoint. nonce: string; + + // Time when this validation process expires. After this time it can + // no longer be authorized or exchanged for a token. + // Available since protocol v9. + expires: Timestamp; } diff --git a/manpages/challenger.conf.5.rst b/manpages/challenger.conf.5.rst @@ -59,11 +59,16 @@ DB Plugin to use for the database, e.g. “postgres”. VALIDATION_DURATION - How long is a validation challenge valid. After this time period, a fresh random challenge code will be generated and the retry limit counter (against guessing attacks) will be reset (to 3). + How long a pending validation process may take, starting with ``/setup`` + and ending with ``/token``. After this time the process can no longer be + authorized or exchanged for a token, and garbage collection may delete the + associated process data. Optional, defaults to 1 day if not given. VALIDATION_EXPIRATION - How long is a validation allowed to take (time from - ``/setup`` to ``/token``). After this time, the garbage collection process can delete all associated data. (Note that tokens will always allow access to 1h after they have been issued, regardless of when the validation expires). + How long a successfully validated address is considered valid. This + validity is reported by ``/info`` after the client exchanges the + authorization code at ``/token``. Optional, defaults to 365 days if not + given. TOKEN_EXPIRATION How long is the access token valid after it was issued. diff --git a/manpages/taler-exchange.conf.5.rst b/manpages/taler-exchange.conf.5.rst @@ -268,6 +268,13 @@ The following options must be in the section "[kyc-provider-$PROVIDER_NAME]" sec LOGIC API type of the KYC provider. +KYC_PROCESS_TIMEOUT + Maximum time for which the exchange reuses an unfinished KYC process if + the provider does not report the process's own expiration time. Once this + timeout passes, starting KYC creates a fresh provider process instead of + returning the old redirect URL. Must be finite and non-zero. Optional, + defaults to 1 day. A provider-reported expiration takes precedence. + Additional logic-specific options may be given in the section.