|WARNING: The Request encryption mechanism is still under audit, use it at your own risk!|
|WARNING: Manipulate private keys must be done with care, losing them can lead to a loss of data and privacy!|
A request can be encrypted in order to make its details private to selected stakeholders. In this guide, we won't explain how encryption is managed under the hood. We will mention encryption or decryption of requests with payers' and payee's keys, wherein the reality we use an intermediate symmetric key. See more details on github
The encryption is managed by the transaction layer, see more details on the Request Protocol section.
To manipulate encrypted request you need a Decryption Provider, e.g:
- Ethereum Private Key Decryption Provider (provided by Request for illustration), using directly the private keys. This provider manipulates private keys in clear, which is not completely secure. Please consider creating your own, see below.
- A browser extension is under development
Create an encrypted request
Ethereum Private Key Decryption Provider (see on github)
Then you can create an encrypted request:
Note: You must give at least one encryption key you can decrypt with the decryption provider. Otherwise, an error will be triggered after the creation.
Get invoice information from its request ID
Let's step back for a second: the requester sent a request that he encrypted with the payer's public key, as well as with his own, in order to retrieve it later. This is a basic and typical example, but a request can be encrypted with many keys, in order to give access to its status and details.
If the decryption provider knows a private key matching one of the keys used at the creation, it can decrypt it. Like a clear request you will be able to get it from its request id a request.
Accepting/cancelling an invoice information
Like a clear request, you will be able to update it if the decryption provider is instantiated with a matching private key.