14.44.2. Description
The configuration file is line-oriented.
Blank lines and whitespace at the beginning and end of a line are ignored.
Comments start with # or % in the first column
(after any beginning-of-line whitespace) and go to the end of the line.
The file is split into sections.
Every section begins with “[SECTIONNAME]” and
contains a number of options of the form “OPTION=VALUE”.
There may be whitespace around the = (equal sign).
Section names and options are case-insensitive.
The values, however, are case-sensitive.
In particular, boolean values are one of YES or NO.
Values can include whitespace by surrounding
the entire value with " (double quote).
Note, however, that there are no escape characters in such strings;
all characters between the double quotes (including other double quotes)
are taken verbatim.
Values that represent filenames can begin with a /bin/sh-like
variable reference.
This can be simple, such as $TMPDIR/foo, or complex,
such as ${TMPDIR:-${TMP:-/tmp}}/foo.
See [PATHS] (below).
Values that represent a time duration are represented as a series
of one or more NUMBER UNIT pairs, e.g. 60 s, 4 weeks 1 day,
5 years 2 minutes.
Values that represent an amount are in the usual amount syntax:
CURRENCY:VALUE.FRACTION, e.g. EUR:1.50.
The FRACTION portion may extend up to 8 places.
Files containing default values for many of the options described below
are installed under $TALER_PREFIX/share/taler/config.d/.
The configuration file given with -c to Taler binaries
overrides these defaults.
A configuration file may include another, by using the @INLINE@ directive,
for example, in main.conf, you could write @INLINE@ sub.conf to
include the entirety of sub.conf at that point in main.conf.
Be extra careful when using taler-config -V VALUE to change configuration
values: it will destroy all uses of @INLINE@ and furthermore remove all
comments from the configuration file!
GLOBAL OPTIONS
The following options are from the “[taler]” section and used by
virtually all Taler components.
- CURRENCY
- Name of the currency, e.g. “EUR” for Euro.
- CURRENCY_ROUND_UNIT
- Smallest amount in this currency that can be transferred using the
underlying RTGS. For example: “EUR:0.01” or “JPY:1”.
- AML_THRESHOLD
- Largest amount in this currency that can be transferred per month without
an AML staff member doing a (manual) AML check. For example: “USD:1000000”.
The “[PATHS]” section is special in that it contains paths that can be
referenced using “$” in other configuration values that specify
filenames. For Taler, it commonly contains the following paths:
- TALER_HOME
- Home directory of the user, usually “${HOME}”. Can be overwritten by
testcases by setting ${TALER_TEST_HOME}.
- TALER_DATA_HOME
- Where should Taler store its long-term data.
Usually “${TALER_HOME}/.local/share/taler/”.
- TALER_CONFIG_HOME
- Where is the Taler configuration kept.
Usually “${TALER_HOME}/.config/taler/”.
- TALER_CACHE_HOME
- Where should Taler store cached data.
Usually “${TALER_HOME}/.cache/taler/”.
- TALER_RUNTIME_DIR
- Where should Taler store system runtime data (like UNIX domain
sockets). Usually “${TMP}/taler-system-runtime”.
EXCHANGE OPTIONS
The following options are from the “[exchange]” section and used by most
exchange tools.
- DB
- Plugin to use for the database, e.g. “postgres”.
- PORT
- Port on which the HTTP server listens, e.g. 8080.
- MASTER_PUBLIC_KEY
- Crockford Base32-encoded master public key, public version of the
exchange’s long-time offline signing key.
- MASTER_PRIV_FILE
- Location of the master private key on disk. Only used by tools that
can be run offline (as the master key is for offline signing).
- BASE_URL
- The base URL under which the exchange can be reached.
Added to wire transfers to enable tracking by merchants.
Used by the KYC logic when interacting with OAuth 2.0.
- AGGREGATOR_IDLE_SLEEP_INTERVAL
- For how long should the taler-exchange-aggregator sleep when it is idle
before trying to look for more work? Default is 60 seconds.
- CLOSER_IDLE_SLEEP_INTERVAL
- For how long should the taler-exchange-closer sleep when it is idle
before trying to look for more work? Default is 60 seconds.
- TRANSFER_IDLE_SLEEP_INTERVAL
- For how long should the taler-exchange-transfer sleep when it is idle
before trying to look for more work? Default is 60 seconds.
- WIREWATCH_IDLE_SLEEP_INTERVAL
- For how long should the taler-exchange-wirewatch sleep when it is idle
before trying to look for more work? Default is 60 seconds.
- AGGREGATOR_SHARD_SIZE
- Which share of the range from [0,..2147483648] should be processed by one of the shards of the aggregator. Useful only for Taler exchanges with ultra high-performance needs. When changing this value, you must stop all aggregators and run “taler-exchange-dbinit -s” before resuming. Default is 2147483648 (no sharding).
- SIGNKEY_LEGAL_DURATION
- For how long are signatures with signing keys legally valid?
- MAX_KEYS_CACHING
- For how long should clients cache
/keys responses at most?
- MAX_REQUESTS
- How many requests should the HTTP server process at most before committing suicide?
- TERMS_DIR
Directory where the terms of service of the exchange operator can be fund.
The directory must contain sub-directories for every supported language,
using the two-character language code in lower case, e.g. “en/” or “fr/”.
Each subdirectory must then contain files with the terms of service in
various formats. The basename of the file of the current policy must be
specified under TERMS_ETAG. The extension defines the mime type.
Supported extensions include “html”, “htm”, “txt”, “pdf”, “jpg”, “jpeg”,
“png” and “gif”. For example, using a TERMS_ETAG of “0”, the structure
could be the following:
- $TERMS_DIR/en/0.pdf
- $TERMS_DIR/en/0.html
- $TERMS_DIR/en/0.txt
- $TERMS_DIR/fr/0.pdf
- $TERMS_DIR/fr/0.html
- $TERMS_DIR/de/0.txt
- TERMS_ETAG
- Basename of the file(s) in the
TERMS_DIR with the current terms of service.
The value is also used for the “Etag” in the HTTP request to control
caching. Whenever the terms of service change, the TERMS_ETAG MUST also
change, and old values MUST NOT be repeated. For example, the date or
version number of the terms of service SHOULD be used for the Etag. If
there are minor (e.g. spelling) fixes to the terms of service, the
TERMS_ETAG probably SHOULD NOT be changed. However, whenever users must
approve the new terms, the TERMS_ETAG MUST change.
- PRIVACY_DIR
- Works the same as
TERMS_DIR, just for the privacy policy.
- PRIVACY_ETAG
- Works the same as
TERMS_ETAG, just for the privacy policy.
EXCHANGE KYC PROVIDER OPTIONS
The following options must be in the section “[kyc-provider-XXX]” sections.
- COST
- Relative cost of the KYC provider, non-negative number.
- LOGIC
- API type of the KYC provider.
- USER_TYPE
- Type of user this provider is for, either INDIVIDUAL or BUSINESS.
- PROVIDED_CHECKS
- List of checks performed by this provider. Space-separated names of checks, must match check names in legitimization rules.
EXCHANGE KYC OAUTH2 OPTIONS
The following options must be in the section “[kyc-provider-XXX]” sections with “LOGIC = oauth2”.
- KYC_OAUTH2_VALIDITY
- Duration (e.g. “12 months”) of the validity of the performed KYC check. Can be “forever”.
- KYC_OAUTH2_AUTH_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/auth” (or “/token”)
- KYC_OAUTH2_LOGIN_URL
- URL of the OAuth2 endpoint to be used for KYC checks. The login URL will be encoded as part of the ‘redirect_uri’ argument of the request to the KYC_AUTH2_AUTH_URL. Typically, the user will then be redirected to this URL to log in. Example: “http://localhost:8888/oauth/v2/login”
- KYC_OAUTH2_INFO_URL
- URL of the endpoint where the OAuth 2.0 token can be used to download the user’s details. The server will use the access token obtained from the KYC_AUTH2_AUTH_URL to show that it is authorized to obtain the details. Example: “http://localhost:8888/api/user/me” or “http://localhost:8888/oauth/v2/info”
- KYC_OAUTH2_CLIENT_ID
- Client ID of the exchange when it talks to the KYC OAuth2 endpoint.
- KYC_OAUTH2_CLIENT_SECRET
- Client secret of the exchange to use when talking to the KYC Oauth2 endpoint.
- KYC_OAUTH2_POST_URL
- URL to which the exchange will redirect the client’s browser after successful authorization/login for the KYC process. Example: “http://example.com/thank-you”
EXCHANGE KYC KYCAID OPTIONS
The following options must be in the section “[kyc-provider-XXX]” sections with “LOGIC = kycaid”.
- KYC_KYCAID_VALIDITY
- Duration (e.g. “12 months”) of the validity of the performed KYC check. Can be “forever”.
- KYC_KYCAID_AUTH_TOKEN
- Authentication token to access the KYC service.
- KYC_KYCAID_FORM_ID
- ID that specifies the form to use for the KYC process.
- KYC_KYCAID_POST_URL
- URL to which the exchange will redirect the client’s browser after successful authorization/login for the KYC process.
EXCHANGE KYC PERSONA OPTIONS
The following options must be in the section “[kyc-provider-XXX]” sections with “LOGIC = persona”.
- KYC_PERSONA_VALIDITY
- Duration (e.g. “12 months”) of the validity of the performed KYC check. Can be “forever”.
- KYC_PERSONA_AUTH_TOKEN
- Authentication token to access the KYC service.
- KYC_PERSONA_SALT
- Salt value to use for request idempotency. Optional, generated at random per process if not given.
- KYC_PERSONA_SUBDOMAIN
- Subdomain to use under Persona.
- KYC_PERSONA_POST_URL
- URL to which the exchange will redirect the client’s browser after successful authorization/login for the KYC process.
- KYC_PERSONA_TEMPLATE_ID
- ID of the Persona template to use.
EXCHANGE KYC PERSONA GLOBAL OPTIONS
The following option must be in the section “[kyclogic-persona]”.
- WEBHOOK_AUTH_TOKEN
- Authentication token Persona must supply to our webhook. This is an optional setting.
EXCHANGE OFFLINE SIGNING OPTIONS
The following options must be in the section “[exchange-offline]”.
- MASTER_PRIV_FILE
- Where to store the offline private key of the exchange.
Mandatory.
- SECM_TOFU_FILE
- Where to store the public keys of both crypto helper modules.
Used to persist the keys after the first invocation of the tool,
so that if they ever change in the future, this is detected and
the tool can abort.
Mandatory.
- SECM_DENOM_PUBKEY
- Public key of the (RSA) crypto helper module. Optional. If not given,
we will rely on TOFU. Note that once TOFU has been established,
this option will also be ignored.
- SECM_ESIGN_PUBKEY
- Public key of the (EdDSA) crypto helper module. Optional. If not given,
we will rely on TOFU. Note that once TOFU has been established,
this option will also be ignored.
EXCHANGE RSA CRYPTO HELPER OPTIONS
The following options must be in the section “[taler-exchange-secmod-rsa]”.
- LOOKAHEAD_SIGN
- How long do we generate denomination and signing keys ahead of time?
- OVERLAP_DURATION
- How much should validity periods for coins overlap?
Should be long enough to avoid problems with
wallets picking one key and then due to network latency
another key being valid. The
DURATION_WITHDRAW period
must be longer than this value.
- SM_PRIV_KEY
- Where should the security module store its long-term private key?
- KEY_DIR
- Where should the security module store the private keys it manages?
- UNIXPATH
- On which path should the security module listen for signing requests?
Note that the taler-exchange-secmod-rsa also evaluates the [coin_*]
configuration sections described below.
EXCHANGE CS CRYPTO HELPER OPTIONS
The following options must be in the section “[taler-exchange-secmod-cs]”.
- LOOKAHEAD_SIGN
- How long do we generate denomination and signing keys ahead of time?
- OVERLAP_DURATION
- How much should validity periods for coins overlap?
Should be long enough to avoid problems with
wallets picking one key and then due to network latency
another key being valid. The
DURATION_WITHDRAW period
must be longer than this value.
- SM_PRIV_KEY
- Where should the security module store its long-term private key?
- KEY_DIR
- Where should the security module store the private keys it manages?
- UNIXPATH
- On which path should the security module listen for signing requests?
Note that the taler-exchange-secmod-cs also evaluates the [coin_*]
configuration sections described below.
EXCHANGE EDDSA CRYPTO HELPER OPTIONS
The following options must be in the section “[taler-exchange-secmod-eddsa]”.
- LOOKAHEAD_SIGN
- How long do we generate denomination and signing keys ahead of time?
- OVERLAP_DURATION
- How much should validity periods for coins overlap?
Should be long enough to avoid problems with
wallets picking one key and then due to network latency
another key being valid. The
DURATION_WITHDRAW period
must be longer than this value.
- DURATION
- For how long should EdDSA keys be valid for signing?
- SM_PRIV_KEY
- Where should the security module store its long-term private key?
- KEY_DIR
- Where should the security module store the private keys it manages?
- UNIXPATH
- On which path should the security module listen for signing requests?
EXCHANGE DATABASE OPTIONS
The following options must be in the section “[exchangedb]”.
- IDLE_RESERVE_EXPIRATION_TIME
- After which time period should reserves be closed if they are idle?
- LEGAL_RESERVE_EXPIRATION_TIME
- After what time do we forget about (drained) reserves during garbage collection?
- AGGREGATOR_SHIFT
- Delay between a deposit being eligible for aggregation and
the aggregator actually triggering.
- DEFAULT_PURSE_LIMIT
- Number of concurrent purses that a reserve may have active
if it is paid to be opened for a year.
EXCHANGE POSTGRES BACKEND DATABASE OPTIONS
The following options must be in section “[exchangedb-postgres]” if the
“postgres” plugin was selected for the database.
- CONFIG
- How to access the database, e.g. “postgres:///taler” to use the
“taler” database. Testcases use “talercheck”.
EXCHANGE ACCOUNT OPTIONS
An exchange (or merchant) can have multiple bank accounts. The following
options are for sections named “[exchange-account-SOMETHING]”. The SOMETHING is
arbitrary and should be chosen to uniquely identify the bank account for
the operator. These options are used by the taler-exchange-aggregator, taler-exchange-closer, taler-exchange-transfer and taler-exchange-wirewatch tools.
- PAYTO_URI
- Specifies the payto://-URL of the account. The general format is
payto://$METHOD/$DETAILS. Examples:
payto://x-taler-bank/localhost:8899/Exchange or
payto://iban/GENODEF1SLR/DE67830654080004822650/ or
payto://iban/DE67830654080004822650/ (providing the BIC is optional).
Note: only the wire-method is actually used from the URI.
- ENABLE_DEBIT
- Must be set to
YES for the accounts that the
taler-exchange-aggregator and taler-exchange-closer should debit.
- ENABLE_CREDIT
- Must be set to
YES for the accounts that the taler-exchange-wirewatch
should check for credits. It is yet uncertain if the merchant
implementation may check this flag as well.
Additionally, for each enabled account there MUST be another matching section named “[exchange-accountcredentials-SOMETHING]”. This section SHOULD be in a secret/ configuration file that is only readable for the taler-exchange-wirewatch and taler-exchange-transfer processes. It contains the credentials to access the bank account:
- WIRE_GATEWAY_URL
- URL of the wire gateway. Typically of the form
https://$HOSTNAME[:$PORT]/taler-wire-gateway/$USERNAME/
where $HOSTNAME is the hostname of the system running the bank
(such as the Taler Python bank or the Nexus) and $USERNAME is
the username of the exchange’s bank account (usually matching
the USERNAME option used for authentication). Example:
https://bank.demo.taler.net/taler-wire-gateway/Exchange/.
- WIRE_GATEWAY_AUTH_METHOD
- This option determines how the exchange (auditor/wirewatch/aggregator)
authenticates with the wire gateway. Choices are
basic and none.
- USERNAME
- User name for
basic authentication with the wire gateway.
- PASSWORD
- Password for
basic authentication with the wire gateway.
EXCHANGE COIN OPTIONS
The following options must be in sections starting with "[coin_]" and are
largely used by taler-exchange-httpd to determine the meta data for the
denomination keys. Some of the options are used by the
taler-exchange-secmod-rsa to determine which RSA keys to create (and of
what key length). Note that the section names must match, so this part of the
configuration MUST be shared between the RSA helper and the exchange.
Configuration values MUST NOT be changed in a running setup. Instead, if
parameters for a denomination type are to change, a fresh section name should
be introduced (and the existing section should be deleted).
- VALUE
- Value of the coin, e.g. “EUR:1.50” for 1 Euro and 50 Cents (per
coin).
- DURATION_WITHDRAW
- How long should the same key be used for clients to withdraw coins of
this value?
- DURATION_SPEND
- How long do clients have to spend these coins?
- DURATION_LEGAL
- How long does the exchange have to keep records for this denomination?
- FEE_WITHDRAW
- What fee is charged for withdrawal?
- FEE_DEPOSIT
- What fee is charged for depositing?
- FEE_REFRESH
- What fee is charged for refreshing?
- FEE_REFUND
- What fee is charged for refunds? When a coin is refunded, the deposit
fee is returned. Instead, the refund fee is charged to the customer.
- CIPHER
- What cryptosystem should be used? Must be set to either “CS” or “RSA”.
The respective crypto-helper will then generate the keys for this
denomination.
- RSA_KEYSIZE
- What is the RSA keysize modulos (in bits)? Only used if “CIPHER=RSA”.
MERCHANT OPTIONS
The following options are from the “[merchant]” section and used by the
merchant backend.
- DB
- Plugin to use for the database, e.g._“postgres”.
- PORT
- Port on which the HTTP server listens, e.g. 8080.
- LEGAL_PRESERVATION
- How long do we keep data in the database for tax audits after the
transaction has completed? Default is 10 years.
- FORCE_AUDIT
- Force the merchant to report every transaction to the auditor
(if the exchange has an auditor)? Default is
NO.
Do not change except for testing.
MERCHANT POSTGRES BACKEND DATABASE OPTIONS
The following options must be in section “[merchantdb-postgres]” if the
“postgres” plugin was selected for the database.
- CONFIG
- How to access the database, e.g. “postgres:///taler” to use the
“taler” database. Testcases use “talercheck”.
KNOWN EXCHANGES (for merchants)
The merchant configuration can include a list of known exchanges if the
merchant wants to specify that certain exchanges are explicitly trusted.
For each trusted exchange, a section [merchant-exchange-$NAME] must exist, where
$NAME is a merchant-given name for the exchange. The following options
must be given in each “[exchange-$NAME]” section.
- EXCHANGE_BASE_URL
- Base URL of the exchange, e.g. “https://exchange.demo.taler.net/”
- MASTER_KEY
- Crockford Base32 encoded master public key, public version of the
exchange’s long-time offline signing key. Can be omitted, in that
case the exchange will NOT be trusted unless it is audited by
a known auditor.
Omitting
MASTER_KEY can be useful if we do not trust the exchange
without an auditor, but should pre-load the keys of this
particular exchange on startup instead of waiting for it to be
required by a client.
- CURRENCY
- Name of the currency for which this exchange is used, e.g. “KUDOS”.
The entire section is ignored if the currency does not match the currency
we use, which must be given in the
[taler] section.
KNOWN AUDITORS (for merchants)
The merchant configuration can include a list of known exchanges if the
merchant wants to specify that certain auditors are explicitly trusted.
For each trusted exchange, a section “[merchant-auditor-$NAME]” must exist, where
$NAME is a merchant-given name for the auditor. The following options
must be given in each “[merchant-auditor-$NAME]” section.
- AUDITOR_BASE_URL
- Base URL of the auditor, e.g. “https://auditor.demo.taler.net/”
- AUDITOR_KEY
- Crockford Base32 encoded auditor public key.
- CURRENCY
- Name of the currency for which this auditor is trusted, e.g. “KUDOS”
The entire section is ignored if the currency does not match the currency
we use, which must be given in the
[taler] section.
AUDITOR OPTIONS
The following options must be in section “[auditor]” for the Taler
auditor.
- DB
- Plugin to use for the database, e.g. “postgres”
- AUDITOR_PRIV_FILE
- Name of the file containing the auditor’s private key.
- PUBLIC_KEY
- Crockford Base32 encoded auditor public key. Used by (online) auditor
processes that do not have access to the (offline) auditor private key file.
- BASE_URL
- Base URL of the auditor, e.g. “https://auditor.demo.taler.net/”
AUDITOR POSTGRES BACKEND DATABASE OPTIONS
The following options must be in section “[auditordb-postgres]” if the
“postgres” plugin was selected for the database.
- CONFIG
- How to access the database, e.g. “postgres:///taler” to use the
“taler” database. Testcases use “talercheck”.
Bank Options
The following options must be in section “[bank]” for the taler-fakebank-run(1) command. They are not used by the exchange or LibEuFin!
- HTTP_PORT
- On which TCP port should the (fake)bank offer its REST API.
- RAM_LIMIT
- This gives the number of transactions to keep in memory. Older transactions will be overwritten and history requests for overwritten transactions will fail.