Topic: Extending the Payment Protocol with vCards - page 2. (Read 9664 times)
Perfect timing on this.
This post describes a method by which users of Bitcoin wallets can exchange contact information as an extension of the Payment Protocol to improve the experience of sending bitcoins between non-merchant users. This represents a request-for-comment from the Bitcoin community and all feedback is appreciated.
As you may know, BIP 70-72 will be included in the next major release of the Satoshi client (Bitcoin-QT). However, this functionality is squarely aimed at merchants creating PaymentRequests. Mike Hearn eventually posted a "FAQ on the Payment Protocol" thread which included this subsequent question/answer:
So what happens if Bob wants to send Alice a payment that Alice didn't specifically issue a PaymentRequest for? As Mike outlined, Alice should have a PaymentRequest dangling out on the internet somewhere that Bob can fulfill. However, because Bob met Alice at a Bitcoin meetup and they didn't previously know each other very well, wouldn't it be nice if Bob could transmit some additional information aside from the name on his SSL certificate? What if Bob wants Alice to have some additional information about him, such as a telephone number or photo?
vCard is a standard that works to fulfill the need of exchanging a "virtual business card" and BIP 0070 defines how extensibility should work:
Therefore, I suggest it be reasonable to include optional vCard data as an extra field in Payment and PaymentACK. While there may not be a concrete use-case for merchants to leverage this field, users performing user-to-user transactions via Payment Protocol may find it helpful to be able to optionally attach extra personal information, especially when paying a person for the first time. Subsequently, should Alice wish to share her contact details with Bob, she can respond with a PaymentACK, including a similar optional vcard field.
Wallet software can be made aware of this "vcard" field and make use of the data directly or launch an appropriate application on that platform which can handle vCards, such as a contact/email/calendar software. The end result of this is that the Payment Protocol becomes much more useful for user-to-user payments, since user-consumable information can be exchanged at their discretion.
In my eyes, to make this workable, several outstanding issues would need to be addressed:
What if Alice wants to initiate a PaymentRequest to Bob to pay him back for lunch? Could/should a vCard be included then?
Yes, maybe, I don't know. I could make an argument for an optional vcard field at each step of the process, depending where it's initiated from.
Won't this lead to everyone including vCards for everything?
Yes, maybe, I don't know. Wallet software could maintain an association of identities/vCards to limit extraneous data sharing or default sharing to "off", however it would always be up to the user to indicate when he wants information shared.
How will Alice know that the payment request from Bob is from the correct Bob?
This is a very complicated topic to answer and BIP 70 has so far only described identity/security through PKI. However, Peter Todd made a post entitled "Adding OpenPGP to the payment protocol" which describes how to implement the Payment Protocol with PGP/GPG. Following his guidance would allow the simple exchange of a short 8-charcter PGP key in-person. When Alice receives Bob's encrypted Payment, her wallet software (not already having Bob's key) could prompt her for Bob's PGP key, which could then be retrieved from a PGP keyserver. Because this PGP key was exchanged out-of-band (i.e. in person), it would provide sufficient personal identity verification.
Why not send the vCard separate from the Payment Request?
Ease-of-use, primarily. For wallets already implementing the Payment Protocol, vCard support would be simple awareness and decoding of a single extra field. No need to bundle it up into a separate file. Additionally, being a part of Payment Protocol would allow the information to be transmitted "on the wire" instead of having to relay a separate physical file.
vCard has a lot of formats. Which one should be implemented?
I'm not a vCard expert, but I'd be partial to the JSON-encoded representation, known as jCard. I have no idea what the compatibility matrix looks like between versions and consuming software.
As you may know, BIP 70-72 will be included in the next major release of the Satoshi client (Bitcoin-QT). However, this functionality is squarely aimed at merchants creating PaymentRequests. Mike Hearn eventually posted a "FAQ on the Payment Protocol" thread which included this subsequent question/answer:
Quote
How will non-shopkeepers create payment requests?
Today the payment request system is intended for online shops and payment processors like BitPay. Gavin wrote some PHP that can be used to generate and serve the signed requests server side.
But in future wallets might create payment requests for their users too. On Android this will be a seamless upgrade - the QRcodes people scan today will start including Bluetooth MAC addresses and the protocol will run over that. We've already got a prototype launched in the Play Store that doesn't use BIP70 but something much more primitive. No pairing is involved, the user experience is seamless.
On the desktop you'd probably fill out a form in your wallet GUI (for the price, the memo, etc) and then drag and drop an icon onto an email you're composing, IM window, web form etc. Anywhere that lets you transfer files basically. The request would be sent to the other side and opened by their wallet.
For signing, anyone can get X.509 certs for an email address for free from StartSSL. It's not super convenient to sign up, but there's no technical reason it can't be just one or two clicks. Once you got a certificate, most operating systems have a "key store" function built in which will let you install the certificate and encrypt your private key for you, often linked to whether the screen is unlocked or not. Android does this as well. Wallets can then talk to the OS to get the key needed for signing.
For receiving asynchronous payments that you didn't explicitly request, I think we'll see web sites pop up that host payment request files for you. Whenever you receive money via the uploaded request your wallet would notice and then upload a fresh one. This would be useful for tips, etc, that currently leak a lot of private data.
Today the payment request system is intended for online shops and payment processors like BitPay. Gavin wrote some PHP that can be used to generate and serve the signed requests server side.
But in future wallets might create payment requests for their users too. On Android this will be a seamless upgrade - the QRcodes people scan today will start including Bluetooth MAC addresses and the protocol will run over that. We've already got a prototype launched in the Play Store that doesn't use BIP70 but something much more primitive. No pairing is involved, the user experience is seamless.
On the desktop you'd probably fill out a form in your wallet GUI (for the price, the memo, etc) and then drag and drop an icon onto an email you're composing, IM window, web form etc. Anywhere that lets you transfer files basically. The request would be sent to the other side and opened by their wallet.
For signing, anyone can get X.509 certs for an email address for free from StartSSL. It's not super convenient to sign up, but there's no technical reason it can't be just one or two clicks. Once you got a certificate, most operating systems have a "key store" function built in which will let you install the certificate and encrypt your private key for you, often linked to whether the screen is unlocked or not. Android does this as well. Wallets can then talk to the OS to get the key needed for signing.
For receiving asynchronous payments that you didn't explicitly request, I think we'll see web sites pop up that host payment request files for you. Whenever you receive money via the uploaded request your wallet would notice and then upload a fresh one. This would be useful for tips, etc, that currently leak a lot of private data.
So what happens if Bob wants to send Alice a payment that Alice didn't specifically issue a PaymentRequest for? As Mike outlined, Alice should have a PaymentRequest dangling out on the internet somewhere that Bob can fulfill. However, because Bob met Alice at a Bitcoin meetup and they didn't previously know each other very well, wouldn't it be nice if Bob could transmit some additional information aside from the name on his SSL certificate? What if Bob wants Alice to have some additional information about him, such as a telephone number or photo?
vCard is a standard that works to fulfill the need of exchanging a "virtual business card" and BIP 0070 defines how extensibility should work:
Quote
The protocol buffers serialization format is designed to be extensible. In particular, new, optional fields can be added to a message and will be ignored (but saved/re-transmitted) by old implementations.
PaymentDetails messages may be extended with new optional fields and still be considered "version 1." Old implementations will be able to validate signatures against PaymentRequests containing the new fields, but (obviously) will not be able to display whatever information is contained in the new, optional fields to the user.
PaymentDetails messages may be extended with new optional fields and still be considered "version 1." Old implementations will be able to validate signatures against PaymentRequests containing the new fields, but (obviously) will not be able to display whatever information is contained in the new, optional fields to the user.
Therefore, I suggest it be reasonable to include optional vCard data as an extra field in Payment and PaymentACK. While there may not be a concrete use-case for merchants to leverage this field, users performing user-to-user transactions via Payment Protocol may find it helpful to be able to optionally attach extra personal information, especially when paying a person for the first time. Subsequently, should Alice wish to share her contact details with Bob, she can respond with a PaymentACK, including a similar optional vcard field.
Wallet software can be made aware of this "vcard" field and make use of the data directly or launch an appropriate application on that platform which can handle vCards, such as a contact/email/calendar software. The end result of this is that the Payment Protocol becomes much more useful for user-to-user payments, since user-consumable information can be exchanged at their discretion.
In my eyes, to make this workable, several outstanding issues would need to be addressed:
What if Alice wants to initiate a PaymentRequest to Bob to pay him back for lunch? Could/should a vCard be included then?
Yes, maybe, I don't know. I could make an argument for an optional vcard field at each step of the process, depending where it's initiated from.
Won't this lead to everyone including vCards for everything?
Yes, maybe, I don't know. Wallet software could maintain an association of identities/vCards to limit extraneous data sharing or default sharing to "off", however it would always be up to the user to indicate when he wants information shared.
How will Alice know that the payment request from Bob is from the correct Bob?
This is a very complicated topic to answer and BIP 70 has so far only described identity/security through PKI. However, Peter Todd made a post entitled "Adding OpenPGP to the payment protocol" which describes how to implement the Payment Protocol with PGP/GPG. Following his guidance would allow the simple exchange of a short 8-charcter PGP key in-person. When Alice receives Bob's encrypted Payment, her wallet software (not already having Bob's key) could prompt her for Bob's PGP key, which could then be retrieved from a PGP keyserver. Because this PGP key was exchanged out-of-band (i.e. in person), it would provide sufficient personal identity verification.
Why not send the vCard separate from the Payment Request?
Ease-of-use, primarily. For wallets already implementing the Payment Protocol, vCard support would be simple awareness and decoding of a single extra field. No need to bundle it up into a separate file. Additionally, being a part of Payment Protocol would allow the information to be transmitted "on the wire" instead of having to relay a separate physical file.
vCard has a lot of formats. Which one should be implemented?
I'm not a vCard expert, but I'd be partial to the JSON-encoded representation, known as jCard. I have no idea what the compatibility matrix looks like between versions and consuming software.
Jump to: