From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Mon, 12 May 2014 10:21:33 -0700 Message-ID: From: Andy Alness To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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>

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.

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.

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.
=C2=A0
Is that really going to be= popular, though? I think it's unclear.

It certainly won't be if there is no ability :)<= br>
-Andy
--047d7bd6be02c670ee04f9372d31--