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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Allow cross-site requests of payment
	requests
Precedence: list

--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&#39;s f=
air. From the server perspective, I&#39;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&#39;s another discussion ent=
irely but sure it could be done all in JS. In certain environments download=
ing a &quot;real app&quot; isn&#39;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&#39;s unclear.</div>
</div></div></div>
</blockquote></div><br>It certainly won&#39;t be if there is no ability :)<=
br><br clear=3D"all"><div>-Andy</div>
</div></div>

--047d7bd6be02c670ee04f9372d31--