From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= Date: Fri, 4 Apr 2014 16:42:56 +0200 Message-ID: To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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=A0a wallet author, = and I don't think that's the right way to get traction with a new s= cheme.

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
However we have and we will propose bounties for each wallet to suppor= t natively the protocol.
=A0
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.=

Yes you are right. But i= f the concept of authenticating yourself gets traction, they will probably = do it.
=A0
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 specifically=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.

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

I understand the problems related to multisig, contract= s 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 messag= e in the blockchain debate).
=A0
Some reasons client certs aren't more widely used boil down to:
<= div>
  1. 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.
  2. The UI for managing client certs in browsers is pretty horrible. There&= #39;s little incentive to improve it because of (1).
  3. 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 doesn't=A0get your keys is supported by Chrome for passwords, but not client cert= s, because (1)
None of the above issues have any obvious fix lurking within Bitc= oin.

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

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

Eric


<= br>
--001a113393c8d5630a04f6388938--