Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elarch@gmail.com>) id 1WW5L3-0003Wu-Ql
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 14:43:25 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.43 as permitted sender)
	client-ip=209.85.215.43; envelope-from=elarch@gmail.com;
	helo=mail-la0-f43.google.com; 
Received: from mail-la0-f43.google.com ([209.85.215.43])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WW5L2-0006Mh-J0
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 14:43:25 +0000
Received: by mail-la0-f43.google.com with SMTP id e16so2610060lan.30
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 04 Apr 2014 07:43:18 -0700 (PDT)
X-Received: by 10.112.56.148 with SMTP id a20mr1716282lbq.44.1396622597905;
	Fri, 04 Apr 2014 07:43:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.31.165 with HTTP; Fri, 4 Apr 2014 07:42:56 -0700 (PDT)
In-Reply-To: <CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com>
References: <CA+WZAEp3HsW5ESGUZ7YfR1MZXGC5jd+LucUt_MUP8K94Xwhuhg@mail.gmail.com>
	<CANEZrP0KVyp2Va7Wyy=t0qYkLNK9BDUaSzBfuzQss+=weLJ1Fw@mail.gmail.com>
	<CA+WZAEqYKv8T1OMCKhOJvf5FAy=WujJ=OhtsYP9aBf=4ZPNxmw@mail.gmail.com>
	<CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com>
	<CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com>
From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= <elarch@gmail.com>
Date: Fri, 4 Apr 2014 16:42:56 +0200
Message-ID: <CA+WZAEqREDkDvmhM7AY+Ju3fkm3uOGm39Ef9+SYoEr43ybbg2Q@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a113393c8d5630a04f6388938
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(elarch[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1WW5L2-0006Mh-J0
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for seamless website
 authentication using Bitcoin address
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 14:43:26 -0000

--001a113393c8d5630a04f6388938
Content-Type: text/plain; charset=ISO-8859-1

>
> The goal of writing a BIP seems to be to get lots of different wallet
> authors to write lots of code for you - but I *am* a wallet author, and I
> don't think that's the right way to get traction with a new scheme.
>

I started without a BIP and the feedback I got is that I should to a BIP.
We cannot write all the code for all the wallets ; this is after all a
communauty project.
However we have and we will propose bounties for each wallet to support
natively the protocol.


> For instance the TREZOR guys would have to support your new protocol
> otherwise if I paid my hotel bill with my TREZOR I couldn't open the door
> when I got there! But they probably have better things to be doing right
> now.
>

Yes you are right. But if the concept of authenticating yourself gets
traction, they will probably do it.


> The key difference between just generating a client certificate and using
> a Bitcoin address is that the client certificate is something that is used
> *specifically* for identification. It leaves no trace in the block chain,
> so no weird privacy issues, it doesn't matter how you manage your wallet,
> and you don't have to persuade lots of people to support your idea because
> it was already done >10 years ago and basically every browser/web server
> supports it.
>

My view on this is mainly about the UX and the fact everyone in Bitcoinland
has a wallet.
It's a approach leveraging this fact, with the possibility to build
interesting apps combining address auth and the blockchain.

I understand the problems related to multisig, contracts etc,
There is no such thing as a from address in a transaction, however many
services still take first tx as the return address.
People will always find way of building and doing stuff (cf the message in
the blockchain debate).


> Some reasons client certs aren't more widely used boil down to:
>
>    1. People like passwords. In particular they like forgetting them and
>    then having friendly people assist them to get it back. Client certs can
>    support this use case, but only if apps are checking the identity in them
>    and not the key.
>    2. The UI for managing client certs in browsers is pretty horrible.
>    There's little incentive to improve it because of (1).
>    3. Cross-device sync doesn't work very well. Apple are starting to
>    tackle this with their iCloud Keychain Sync service but then of course,
>    Apple has all your keys and you may well just sign in to things with your
>    Apple account (if it were to be supported). Cross-device sync where the
>    server *doesn't* get your keys is supported by Chrome for passwords,
>    but not client certs, because (1)
>
> None of the above issues have any obvious fix lurking within Bitcoin.
>

There is also the benefit of revocation with certificate and central
authority.

But, again, you already have a wallet and a Bitcoin address.
So if you add a simple auth protocol, people will use it at no cost.

Eric

--001a113393c8d5630a04f6388938
Content-Type: text/html; charset=ISO-8859-1
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>The goal of writing a BIP seems to be to get lots of different wallet =
authors to write lots of code for you - but I <i>am</i>=A0a wallet author, =
and I don&#39;t think that&#39;s the right way to get traction with a new s=
cheme. </div>

</div></div></div></blockquote><div><br></div><div>I started without a BIP =
and the feedback I got is that I should to a BIP. We cannot write all the c=
ode for all the wallets ; this is after all a communauty project.=A0</div>

<div>However we have and we will propose bounties for each wallet to suppor=
t natively the protocol.</div><div>=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>For instance the TREZOR guys would have to support your new protocol other=
wise if I paid my hotel bill with my TREZOR I couldn&#39;t open the door wh=
en I got there! But they probably have better things to be doing right now.=
</div>

</div></div></div></blockquote><div><br></div><div>Yes you are right. But i=
f the concept of authenticating yourself gets traction, they will probably =
do it.</div><div>=A0</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=
></div><div>The key difference between just generating a client certificate=
 and using a Bitcoin address is that the client certificate is something th=
at is used <i>specifically</i>=A0for identification. It leaves no trace in =
the block chain, so no weird privacy issues, it doesn&#39;t matter how you =
manage your wallet, and you don&#39;t have to persuade lots of people to su=
pport your idea because it was already done &gt;10 years ago and basically =
every browser/web server supports it.</div>

</div></div></div></blockquote><div><br></div><div>My view on this is mainl=
y about the UX and the fact everyone in Bitcoinland has a wallet.</div><div=
>It&#39;s a approach leveraging this fact, with the possibility to build in=
teresting apps combining address auth and the blockchain.</div>

<div><br></div><div>I understand the problems related to multisig, contract=
s etc,</div><div>There is no such thing as a from address in a transaction,=
 however many services still take first tx as the return address.</div>

<div>People will always find way of building and doing stuff (cf the messag=
e in the blockchain debate).</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Some reasons client certs aren&#39;t more widely used boil down to:</div><=
div><ol><li>People like passwords. In particular they like forgetting them =
and then having friendly people assist them to get it back. Client certs ca=
n support this use case, but only if apps are checking the identity in them=
 and not the key.</li>


<li>The UI for managing client certs in browsers is pretty horrible. There&=
#39;s little incentive to improve it because of (1).<br></li><li>Cross-devi=
ce sync doesn&#39;t work very well. Apple are starting to tackle this with =
their iCloud Keychain Sync service but then of course, Apple has all your k=
eys and you may well just sign in to things with your Apple account (if it =
were to be supported). Cross-device sync where the server <i>doesn&#39;t</i=
>=A0get your keys is supported by Chrome for passwords, but not client cert=
s, because (1)</li>


</ol><div>None of the above issues have any obvious fix lurking within Bitc=
oin.</div></div></div></div></div></blockquote><div><br></div><div>There is=
 also the benefit of revocation with certificate and central authority.</di=
v>

<div><br></div><div>But, again, you already have a wallet and a Bitcoin add=
ress.</div><div>So if you add a simple auth protocol, people will use it at=
 no cost.=A0</div></div><br></div><div class=3D"gmail_extra">Eric</div><div=
 class=3D"gmail_extra">

<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><=
br></div></div>

--001a113393c8d5630a04f6388938--