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 1WcWWS-0001yS-16 for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 08:57:48 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.179 as permitted sender) client-ip=209.85.217.179; envelope-from=elarch@gmail.com; helo=mail-lb0-f179.google.com; Received: from mail-lb0-f179.google.com ([209.85.217.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WcWWP-0001zn-Ir for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 08:57:47 +0000 Received: by mail-lb0-f179.google.com with SMTP id p9so3978027lbv.24 for ; Tue, 22 Apr 2014 01:57:38 -0700 (PDT) X-Received: by 10.152.234.229 with SMTP id uh5mr567866lac.56.1398157058821; Tue, 22 Apr 2014 01:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.31.165 with HTTP; Tue, 22 Apr 2014 01:57:18 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Eric_Larchev=C3=AAque?= Date: Tue, 22 Apr 2014 10:57:18 +0200 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1133a6fad4d39604f79dce48 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: 1WcWWP-0001zn-Ir 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: Tue, 22 Apr 2014 08:57:48 -0000 --001a1133a6fad4d39604f79dce48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The development of BitID has had some progress, and we have now a working wallet prototype based on Android Bitcoin Wallet (bitoinj). The user flow is quite nice and if you are curious here is a short video demonstration : https://www.youtube.com/watch?v=3D3eepEWTnRTc By default, each new first auth request will create and save a new address (SQRL like). It could be based on BIP32, but this works also without. This requires to add metadata to addresses, as described here : https://github.com/bitid/bitid/blob/master/bitid_metadata.md It open also the fields for decentralized 2FA as well as "pay as guest" checkout in conjonction with BIP70 payment request. Eric On Tue, Apr 22, 2014 at 8:34 AM, Jan M=C3=B8ller wro= te: > The reason why client side certificates have never gained traction becaus= e > it is a pain to safely store/backup secrets. > In bitcoinland we are forced to solve the problem of safely storing > secrets, and over the years we have come up with software and hardware > solutions to make this safer and easier to manage for ordinary people. > Solving this is paramount to the success of Bitcoin, and nobody has solve= d > it before on a grand scale. > > I see no reason for forcing end users to use two different mechanisms for > safely managing secrets. > > I agree that using a bitcoin address for authentication purposes might be > confusing and potentially linking your funds with your identity. So I am > all for using something else than bitcoin addresses and bitcoin private > keys. > > With bip32 we have finally agreed on a mechanism for generating a > hierarchy of bitcoin private keys from a master seed. A similar approach > can be used for generating a parallel hierarchy for authentication > purposes. > > - Jan > > > --001a1133a6fad4d39604f79dce48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The development of BitID has had some progress, and we hav= e now a working wallet prototype based on Android Bitcoin Wallet (bitoinj).=
The user flow is quite nice and if you are curious here is a short vid= eo demonstration :
https://www.youtu= be.com/watch?v=3D3eepEWTnRTc

By default, each new first au= th request will create and save a new address (SQRL like). It could be base= d on BIP32, but this works also without.
This requires to add metadata to addresses, as described here :
<= div>https://github.com/bitid/bitid/blob/master/bitid_metadata.md

It open also the fields for decentralized 2FA as = well as "pay as guest" checkout in conjonction with BIP70 payment= request.

Eric



On Tue, Apr 22, 2014 at 8:34 AM, Jan M= =C3=B8ller <jan.moller@gmail.com> wrote:
The reason why client side certificates have never ga= ined traction because it is a pain to safely store/backup secrets.
In bitcoinland we are forced to solve the problem of safely storing secre= ts, and over the years we have come up with software and hardware solutions= to make this safer and easier to manage for ordinary people. Solving this = is paramount to the success of Bitcoin, and nobody has solved it before on = a grand scale.=C2=A0

I see no reason for forcing end users to use two differ= ent mechanisms for safely managing secrets.

I agre= e that using a bitcoin address for authentication purposes might be confusi= ng and potentially linking your funds with your identity. So I am all for u= sing something else than bitcoin addresses and bitcoin private keys.

With bip32 we have finally agreed on a mechanism = for generating a hierarchy of bitcoin private keys from a master seed. A si= milar approach can be used for generating a parallel hierarchy for authenti= cation purposes.=C2=A0
- Jan



--001a1133a6fad4d39604f79dce48--