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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1V7l6a-000802-5n
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Aug 2013 11:43:40 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.52 as permitted sender)
client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f52.google.com;
Received: from mail-oa0-f52.google.com ([209.85.219.52])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V7l6Z-0007vh-7B
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Aug 2013 11:43:40 +0000
Received: by mail-oa0-f52.google.com with SMTP id n12so6603149oag.25
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Aug 2013 04:43:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.79.131 with SMTP id j3mr207018oex.96.1376048613791; Fri,
09 Aug 2013 04:43:33 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.84.231 with HTTP; Fri, 9 Aug 2013 04:43:33 -0700 (PDT)
Date: Fri, 9 Aug 2013 13:43:33 +0200
X-Google-Sender-Auth: xg19rDIGGLSoLFWMJRs6-A6_aV0
Message-ID: <CANEZrP3w+pGVJijxLr1N6wQiqg4U=RUP3Mrph2=fwF+Ga_U9sQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b678126d19d5804e382486d
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1V7l6Z-0007vh-7B
Subject: [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 11:43:40 -0000
--047d7b678126d19d5804e382486d
Content-Type: text/plain; charset=UTF-8
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.
--047d7b678126d19d5804e382486d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is just me making notes for myself, I'm not serio=
usly suggesting this be implemented any time soon.<div><br></div><div>Mozil=
la Persona is an infrastructure for web based single sign on. It works by h=
aving email providers sign temporary certificates for their users, whose br=
owsers then sign server-provided challenges to prove their email address.</=
div>
<div><br></div><div>Because an SSO system is a classic chicken/egg setup, t=
hey run various fallback services that allow anyone with an email address t=
o 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 beco=
mes transparently decentralised.</div>
<div><br></div><div>In other words, they seem to do a lot of things right.<=
/div><div><br></div><div>Of course you can already sign payments using an X=
.509 cert issued to an email address with v1 of the payment protocol, so te=
chnically 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 prof=
essional. CAs in contrast are designed for web site admins really so the ex=
perience of getting a cert for an email address is rather variable and more=
heavyweight.</div>
<div><br></div><div>Unfortunately Persona does not use X.509. It uses a cus=
tom thing based on JSON. However, under the hood it's just assertions s=
igned by RSA keys, so an implementation is likely to be quite easy. From th=
e 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 requ=
ests automatically. For many users, it'd be just one click, which is pr=
etty neat.</div>
<div><br></div><div><br></div></div>
--047d7b678126d19d5804e382486d--
|
