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't think that'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'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't matter how you = manage your wallet, and you don't have to persuade lots of people to su= pport your idea because it was already done >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'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'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'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'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--