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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WK3sM-0002kK-KV for bitcoin-development@lists.sourceforge.net; Sun, 02 Mar 2014 10:44:06 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f179.google.com; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WK3sL-000440-T4 for bitcoin-development@lists.sourceforge.net; Sun, 02 Mar 2014 10:44:06 +0000 Received: by mail-ob0-f179.google.com with SMTP id va2so956860obc.24 for ; Sun, 02 Mar 2014 02:44:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.246.10 with SMTP id xs10mr11535962oec.18.1393757040590; Sun, 02 Mar 2014 02:44:00 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Sun, 2 Mar 2014 02:44:00 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Mar 2014 11:44:00 +0100 X-Google-Sender-Auth: 5NAjBrJIgbX7NJqaWdwb-kQ_BAY Message-ID: From: Mike Hearn To: Jeremy Spilman Content-Type: multipart/alternative; boundary=001a1136989a4ec84904f39d59f1 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WK3sL-000440-T4 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP70 extension to allow for identity delegation 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: Sun, 02 Mar 2014 10:44:06 -0000 --001a1136989a4ec84904f39d59f1 Content-Type: text/plain; charset=UTF-8 > > Perhaps the UI just isn't expressive enough currently to expose this > situation in any way, let alone reliably alert the user to the issue, > because there's no way for the payment processor to get authenticated > fields other than memo into the UI. > I think for now as long as payment processors include the merchant name in the memo, that's good - as long as hardware devices or second factor wallets display the memo as well! Trezor has a small screen, I don't know how feasible displaying the whole memo is there though - hence an interest in something better. For now we can probably muddle through. > A poor solution: If the UI included some sort of certificate viewer, even > just tied to the OS certificate viewer, and made the cert available for > inspection, at least the merchant would have a chance to put some fields in > there which a very advanced user might actually find. > Not really interested in solutions that only help very advanced users. Besides, my understanding is that most PKI CA's will not sign certs that include arbitrary data they don't understand for I guess the obvious security reasons (generally signing things you don't understand is a bad idea). But I've never actually tried it. We don't want anyone to have to go back to their CA anyway, especially not with special requests. --001a1136989a4ec84904f39d59f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Perhaps the UI just isn't expressive en= ough currently to expose this situation in any way, let alone reliably aler= t the user to the issue, because there's no way for the payment process= or to get authenticated fields other than memo into the UI.

I think for now as long as payment p= rocessors include the merchant name in the memo, that's good - as long = as hardware devices or second factor wallets display the memo as well! Trez= or has a small screen, I don't know how feasible displaying the whole m= emo is there though - hence an interest in something better. For now we can= probably muddle through.
=C2=A0
A poor solu= tion: If the UI included some sort of certificate viewer, even just tied to= the OS certificate viewer, and made the cert available for inspection, at = least the merchant would have a chance to put some fields in there which a = very advanced user might actually find.

Not really interested in solutions that on= ly help very advanced users. Besides, my understanding is that most PKI CA&= #39;s will not sign certs that include arbitrary data they don't unders= tand for I guess the obvious security reasons (generally signing things you= don't understand is a bad idea). But I've never actually tried it.=

We don't want anyone to have to go back to their CA= anyway, especially not with special requests.
--001a1136989a4ec84904f39d59f1--