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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
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 <elarch@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com>
References: <CA+WZAEp3HsW5ESGUZ7YfR1MZXGC5jd+LucUt_MUP8K94Xwhuhg@mail.gmail.com>
<CANEZrP0KVyp2Va7Wyy=t0qYkLNK9BDUaSzBfuzQss+=weLJ1Fw@mail.gmail.com>
<CA+WZAEqYKv8T1OMCKhOJvf5FAy=WujJ=OhtsYP9aBf=4ZPNxmw@mail.gmail.com>
<CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com>
<CANEZrP2Z5x0_kOQ=8-BMzbmi9=D=ou=s3dgEksMA5F84BHSt9A@mail.gmail.com>
From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= <elarch@gmail.com>
Date: Fri, 4 Apr 2014 16:42:56 +0200
Message-ID: <CA+WZAEqREDkDvmhM7AY+Ju3fkm3uOGm39Ef9+SYoEr43ybbg2Q@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
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: <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 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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div>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 <i>am</i>=A0a wallet author, =
and I don't think that's the right way to get traction with a new s=
cheme. </div>
</div></div></div></blockquote><div><br></div><div>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</div>
<div>However we have and we will propose bounties for each wallet to suppor=
t natively the protocol.</div><div>=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>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.=
</div>
</div></div></div></blockquote><div><br></div><div>Yes you are right. But i=
f the concept of authenticating yourself gets traction, they will probably =
do it.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>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 <i>specifically</i>=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.</div>
</div></div></div></blockquote><div><br></div><div>My view on this is mainl=
y about the UX and the fact everyone in Bitcoinland has a wallet.</div><div=
>It's a approach leveraging this fact, with the possibility to build in=
teresting apps combining address auth and the blockchain.</div>
<div><br></div><div>I understand the problems related to multisig, contract=
s etc,</div><div>There is no such thing as a from address in a transaction,=
however many services still take first tx as the return address.</div>
<div>People will always find way of building and doing stuff (cf the messag=
e in the blockchain debate).</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Some reasons client certs aren't more widely used boil down to:</div><=
div><ol><li>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.</li>
<li>The UI for managing client certs in browsers is pretty horrible. There&=
#39;s little incentive to improve it because of (1).<br></li><li>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 <i>doesn't</i=
>=A0get your keys is supported by Chrome for passwords, but not client cert=
s, because (1)</li>
</ol><div>None of the above issues have any obvious fix lurking within Bitc=
oin.</div></div></div></div></div></blockquote><div><br></div><div>There is=
also the benefit of revocation with certificate and central authority.</di=
v>
<div><br></div><div>But, again, you already have a wallet and a Bitcoin add=
ress.</div><div>So if you add a simple auth protocol, people will use it at=
no cost.=A0</div></div><br></div><div class=3D"gmail_extra">Eric</div><div=
class=3D"gmail_extra">
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><=
br></div></div>
--001a113393c8d5630a04f6388938--
|
