1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YL7wN-0005mN-IQ
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Feb 2015 10:21:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.179 as permitted sender)
client-ip=74.125.82.179; envelope-from=natanael.l@gmail.com;
helo=mail-we0-f179.google.com;
Received: from mail-we0-f179.google.com ([74.125.82.179])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YL7wL-0006mY-Tq
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Feb 2015 10:21:11 +0000
Received: by mail-we0-f179.google.com with SMTP id u56so27060847wes.10
for <bitcoin-development@lists.sourceforge.net>;
Tue, 10 Feb 2015 02:21:03 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.172.35 with SMTP id az3mr51270504wjc.43.1423563663777;
Tue, 10 Feb 2015 02:21:03 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 02:21:03 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 02:21:03 -0800 (PST)
In-Reply-To: <CAAt2M18H0K99bmD4H_FRSeE+O9nGFDruCmo63GOQt1kxAdVBmQ@mail.gmail.com>
References: <CAAt2M18H0K99bmD4H_FRSeE+O9nGFDruCmo63GOQt1kxAdVBmQ@mail.gmail.com>
Date: Tue, 10 Feb 2015 11:21:03 +0100
Message-ID: <CAAt2M188whrv9VgV8UYBq+kcmgN9b6QQH7+wd7wQYNj8bd4Pcg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e0122e8b67ea84e050eb93ea0
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YL7wL-0006mY-Tq
Subject: [Bitcoin-development] Standardizing automatic pre-negotiation of
transaction terms with BIP70? (Emulating Amazon one-click purchase at all
merchants)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 10 Feb 2015 10:21:11 -0000
--089e0122e8b67ea84e050eb93ea0
Content-Type: text/plain; charset=UTF-8
BIP70 is a protocol for getting a user's wallet client communicate with a
merchant's server in order to agree on details like where to send the
payment, how much to send, what the shipping address is, sending a receipt
back, and much more using various extensions that adds more functionality.
There could even be advanced functionality for automatically negotiating
terms. One example could be selecting a multisignature arbitrator both
sides trust. Another could be to agree on the speed and type of delivery.
Many more types of decisions could be automatically agreed upon.
But as it is now, it is designed to be initiated at the time of payment. If
you always want next-day delivery from online stores then you won't always
know if that's an option until you've filled the digital basket and gone
through checkout. If you only want to shop with an arbitrator involved same
thing applies.
Everything that BIP70 enables happens at the last step only, as it is right
now.
If there could be a BIP70 HTML tag on web shops that automatically
triggered your wallet as soon as you visit the page, it would be possible
for a browser extension that talks to your wallet to tell you right away if
the web shop you're currently looking at has terms you consider acceptable
or not (note: if your wallet client isn't installed on or linked to that
same machine, a visible Qr code would be an acceptable alternative which
you can scan in advance before you start shopping). This notification can
even be automatically updated as you add and remove things from your cart
and details like shipping options change.
This would massively simplify the shipping experience and make every web
shop feel like Amazon.
Of course this has privacy implications and increases exposure to potential
wallet exploits, but the wallet can ask you if you intend to shop or not at
each site before it even connects and send any information at all in order
to mitigate both of those problems. This way it should be reasonably safe.
Another option would be to automatically connect but limit what data is
sent in order to remain privacy preserving, until the user agrees to send
private information.
This second method would also open up for the merchant to other send
relevant information such as details about various certifications from
third parties, which can include a certification that shows they have been
been audited and approved by by entity X for purpose Y. If your wallet has
that entity whitelisted it will show you that certificate (for example
"Acme Audits have audited and approves of Merchant M's privacy policy and
data protection"). With a list of predefined types of certifications that
the wallet understand and accepts, it could (by choice of the user) require
a certificate to be present to even allow you to make a purchase (lack of
required certifications would result in automatic denial). No certificate =
your wallet never proceed to send private information.
Thoughts?
- Sent from my tablet
--089e0122e8b67ea84e050eb93ea0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">BIP70 is a protocol for getting a user's wallet client c=
ommunicate with a merchant's server in order to agree on details like w=
here to send the payment, how much to send, what the shipping address is, s=
ending a receipt back, and much more using various extensions that adds mor=
e functionality.</p>
<p dir=3D"ltr">There could even be advanced functionality for automatically=
negotiating terms. One example could be selecting a multisignature arbitra=
tor both sides trust. Another could be to agree on the speed and type of de=
livery. Many more types of decisions could be automatically agreed upon. </=
p>
<p dir=3D"ltr">But as it is now, it is designed to be initiated at the time=
of payment. If you always want next-day delivery from online stores then y=
ou won't always know if that's an option until you've filled th=
e digital basket and gone through checkout. If you only want to shop with a=
n arbitrator involved same thing applies.</p>
<p dir=3D"ltr">Everything that BIP70 enables happens at the last step only,=
as it is right now. </p>
<p dir=3D"ltr">If there could be a BIP70 HTML tag on web shops that automat=
ically triggered your wallet as soon as you visit the page, it would be pos=
sible for a browser extension that talks to your wallet to tell you right a=
way if the web shop you're currently looking at has terms you consider =
acceptable or not (note: if your wallet client isn't installed on or li=
nked to that same machine, a visible Qr code would be an acceptable alterna=
tive which you can scan in advance before you start shopping). This notific=
ation can even be automatically updated as you add and remove things from y=
our cart and details like shipping options change. </p>
<p dir=3D"ltr">This would massively simplify the shipping experience and ma=
ke every web shop feel like Amazon.</p>
<p dir=3D"ltr">Of course this has privacy implications and increases exposu=
re to potential wallet exploits, but the wallet can ask you if you intend t=
o shop or not at each site before it even connects and send any information=
at all in order to mitigate both of those problems. This way it should be =
reasonably safe.</p>
<p dir=3D"ltr">Another option would be to automatically connect but limit w=
hat data is sent in order to remain privacy preserving, until the user agre=
es to send private information.</p>
<p dir=3D"ltr">This second method would also open up for the merchant to ot=
her send relevant information such as details about various certifications =
from third parties, which can include a certification that shows they have =
been been audited and approved by by entity X for purpose Y. If your wallet=
has that entity whitelisted it will show you that certificate (for example=
"Acme Audits have audited and approves of Merchant M's privacy po=
licy and data protection"). With a list of predefined types of certifi=
cations that the wallet understand and accepts, it could (by choice of the =
user) require a certificate to be present to even allow you to make a purch=
ase (lack of required certifications would result in automatic denial). No =
certificate =3D your wallet never proceed to send private information. </p>
<p dir=3D"ltr">Thoughts? </p>
<p dir=3D"ltr">- Sent from my tablet</p>
--089e0122e8b67ea84e050eb93ea0--
|
