Questions and answers
What's the point of digital checks?
Digital checks have several very useful properties.
You can write a check on a computer which is not connected to the Internet, hence your passphrase and your money are more secure.
You can put a check in the purchase webform of an online shop. You don't have to send the check to the payment service, the shop does it and receives back a confirmation (so, you don't have to prove the payment, and no shop clerk has to verify the payment - it's all automated). You may also be able to more efficiently hide your IP address from the payment service, since you need to access it less.
Checks can be sent to the payment service through any mean of communication, like SMSs (axiomatic tokens for payments are generally 95 characters long, so they fit nicely in the 160 characters limit for SMSs).
Payment services can be more resilient to DDOS attacks. The service can setup any number of public proxies which send tokens to the (hidden) service.
How should I choose my passphrase?
It is crucial to choose it as it is recommended in the documentation of AxiomaticTokenizer.
Can AxiomaticTokenizer be deployed on an existing online payment service?
Yes. It's a generic system. However, this is only the client side, the user interface. An online payment service has to implement the server side, that is, code which parses the incoming tokens and executes the requested actions in the database.
See this for details.
May I put a "Make payment" token in the purchase form of a shopping website?
I have seen some proxy websites which send tokens to the service, to help mitigate DDOS attacks. May I send a token through such a proxy?
I am not sure that my last payment was actually made. Can I generate a new token with the same payment information?
No! Just resend the same token until you receive an execution proof from the service. If you receive the "Success" execution proof, it's guaranteed that the payment was successfully executed.
DO NOT generate another token with the same payment information unless you want to make a new payment.
For some reason, a token which I generated an hour ago didn't reach the service; or it might have, but I am not sure. How can I ensure that it's ignored if it eventually reaches the service?
Generate another token (for example, for login) and send it to the service (until you receive an execution proof from the service). If you receive from the service either a "Success" or a "LastExecuted" execution proof, the older token will not be executed if it reaches the service afterwards.
What information is saved by AxiomaticTokenizer in order to later access an account?
None. AxiomaticTokenizer is stateless, that is, it requires no saved information in order to access an account. The user must remember or store his account names and passphrases.
If a device with AxiomaticTokenizer is lost, all the accounts of its owner can still be accessed with another device.
A user may choose to have various account names saved by AxiomaticTokenizer.
How can I not remember a passphrase?
Choose your passphrase as recommended in the documentation of AxiomaticTokenizer.
If you think it's necessary to not let anyone get your digital currency, burn or swallow the paper on which the passphrase is written.
I have a secret account. Because its secret, its passphrase is not backed up anywhere. How can I make sure that I will not lose the money I have in it if I forget its passphrase?
For this account, add as inheritor a public account whose passphrase you have backed up.
If you happen to forget the passphrase of the secret account, when this enters in inheritance mode, all the digital currency from it will be moved to your inheritor public account.
Is it possible for someone to mount a brute force attack against my passphrase?
Generally, yes because either you send your tokens to various entities, like online shops who can mount an attack based on the token integrity code, or you pay someone who can mount an attack based on the token reference code (which is saved by the service in the recipient's account).
This is why it's critical that you choose your passphrases as recommended in the documentation of AxiomaticTokenizer.
In order to further protect yourself, always hold most of your digital currency in secret accounts which have passphrases different than your public accounts. This way, your tokens don't reach another entity.
There is absolutely no amount of security (provider-based, user-level hardware, etc...) that can overcome the user's willingness to hand over access to a social engineering con artist.
The purpose of AxiomaticTokenizer is to offer a technological solution to people who want to protect their money inside the money issuer.
What people choose to do with their money is their choice, not for AxiomaticTokenizer to police.
The passphrases are not secure enough because I can't type small and big letters, and special characters like "!@#$%^&*()".
Having a pool with more characters is not more secure, but it can create shorter passphrases with the same strength.
The strength of a passphrase is proportional with the number of combinations which can be made with the pool of characters from which a passphrase is made.
A given number of combinations can be achieved with a pool of any number of characters. What makes the difference is the size of the passphrase.
Having a shorter passphrase might appear more practical, but a passphrase must also be typed. If only alphanumeric characters are used, it's much easier to write a passphrase, so this compensates for the bigger size.
17 characters taken from a pool of 72 characters give about the same number of combinations as 20 characters taken from a pool of 36 characters; actually, it's 3 times more combinations. So, for just 3 characters less the user would have to use the Shift key, on average, 8.5 times, plus search on the keyboard the special characters.
Moreover, non alphanumeric characters have a tendency to create problems with remembering. Sometimes people accidentally type special characters in their passphrases, even twice. Capitalization is also a problem.