Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ Each BCIP should provide a concise technical specification of the feature and a
| [BCIP-0002](bcip-0002.md) | Atomic Swaps | Standard | Draft |
| [BCIP-0003](bcip-0003.md) | Wallet Key | Standard | Accepted |
| [BCIP-0302](bcip-0302.md) | Registered identity types | Standard | Draft |
| [BCIP-0004](bcip-0004.md) | NFC Payment Solution | Standard | Draft |

---

Expand Down
85 changes: 85 additions & 0 deletions bcip-0004.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# BCIP-0004 : NFC Payment Solution

```
Number: BCIP-0004
Title: NFC Payment Solution
Type: Informational
Status: Draft
Authors: Blockcore <post@blockcore.net>
Created: 2023-09-19
```

## Abstract

This is a proposed solution for NFC payments using Blockcore.

NFC has primarily two modes, read/write data and authentication. The common NFC payment solutions are using the authentication mode, where the NFC card is used to authenticate the user and the payment is done using a different channel. Your regular payment cards from fiat banks are using this mode. The authentication mode is not suitable for Blockcore payments, because it requires a central authority to issue the cards and to verify the authentication.

While such a solution could be implemented, it requires a central authority (custodial wallet service) to issue the cards and to verify the authentication. This is not a solution that Blockcore will support, but it is possible to implement such a solution on top of Blockcore for anyone who wants to do that.

## Motivation

NFC payments are a convenient way to pay for goods and services. It is a technology that is widely adopted and supported by most modern smartphones. It is also a technology that is widely used in payment terminals in stores and restaurants, or for festivals and events.

Making use and adoption of Bitcoin and other cryptocurrencies is a challenge, because it is not widely supported by payment terminals. The NFC payment solution will allow Blockcore to be used for smaller amounts, such as paying for a coffee or a beer at a festival.

## Body

The deployment of NFC payment solution requires the following infrastructure:

- Blockcore Payment Server
- NFC Payment Terminal
- NFC Payment Card
- Blockcore Wallet (optional)

The proposed solution requires the private key to be stored on the physical NFC card. This will be the same private key for all payments, until the user decides to wipe/rewrite their private key. For privacy reasons, it is recommended to wipe the private key after some usage, such as after a day or a week or events.
Comment thread
sondreb marked this conversation as resolved.

The private key is written to the NFC card with encryption. It can be written multiple times, depending on which merchants the user want to utilize their NFC cards at. It is the users of the cards that decides who will be able to read the private key from the card.

During the writing process, user can decide to add an additional security layer in the form of a private PIN code. This must then be provided for each payment performed.

To activate an NFC card, the user can start the process within their Blockcore Wallet. When creating an new card, a private key will be derived from the current root private key under an hardened path. This means that cards follow the user wallets, for restore and backup purposes.

`m / purpose' / coin_type' / account' / change / address_index`

Purpose 44 is used for regular wallet key derivation, for NFC cards the purpose will be 423. Coin type will follow which chain the NFC card is used for, such as 0 for Bitcoin, see [SLIP-44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) for more information on all coint types.

"change" and "address_index" will always be 0, but the full derivation are used for potential future expansion where additional keys for each card might be used.

When creating a card within the wallet, the user can also pick which decentralized identity to attach to it (or none at all). This will allow the user to verify that they are the owner of the funds on the card, in case of an NFC cloning operation.

NFCs are not secure, they can be cloned and the private key can be extracted from the card. The private key will be stored encrypted with the public key of the merchants that the payeer want to use their card with.

That means that the owner of the card, decides who can actually decrypt their private key. Even if someone clones the card, they will still only be able to use the card with the pre-approved merchant, which can disable the card if they suspect that the card has been cloned.

The card can be used for identification and payment. The identification is used to verify membership, etc.

### 1. Safety and Value Amounts

Since the security of the NFC card payment solution is not as strong as a hardware wallet, it is recommended to only use the card for smaller amounts. The NFC card can be used for identification and payment, but it is recommended to use a hardware wallet for larger amounts.

### 2. Public Key Discovery

Comment thread
sondreb marked this conversation as resolved.
The public key of merchants should be published within the decentralized identity document (DID Document) of the merchant. This will allow the user to discover the public key of the merchant, and to encrypt the private key on the card with the public key of the merchant.

Additionally stores can post their public key on their website, or in their store, to allow customers to encrypt their private key with the public key of the merchant the store supports. This will then be a one-time operation the first time.

### 3. Anonymous Pre-Created Cards

The solution also supports event organizers to pre-create cards for their event. This will allow the event organizer to create a card for each ticket holder, and to pre-load the card with a certain amount of funds. This will allow the ticket holders to use the card for payments at the event, and to use the card for identification (can be anonymous, like a ticket identification number).
Comment thread
sondreb marked this conversation as resolved.

### 4. Card Fill Up

Cards can be filled up with funds by the user, or by the merchant. The merchant can fill up the card with funds, and the user can fill up the card with funds from their own wallet, like Blockcore Wallet.

The address of the card can be printed on the card using QR-code for quick and easy fill-up.

## Considerations

Should the identity be stored unencrypted on the card and be readable by everyone, or should the user have option to encrypt it? Perhaps it can be a user-choice?

That means I can identity with the card, but I don't need to give merchant access to perform payments on my behalf.

## References

This is a section for references such as links to other documents or to reference implementations.