On Wed, Jul 8, 2015 at 9:53 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:
> I think we want to support wallets in any form (native app, hosted on the
> Web, or built into the browser or OS) but we want to standardise the
> messages that wallets will receive to initiate and confirm/complete a
> payment and the responses they are expected to send back.
I agree. Recently, I've been trying to simplify the way I talk to people
about payments by using terminology and analogies that everyone
understands, such as comparing wallets to email as a
container/sender/receiver of transactions, and comparing transactions to
messages about money. Then, using a JWT format, the simplest way I found to
represent those messages was:
{
"header": {
"alg": ""
},
"payload": {
"sub": "",
"aud": "",
"amt": 0,
"iou": "",
"iat": ""
},
"signature": ""
}
where "sub" is the transaction source/sender (a URI), "aud" the transaction
destination/receiver (a URI), "amt" (non-standard) the transaction amount,
"iou" (non-standard) the transaction currency/IOU, and "iat" a timestamp
that indicates when the document was signed.
Regarding payment initiation, whoever wants to initiate the payment would
sign this JWT and *send it to the other party* (e.g. P2P, QR code, or via a
server), which in turn would have to *sign it and send it back* as a proof
of consent for receiving those funds. At the end of the payment initiation
flow both parties would have JWTs with each other's signatures, and then
the payment execution flow could be triggered by sending the signed JWTs to
the payment processor.
Jorge Zaccaro
Fundador, Playbanq SAS
Bogotá D.C., Colombia
+57 300 673 0039
Received on Wednesday, 8 July 2015 16:15:32 UTC