Author: Chris Stewart 2019-07-05 00:37:19
Published on: 2019-07-05T00:37:19+00:00
The discussion revolves around a proposal made by Nadav, which suggests including an extension field that allows the merchant to include a Zero-Knowledge Proof (ZKP) for ZKCP-compatible data transfers. The proposed scheme aims at reducing the client-server interaction for REST APIs while ensuring payment to the merchant. Without this scheme, the workflow involves four steps: the client sends a request to the server for invoice, the server returns the invoice, the client pays the invoice and the server sends data back or the client makes another request to the server for data. However, with Nadav's scheme, the process is simplified as the server returns the invoice along with encrypted payload in response to the client's request, the client pays the invoice and decrypts data according to Nadav's scheme. This saves a round trip between the server and client and gives atomicity to the transaction, but there are no guarantees about the integrity of the encrypted data. To solve this, MAC can be placed inside the encryption so that data replacement over an insecure channel can be detected, and the use of shared secret ensures only the intended recipient can decrypt it. While this scheme adds complexity without any meaningful guarantee to the customer, it can be useful for the edge case where a customer wants to pre-download the data before paying but still trusts the merchant. There may be a higher-level abstraction to be standardized that would handle more mainstream use-cases.
Updated on: 2023-06-02T19:03:51.865842+00:00