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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <op.xb3btqp7yldrnw@laptop-air>
References: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
	<op.xb3btqp7yldrnw@laptop-air>
Date: Sun, 2 Mar 2014 11:44:00 +0100
Message-ID: <CANEZrP0bkyO=L_9RAbgGCXhWSn+Tc_F12tMxqVz9d0Vd=kaU8w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=001a1136989a4ec84904f39d59f1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 extension to allow for identity
	delegation
Precedence: list

--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

<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>Perhaps the UI just isn&#39;t expressive en=
ough currently to expose this situation in any way, let alone reliably aler=
t the user to the issue, because there&#39;s no way for the payment process=
or to get authenticated fields other than memo into the UI.<br>
</div></blockquote><div><br></div><div>I think for now as long as payment p=
rocessors include the merchant name in the memo, that&#39;s good - as long =
as hardware devices or second factor wallets display the memo as well! Trez=
or has a small screen, I don&#39;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.</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></div><div>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.</div>
</blockquote><div><br></div><div>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&#39;t unders=
tand for I guess the obvious security reasons (generally signing things you=
 don&#39;t understand is a bad idea). But I&#39;ve never actually tried it.=
</div>
<div><br></div><div>We don&#39;t want anyone to have to go back to their CA=
 anyway, especially not with special requests.</div></div></div></div>

--001a1136989a4ec84904f39d59f1--