Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WJegx-0005OZ-N5 for bitcoin-development@lists.sourceforge.net; Sat, 01 Mar 2014 07:50:39 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co designates 50.117.27.232 as permitted sender) client-ip=50.117.27.232; envelope-from=jeremy@taplink.co; helo=mail.taplink.co; Received: from mail.taplink.co ([50.117.27.232]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1WJegw-0000wP-Vv for bitcoin-development@lists.sourceforge.net; Sat, 01 Mar 2014 07:50:39 +0000 Received: from laptop-air ([192.168.168.135]) by mail.taplink.co ; Fri, 28 Feb 2014 23:50:48 -0800 Content-Type: multipart/alternative; boundary=----------HuvgV2oycVxhn4Te0WCBxM To: Wladimir References: Date: Fri, 28 Feb 2014 23:50:32 -0800 MIME-Version: 1.0 From: "Jeremy Spilman" Organization: TapLink Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) 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 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 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: 1WJegw-0000wP-Vv Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors 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: Sat, 01 Mar 2014 07:50:39 -0000 ------------HuvgV2oycVxhn4Te0WCBxM Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir wrote: > Such a thing would be interesting for a future BIP standard. I see one > problem here: for an unsigned payment request there isn't really an > "origin". >Browser URI handlers don't send the referrer either. Yeah, good point. If you have a cert, we have the CN from the cert, which becomes the string displayed as 'Pay To' and alternatively 'Merchant'. But if there's no cert then all you have is memo. So the best way to differentiate signed requests is by prominently displaying that Merchant string. Really the green part should just be the 'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that would make the lack of certificate highly apparent. ------------HuvgV2oycVxhn4Te0WCBxM Content-Type: multipart/related; boundary=----------HuvgV2oycVxhn4ru9Zz9SZ ------------HuvgV2oycVxhn4ru9Zz9SZ Content-Type: text/html; charset=iso-8859-15 Content-ID: Content-Transfer-Encoding: Quoted-Printable On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <laanwj@gmail.com&= gt; wrote:

Such a thing would be interesting = for a future BIP standard. I see one problem here: for an unsigned payme= nt request there isn't really an "origin". Browser URI handlers don't se= nd the referrer either.

Yeah, good point. If you ha= ve a cert, we have the CN from the cert, which becomes the string displa= yed as 'Pay To' and alternatively 'Merchant'.

B= ut if there's no cert then all you have is memo.

So the best way to differentiate signed requests is by prominently dis= playing that Merchant string. Really the green part should just be the '= Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that wo= uld make the lack of certificate highly apparent. 


------------HuvgV2oycVxhn4ru9Zz9SZ-- ------------HuvgV2oycVxhn4Te0WCBxM--