From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WW4Eh-0005GW-Mu for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 13:32:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.181 as permitted sender) client-ip=209.85.160.181; envelope-from=gavinandresen@gmail.com; helo=mail-yk0-f181.google.com; Received: from mail-yk0-f181.google.com ([209.85.160.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WW4Eg-0001is-0S for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 13:32:47 +0000 Received: by mail-yk0-f181.google.com with SMTP id 131so2856112ykp.40 for ; Fri, 04 Apr 2014 06:32:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.120.147 with SMTP id p19mr16990985yhh.6.1396618360303; Fri, 04 Apr 2014 06:32:40 -0700 (PDT) Received: by 10.170.133.195 with HTTP; Fri, 4 Apr 2014 06:32:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 09:32:40 -0400 Message-ID: From: Gavin Andresen To: =?ISO-8859-1?Q?Eric_Larchev=EAque?= Content-Type: multipart/alternative; boundary=20cf3010e48d40b5f104f6378d0a X-Spam-Score: 0.4 (/) 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 (gavinandresen[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 1.0 FREEMAIL_REPLY From and body contain different freemails X-Headers-End: 1WW4Eg-0001is-0S 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 13:32:47 -0000 --20cf3010e48d40b5f104f6378d0a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Using a bitcoin address repeatedly is something we're trying to move away from. And using a bitcoin address as a persistent identity key feels like the wrong direction to me. Better to use something like client certificates, the FIDO alliance's (new!) specs: http://fidoalliance.org/specifications/download ... or Steve Gibson's proposed SQRL system: https://www.grc.com/sqrl/sqrl.htm If one of those systems gets critical mass and actually starts being successful, then I think it would make sense to specify a standard way of using a HD wallet's deterministic seed to derive a key used for the FIDO or SQRL systems. On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchev=EAque wrote= : > What I'm trying to achieve, is to have a very simple way of authenticatin= g > yourself with one Bitcoin address from your wallet. > For most of the people using Bitcoin, their wallet is on their phone. > > The UX is clear and simple : > 1. click on "connect with Bitcoin" (the audience is normal people) > 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...) > 3. accept the authentication request (same style than OpenID or Facebook > connect) > 4. user is autologged and identified by the chosen Bitcoin public address > > It makes sense only if major wallets are supporting the protocol. If you > need to install a plugin or download a third party software, no one will = do > it. > I see only benefits for the entire ecosystem, and if I'm working on such = a > proposition it is because I really need this feature. > > Of course, it can be done without a BIP, I just need to convince wallet > developpers one by one to implement the feature. > But I thought it was much better to start the "official" way, so all > wallet could easily find and implement the same authentication mechanism. > > > Bitcoin and website authentication are unrelated problems > > I respectfully disagree. Many services require your Bitcoin address, and > to do that they artificially request an email/password to store it. > This is not about authentication as an identity (as "I'm Eric > Larcheveque"), but as in "I'm proving to you that I control this address"= . > > Without such a standard protocol, you could never envision a pure Bitcoin > physical locker rental, or booking an hotel room via Bitcoin and opening > the door through the paying address. > > Eric > > > > On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn wrote: > >> This comes up every few months. I think the problem you are trying to >> solve is already solved by SSL client certificates, and if you want to h= elp >> make them more widespread the programs you need to upgrade are web brows= ers >> and not Bitcoin wallets. There are certainly bits of infrastructure you >> could reuse here and there, like perhaps a TREZOR with a custom firmware >> extension for really advanced/keen users, but overall Bitcoin and websit= e >> authentication are unrelated problems. >> >> >> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchev=EAque wro= te: >> >>> Hello, >>> >>> I've written a draft BIP description of an authentication protocol base= d >>> on Bitcoin public address. >>> >>> By authentication we mean to prove to a service/application that we >>> control a specific Bitcoin address by signing a challenge, and that all >>> related data and settings may securely be linked to our session. >>> >>> The aim is to greatly facilitate sign ups and logins to services and >>> applications, improving the Bitcoin ecosystem as a whole. >>> >>> https://github.com/bitid/bitid/blob/master/BIP_draft.md >>> >>> Demo website : >>> http://bitid-demo.herokuapp.com/ >>> >>> Classical password authentication is an insecure process that could be >>> solved with public key cryptography. The problem is that it theoretical= ly >>> offloads a lot of complexity and responsibility on the user. Managing >>> private keys securely is complex. However this complexity is already be= ing >>> addressed in the Bitcoin ecosystem. So doing public key authentication = is >>> practically a free lunch to bitcoiners. >>> >>> I've formatted the protocol description as a BIP because this is the >>> only way to have all major wallets implementing it, and because it >>> completely fits in my opinion the BIP "process" category. >>> >>> Please read it and let me know your thoughts and comments so we can >>> improve on this draft. >>> >>> Eric Larcheveque >>> elarch@gmail.com >>> >>> >>> >>> -----------------------------------------------------------------------= ------- >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >> > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --=20 -- Gavin Andresen --20cf3010e48d40b5f104f6378d0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Using a bitcoin address repeatedly is something we're = trying to move away from.

And using a bitcoin address as= a persistent identity key feels like the wrong direction to me.

Better to use something like client certificates, the FIDO a= lliance's (new!) specs:

... or Steve Gibson's proposed SQRL system:
=A0=A0https://www.grc.com/= sqrl/sqrl.htm

If one of those systems gets cri= tical mass and actually starts being successful, then I think it would make= sense to specify a standard way of using a HD wallet's deterministic s= eed to derive a key used for the FIDO or SQRL systems.




On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchev=EAque <= span dir=3D"ltr"><= elarch@gmail.com> wrote:
What I'm trying to achi= eve, is to have a very simple way of authenticating yourself with one Bitco= in address from your wallet.
For most of the people using Bitcoin, their wallet is on their phone.

The UX is clear and simple :
1. click on &quo= t;connect with Bitcoin" (the audience is normal people)
2. f= lash the QRcode with your wallet (blockchain.info, mycelium, ...)
3. accept the authentication request (same style than OpenID or Facebo= ok connect)
4. user is autologged and identified by the chosen Bi= tcoin public address

It makes sense only if major = wallets are supporting the protocol. If you need to install a plugin or dow= nload a third party software, no one will do it.
I see only benefits for the entire ecosystem, and if I'm working o= n such a proposition it is because I really need this feature.

Of course, it can be done without a BIP, I just need to co= nvince wallet developpers one by one to implement the feature.
But I thought it was much better to start the "official" way= , so all wallet could easily find and implement the same authentication mec= hanism.

>=A0=A0Bitcoin and website authentication are = unrelated problems

I respectfully disagree. Many services require your Bitcoin address, and= to do that they artificially request an email/password to store it.=
This is no= t about authentication as an identity (as "I'm Eric Larcheveque&qu= ot;), but as in "I'm proving to you that I control this address&qu= ot;.

Without such a standard protoc= ol, you could never envision a pure Bitcoin physical locker rental, or book= ing an hotel room via Bitcoin and opening the door through the paying addre= ss.

Eric
=


On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike@plan99.net> w= rote:
This comes up every few mon= ths. I think the problem you are trying to solve is already solved by SSL c= lient certificates, and if you want to help make them more widespread the p= rograms you need to upgrade are web browsers and not Bitcoin wallets. There= are certainly bits of infrastructure you could reuse here and there, like = perhaps a TREZOR with a custom firmware extension for really advanced/keen = users, but overall Bitcoin and website authentication are unrelated problem= s.


On = Fri, Apr 4, 2014 at 2:15 PM, Eric Larchev=EAque <elarch@gmail.com> wrote:
Hello,

I've written a draft BIP description of = an authentication protocol based on Bitcoin public address.

By authe= ntication we mean to prove to a service/application that we control a speci= fic Bitcoin address by signing a challenge, and that all related data and s= ettings may securely be linked to our session.

The aim is to greatly facilitate sign ups and logins to serv= ices and applications, improving the Bitcoin ecosystem as a whole.

<= a href=3D"https://github.com/bitid/bitid/blob/master/BIP_draft.md" target= =3D"_blank">https://github.com/bitid/bitid/blob/master/BIP_draft.md

Demo website :
http://bitid-demo.herokuapp.com/

Classical password = authentication is an insecure process that could be solved with public key = cryptography. The problem is that it theoretically offloads a lot of comple= xity and responsibility on the user. Managing private keys securely is comp= lex. However this complexity is already being addressed in the Bitcoin ecos= ystem. So doing public key authentication is practically a free lunch to bi= tcoiners.

I've formatted the protocol description as a BIP be= cause this is the only way to have all major wallets implementing it, and b= ecause it completely fits in my opinion the BIP "process" categor= y.

Please read it and let me know your thoughts and commen= ts so we can improve on this draft.

Eric Larch= eveque


-----------------------------------------------------------= -------------------

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




-----------------------------------------------------------= -------------------

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




--
--
Ga= vin Andresen
--20cf3010e48d40b5f104f6378d0a--