summaryrefslogtreecommitdiff
path: root/a6/f0f6bd35b0072e47b63c0d1f3e4c2c4015a551
blob: 86192dee75c258a3d91cd2b201cf9fdf5cd7df5f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elarch@gmail.com>) id 1WW32n-0001nn-Ou
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 12:16:25 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.49 as permitted sender)
	client-ip=209.85.215.49; envelope-from=elarch@gmail.com;
	helo=mail-la0-f49.google.com; 
Received: from mail-la0-f49.google.com ([209.85.215.49])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WW32k-0000vT-U7
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 12:16:25 +0000
Received: by mail-la0-f49.google.com with SMTP id mc6so2393133lab.36
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 04 Apr 2014 05:16:16 -0700 (PDT)
X-Received: by 10.152.234.130 with SMTP id ue2mr8490668lac.0.1396613776209;
	Fri, 04 Apr 2014 05:16:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.31.165 with HTTP; Fri, 4 Apr 2014 05:15:56 -0700 (PDT)
From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= <elarch@gmail.com>
Date: Fri, 4 Apr 2014 14:15:56 +0200
Message-ID: <CA+WZAEp3HsW5ESGUZ7YfR1MZXGC5jd+LucUt_MUP8K94Xwhuhg@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=001a113484bc04fca104f6367cdc
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: 1WW32k-0000vT-U7
Subject: [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 12:16:26 -0000

--001a113484bc04fca104f6367cdc
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I've written a draft BIP description of an authentication protocol based 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 theoretically
offloads a lot of complexity and responsibility on the user. Managing
private keys securely is complex. However this complexity is already being
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

--001a113484bc04fca104f6367cdc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br><br>I&#39;ve written a draft BIP description of =
an authentication protocol based on Bitcoin public address.<br><br>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.<div>

<br></div><div>The aim is to greatly facilitate sign ups and logins to serv=
ices and applications, improving the Bitcoin ecosystem as a whole.<br><br><=
a href=3D"https://github.com/bitid/bitid/blob/master/BIP_draft.md">https://=
github.com/bitid/bitid/blob/master/BIP_draft.md</a><br>

<br>Demo website :<br><a href=3D"http://bitid-demo.herokuapp.com/">http://b=
itid-demo.herokuapp.com/</a><br><br>Classical password authentication is an=
 insecure process that could be solved with public key cryptography. The pr=
oblem is that it theoretically offloads a lot of complexity and responsibil=
ity on the user. Managing private keys securely is complex. However this co=
mplexity is already being addressed in the Bitcoin ecosystem. So doing publ=
ic key authentication is practically a free lunch to bitcoiners.<br>

<div><br></div><div>I&#39;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 &quot;process&quot; categor=
y.</div>

<div><br></div><div>Please read it and let me know your thoughts and commen=
ts so we can improve on this draft.<br></div><div><br></div><div>Eric Larch=
eveque</div><div><a href=3D"mailto:elarch@gmail.com">elarch@gmail.com</a></=
div>

<div><br></div></div></div>

--001a113484bc04fca104f6367cdc--