summaryrefslogtreecommitdiff
path: root/e5/73499a70afb55acb48ad5065796869f1011ffb
blob: ae219394585d31ec59040169c41790100b5453c8 (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
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
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
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 <melvincarvalho@gmail.com>) id 1V7leV-0000Rm-HN
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 Aug 2013 12:18:43 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.172 as permitted sender)
	client-ip=209.85.214.172; envelope-from=melvincarvalho@gmail.com;
	helo=mail-ob0-f172.google.com; 
Received: from mail-ob0-f172.google.com ([209.85.214.172])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V7leU-0003RV-FW
	for bitcoin-development@lists.sourceforge.net;
	Fri, 09 Aug 2013 12:18:43 +0000
Received: by mail-ob0-f172.google.com with SMTP id er7so6288007obc.17
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 09 Aug 2013 05:18:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.199.74 with SMTP id ji10mr286298obc.69.1376050717082;
	Fri, 09 Aug 2013 05:18:37 -0700 (PDT)
Received: by 10.76.23.9 with HTTP; Fri, 9 Aug 2013 05:18:37 -0700 (PDT)
In-Reply-To: <4A46BA74-F2C2-4139-AABE-67CFE4BC4FA4@grabhive.com>
References: <CANEZrP3w+pGVJijxLr1N6wQiqg4U=RUP3Mrph2=fwF+Ga_U9sQ@mail.gmail.com>
	<4A46BA74-F2C2-4139-AABE-67CFE4BC4FA4@grabhive.com>
Date: Fri, 9 Aug 2013 14:18:37 +0200
Message-ID: <CAKaEYh+7fH9DSDc-nFn_Fp4tEPpnkLcNHx1ank05Jk4S-mp2Eg@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Wendell <w@grabhive.com>
Content-Type: multipart/alternative; boundary=e89a8ff1c0242f57b604e382c66b
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
	(melvincarvalho[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: 1V7leU-0003RV-FW
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Idea for new payment protocol PKI
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, 09 Aug 2013 12:18:43 -0000

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

On 9 August 2013 13:59, Wendell <w@grabhive.com> wrote:

> We have been discussing something like this over here too, as well as
> exploring more esoteric blockchain+signature-based "SSO" implementations as
> discussed by John Light and others.
>

I've been using SSO for years using an X.509 private key in my browser, and
my public key referenced in my home page.

The unfortunate thing is that X.509 tends to use RSA, and bitcoin tends to
use ECC for space reasons.  Since, in its simplest form, bitcoin is a
distributed ledger of public key / balance values you could imagine an
enormous eco system where every key pair become a wallet with 10s of
millions of users.

I was thinking about an alt coin along these lines.  The problem is that
there's no OP_CODE for RSA and the block chain would become massive.


>
> One of our long-term ambitions with Hive is to provide a (mostly)
> user-transparent, decentralized authentication service. It sounds like our
> infrastructure could already handle a Persona implementation, and we very
> much want to get behind some forward-thinking standard. So as long as the
> plan _IS_ to remove said 'centralized struts' at the appropriate time, I'd
> say we're interested in exploring this further.
>

Sounds great, would love to hear more about what you come up with!


>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote:
>
> > This is just me making notes for myself, I'm not seriously suggesting
> this be implemented any time soon.
> >
> > Mozilla Persona is an infrastructure for web based single sign on. It
> works by having email providers sign temporary certificates for their
> users, whose browsers then sign server-provided challenges to prove their
> email address.
> >
> > Because an SSO system is a classic chicken/egg setup, they run various
> fallback services that allow anyone with an email address to take part.
> They also integrate with the Google/Yahoo SSO systems as well. The
> intention being that they do this until Persona becomes big enough to
> matter, and then they can remove the centralised struts and the system
> becomes transparently decentralised.
> >
> > In other words, they seem to do a lot of things right.
> >
> > Of course you can already sign payments using an X.509 cert issued to an
> email address with v1 of the payment protocol, so technically no new PKI is
> needed. But the benefit of leveraging Persona would be convenience - you
> can get yourself a Persona cert and use it to sign in to websites with a
> single click, and the user experience is smart and professional. CAs in
> contrast are designed for web site admins really so the experience of
> getting a cert for an email address is rather variable and more heavyweight.
> >
> > Unfortunately Persona does not use X.509. It uses a custom thing based
> on JSON. However, under the hood it's just assertions signed by RSA keys,
> so an implementation is likely to be quite easy. From the users
> perspective, their wallet app would embed a browser and drive it as if it
> were signing into a website, but stop after the user is signed into Persona
> and a user cert has been provisioned. It can then sign payment requests
> automatically. For many users, it'd be just one click, which is pretty neat.
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 August 2013 13:59, Wendell <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:w@grabhive.com" target=3D"_blank">w@grabhive.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">

We have been discussing something like this over here too, as well as explo=
ring more esoteric blockchain+signature-based &quot;SSO&quot; implementatio=
ns as discussed by John Light and others.<br></blockquote><div><br></div>

<div>I&#39;ve been using SSO for years using an X.509 private key in my bro=
wser, and my public key referenced in my home page.<br><br></div><div>The u=
nfortunate thing is that X.509 tends to use RSA, and bitcoin tends to use E=
CC for space reasons.=A0 Since, in its simplest form, bitcoin is a distribu=
ted ledger of public key / balance values you could imagine an enormous eco=
 system where every key pair become a wallet with 10s of millions of users.=
=A0 <br>

<br>I was thinking about an alt coin along these lines.=A0 The problem is t=
hat there&#39;s no OP_CODE for RSA and the block chain would become massive=
.<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
One of our long-term ambitions with Hive is to provide a (mostly) user-tran=
sparent, decentralized authentication service. It sounds like our infrastru=
cture could already handle a Persona implementation, and we very much want =
to get behind some forward-thinking standard. So as long as the plan _IS_ t=
o remove said &#39;centralized struts&#39; at the appropriate time, I&#39;d=
 say we&#39;re interested in exploring this further.<br>

</blockquote><div><br></div><div>Sounds great, would love to hear more abou=
t what you come up with! <br></div><div>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<br>
-wendell<br>
<br>
<a href=3D"http://grabhive.com" target=3D"_blank">grabhive.com</a> | <a hre=
f=3D"http://twitter.com/grabhive" target=3D"_blank">twitter.com/grabhive</a=
> | gpg: 6C0C9411<br>
<div><div><br>
On Aug 9, 2013, at 1:43 PM, Mike Hearn wrote:<br>
<br>
&gt; This is just me making notes for myself, I&#39;m not seriously suggest=
ing this be implemented any time soon.<br>
&gt;<br>
&gt; Mozilla Persona is an infrastructure for web based single sign on. It =
works by having email providers sign temporary certificates for their users=
, whose browsers then sign server-provided challenges to prove their email =
address.<br>


&gt;<br>
&gt; Because an SSO system is a classic chicken/egg setup, they run various=
 fallback services that allow anyone with an email address to take part. Th=
ey also integrate with the Google/Yahoo SSO systems as well. The intention =
being that they do this until Persona becomes big enough to matter, and the=
n they can remove the centralised struts and the system becomes transparent=
ly decentralised.<br>


&gt;<br>
&gt; In other words, they seem to do a lot of things right.<br>
&gt;<br>
&gt; Of course you can already sign payments using an X.509 cert issued to =
an email address with v1 of the payment protocol, so technically no new PKI=
 is needed. But the benefit of leveraging Persona would be convenience - yo=
u can get yourself a Persona cert and use it to sign in to websites with a =
single click, and the user experience is smart and professional. CAs in con=
trast are designed for web site admins really so the experience of getting =
a cert for an email address is rather variable and more heavyweight.<br>


&gt;<br>
&gt; Unfortunately Persona does not use X.509. It uses a custom thing based=
 on JSON. However, under the hood it&#39;s just assertions signed by RSA ke=
ys, so an implementation is likely to be quite easy. From the users perspec=
tive, their wallet app would embed a browser and drive it as if it were sig=
ning into a website, but stop after the user is signed into Persona and a u=
ser cert has been provisioned. It can then sign payment requests automatica=
lly. For many users, it&#39;d be just one click, which is pretty neat.<br>


<br>
</div></div><div><div>-----------------------------------------------------=
-------------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It&#39;s a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with &lt;2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div></div>

--e89a8ff1c0242f57b604e382c66b--