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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andy@coinbase.com>) id 1WjuPZ-0001eW-9C
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 17:53:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of coinbase.com
designates 209.85.213.179 as permitted sender)
client-ip=209.85.213.179; envelope-from=andy@coinbase.com;
helo=mail-ig0-f179.google.com;
Received: from mail-ig0-f179.google.com ([209.85.213.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WjuPX-0005DX-GF
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 17:53:13 +0000
Received: by mail-ig0-f179.google.com with SMTP id hn18so4156030igb.12
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 May 2014 10:53:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=zwveZn5VkM2V/BXjvZKdcTl98tftvSjkVrkSn+3b3WE=;
b=leAYfudI5hmxWiKW0QaFbnilxSL1s5efU/tIE7uG21lvpzGqKgfLIxV9UesZ6Vtiey
xK9vBhr1oTw0wCS3aWgHbkeLuGzi4TWtBrnf7T+B3IQoZKsewPpmde4d6a9+fuECBf+F
pKmO+SQS/RqGL/CvQfVcpDQEepB9mkE6nKJzLsd/IvZ5V7thWteFxQFUxn38bndJtIz2
wpkkVYfJujb7+wLqJP7u307h4PtKGb9zh2WrHXl3Ed5uu/cbOqR/ylWPFmnA9D7Vv3pR
uuOxIF4BSbPojd2waQgIXgiI0w9NAiMIZIPnCgdbh3eP4bkf7K+1CIpGTG/nlnskVVP3
x30w==
X-Gm-Message-State: ALoCoQnU/GCNmc8fnafUfeWfqtQg3n+DTBcOiJKraBCut+JuBKyvwXCWT2uPlcBNpCejKPV2U4t+
MIME-Version: 1.0
X-Received: by 10.50.66.169 with SMTP id g9mr45040377igt.49.1399915293332;
Mon, 12 May 2014 10:21:33 -0700 (PDT)
Received: by 10.43.162.201 with HTTP; Mon, 12 May 2014 10:21:33 -0700 (PDT)
In-Reply-To: <CANEZrP0Ea-goS-Ba58z62E4cv5QKvYzbOkwT0JJPaXLniE_m5g@mail.gmail.com>
References: <CALKy-wq6FZs39KX-gk2PizEEikLvHhxMkt=OT61fcUchsaLpfg@mail.gmail.com>
<CANEZrP0Ea-goS-Ba58z62E4cv5QKvYzbOkwT0JJPaXLniE_m5g@mail.gmail.com>
Date: Mon, 12 May 2014 10:21:33 -0700
Message-ID: <CALKy-wqMPvchyCCNYSdPXYEA7uNAA+qVaCCXqd5PNkxs1dr2Wg@mail.gmail.com>
From: Andy Alness <andy@coinbase.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7bd6be02c670ee04f9372d31
X-Spam-Score: -0.5 (/)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WjuPX-0005DX-GF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Allow cross-site requests of payment
requests
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: Mon, 12 May 2014 17:53:13 -0000
--047d7bd6be02c670ee04f9372d31
Content-Type: text/plain; charset=UTF-8
>
> It sounds OK to me, although we should all sleep on it for a bit. The
> reason this header exists is exactly because mobile code fetching random
> web resources can result in surprising security holes.
>
That's fair. From the server perspective, I'd argue that payment requests /
payments already need to be publicly accessible endpoints. Current
practical use requires support for cross-app/cross-device requests for
them. It seems like a reasonable logical extension to explicitly allow for
them to be accessed cross-site as well.
For this to be useful, someone would have to actually want to fully
> implement the payment protocol (with its own root cert store, ASN.1
> parsing, RSA etc) in browser-sandboxed Javascript rather than just
> providing a real app for people to download.
>
I think there is still value in fetching the payment request cross-site
even if the request payload is validated by a 3rd party using a more
conventional TLS/crypto suite. Exposing x.509/RSA/ASN.1/chain verification
functionality strikes me as a useful thing browsers could easily offer but
that's another discussion entirely but sure it could be done all in JS. In
certain environments downloading a "real app" isn't possible/practical.
> Is that really going to be popular, though? I think it's unclear.
>
It certainly won't be if there is no ability :)
-Andy
--047d7bd6be02c670ee04f9372d31
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div class=3D""><div>It sounds OK to me, although we should all sleep on it=
for a bit. The reason this header exists is exactly because mobile code fe=
tching random web resources can result in surprising security holes.=C2=A0<=
br>
</div></div></div></div></div></blockquote><div><br></div><div>That's f=
air. From the server perspective, I'd argue that payment requests / pay=
ments already need to be publicly accessible endpoints. Current practical u=
se requires support for cross-app/cross-device requests for them. It seems =
like a reasonable logical extension to explicitly allow for them to be acce=
ssed cross-site as well.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">
<div>For this to be useful, someone would have to actually want to fully im=
plement the payment protocol (with its own root cert store, ASN.1 parsing, =
RSA etc) in browser-sandboxed Javascript rather than just providing a real =
app for people to download.</div>
</div></div></div></blockquote><div><br></div><div>I think there is still v=
alue in fetching the payment request cross-site even if the request payload=
is validated by a 3rd party using a more conventional TLS/crypto suite. Ex=
posing x.509/RSA/ASN.1/chain verification functionality strikes me as a use=
ful thing browsers could easily offer but that's another discussion ent=
irely but sure it could be done all in JS. In certain environments download=
ing a "real app" isn't possible/practical.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Is that really going to be=
popular, though? I think it's unclear.</div>
</div></div></div>
</blockquote></div><br>It certainly won't be if there is no ability :)<=
br><br clear=3D"all"><div>-Andy</div>
</div></div>
--047d7bd6be02c670ee04f9372d31--
|
