From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: From: Mike Hearn To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
This is just me making notes for myself, I'm not serio= usly suggesting this be implemented any time soon.

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.

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.

In other words, they seem to do a lot of things right.<= /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.

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.


--047d7b678126d19d5804e382486d--