Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WW5fy-0001Ya-HY for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 15:05:02 +0000 X-ACL-Warn: Received: from mail-ob0-f173.google.com ([209.85.214.173]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WW5fv-0007Gz-7y for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 15:05:00 +0000 Received: by mail-ob0-f173.google.com with SMTP id gq1so3660754obb.32 for ; Fri, 04 Apr 2014 08:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=qY/SUfT5H7pjDapazmS8azUuWVTvtIjBcynYyc1K15M=; b=ME42KUGl+K/v5omzrihRCzl7/aWGbHesPk3r2smPvmQF5+fcBGmVoPb4BMogY2hS7x eod3Go8h5CL1+YQmscOOmdh7ZY+MyyhhH3sRoud09nJTaD/SE3fqDhXqpww3Y8thBICL vy6ooLeG+49c2XUTQa4CqnUvfIb7UTJonYyQ6BG3r5K8nMj0omVtfvR9BN66cYQxR6eh DQoy4XVNGgdSsuOW6chKZ6CQVVIkP10EhS9WyXhfnkhgbf13ayo4BC7fPxrDtbE35Fo0 5Q2c9zoBUV2E7DA+Yp0CEc8/byzAFd2Pwp7jBPNnB/89GdxjlQn8Do2BcmYJ4G+C/JxO keew== X-Gm-Message-State: ALoCoQk0irst66MSgK5ivQmMruZwo29yeJQwKPhN6PLYXndlFWfkeRCGxjQ0q3cydyiF6StXqNWs X-Received: by 10.60.54.38 with SMTP id g6mr184741oep.79.1396623415291; Fri, 04 Apr 2014 07:56:55 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.60.102.9 with HTTP; Fri, 4 Apr 2014 07:56:25 -0700 (PDT) In-Reply-To: References: From: slush Date: Fri, 4 Apr 2014 16:56:25 +0200 X-Google-Sender-Auth: Z4o6tbtHAYWLSEcEdnGpmE64jy4 Message-ID: To: =?ISO-8859-1?Q?Eric_Larchev=EAque?= Content-Type: multipart/alternative; boundary=089e0112cf388dc7f504f638bac4 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WW5fv-0007Gz-7y 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 15:05:02 -0000 --089e0112cf388dc7f504f638bac4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm cracking my head for many months with the idea of using TREZOR for web auth purposes. Unfortunately I'm far from any usable solution yet. My main comments to your BIP: Don't use bitcoin addresses directly and don't encourage services to use this "login" for financial purposes. Mike is right, mixing authentication and financial services is wrong. Use some function to generate other private/public key from bitcoin's seed/private key to not leak bitcoin-related data to website. Cheers, Marek On Fri, Apr 4, 2014 at 4:42 PM, Eric Larchev=EAque wrote= : > 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 doo= r >> 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 usin= g >> a Bitcoin address is that the client certificate is something that is us= ed >> *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 id= ea >> because it was already done >10 years ago and basically every browser/we= b >> 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 i= n > 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 cours= e, >> 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 t= he >> 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 > > > > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0112cf388dc7f504f638bac4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm cracking my head for many months with the idea of = using TREZOR for web auth purposes. Unfortunately I'm far from any usab= le solution yet.

My main comments to your BIP: Don't= use bitcoin addresses directly and don't encourage services to use thi= s "login" for financial purposes. Mike is right, mixing authentic= ation and financial services is wrong. Use some function to generate other = private/public key from bitcoin's seed/private key to not leak bitcoin-= related data to website.

Cheers,
Marek


On Fri, Apr 4, 2014 at 4:42 PM, E= ric Larchev=EAque <elarch@gmail.com> wrote:
=
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 code for all the wallets ; this is after all a communauty project.=A0<= /div>
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 if the concept of authenticating yourself gets traction, they will pro= bably 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= mainly about the UX and the fact everyone in Bitcoinland has a wallet.
It's a approach leveraging this fact, with the possibility to bu= ild interesting 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.

Th= ere is also the benefit of revocation with certificate and central authorit= y.

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

=
E= ric


<= br>
-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0112cf388dc7f504f638bac4--