Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-08-09 📝 Original message:This is just me making ...
📅 Original date posted:2013-08-09
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130809/93d2a4b9/attachment.html>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130809/93d2a4b9/attachment.html>;