Transactions
The system should support the following kinds of transactions:
- Invalidate CODE: if CODE is valid and the transaction succeeds, CODE becomes invalid.
- Activate CODE [PIN|PUBKEY]: Activates the account using activate code, CODE. If PIN is present, it is associated with the account and subsequent transactions will require the PIN. If PUBKEY is specified, it is associated with the account and subsequent transactions are allowed only if they occur over an SSL/TLS session using the key.
- Initialize INITCODE DEBITCODE VALUE: Transfers VALUE amount from DEBITCODE to INITCODE to initialize the card. INITCODE then becomes invalid.
Transfer DEPOSITCODE DEBITCODE VALUE FEE: Transfers VALUE amount from DEBITCODE to DEPOSITCODE and debits FEE from DEBITCODE. If FEE is insufficient, the transaction fails with a RequiresFee FEE2 result, where FEE2 is the minimum required fee amount.
- TODO: Guarantee that the ibank or client can determine the proper fee amount before beginning a transaction. Should banks be allowed to have more than one fee structure for intra-bank transfers? How could we represent such fee structures? Should intra-bank transfers be free? State exactly what it means when a bank refuses a previously agreed-upon fee and demands a higher fee.
Purchase DEBITCODE FEE CODELIST: allow the client to purchase codes with the specified characteristics. If the fee is insufficient, the transaction fails with a RequiresFee FEE2 result, where FEE2 is the minimum required fee amount. If a specified combination of characteristics is not supported, no new codes are issued, and a list of invalid codes is returned, with an error code and explanation for each. If the transaction succeeds, FEE amount is deducted from the account associated with DEBITCODE, new random codes are generated, tagged with the specified characteristics, and associated with the same account as DEBITCODE.
- TODO: figure out a good way to represent the list of characteristics, the fee structure for new codes, and error feedback. Look into techniques used in Semantic Web research.
Authentication
The protocol occurs over an SSL/TLS connection. When the client initiates the connection, it may use a private key to authenticate itself to the server. If the client tries to access an account with a public key associated with it, the client must have previously set up the TLS connection using the corresponding private key.
Every account may have a PIN associated with it. The PIN must prefix every command issued against the account. The purpose of the PIN is to prevent physical attacks on the card. For example, if someone steals your card or takes a photograph of the debit codes, they still need your PIN withdraw the money.
This highlights the need for a software client. If you use a client, the client can retrieve a new, non-PIN'ed, debit code for each transaction, and keep your PIN secret. But if you purchase on a website by entering your debit code and PIN number, then the merchant gets your PIN. An evil or hacked merchant could deliver your debit code & PIN to criminals. The criminals can capture your debit codes by camera and store them in a database. Then they just wait for you to make a purchase with one of the codes at a hacked website. They look up the debit code in their database to find your other debit codes, which were stolen via camera. All of your debit codes have the same PIN, so they find which codes are unused and then make purchases with them. I hope that clients will become popular before criminals become sophisticated enough to perform this attack. Cards will need special features to prevent photographic theft of codes.
- ["MisterN"]: Wouldn't it be better to attach a randomized cryptographic hash of the PIN instead of the PIN itself?
TODO: add PINs to HTTP 402 Protocl Extension