From: Melvin Carvalho <melvincarvalho@gmail•com>
To: Wendell <w@grabhive•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Idea for new payment protocol PKI
Date: Fri, 9 Aug 2013 14:18:37 +0200 [thread overview]
Message-ID: <CAKaEYh+7fH9DSDc-nFn_Fp4tEPpnkLcNHx1ank05Jk4S-mp2Eg@mail.gmail.com> (raw)
In-Reply-To: <4A46BA74-F2C2-4139-AABE-67CFE4BC4FA4@grabhive.com>
[-- Attachment #1: Type: text/plain, Size: 3938 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5171 bytes --]
prev parent reply other threads:[~2013-08-09 12:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 11:43 Mike Hearn
2013-08-09 11:57 ` Melvin Carvalho
2013-08-09 12:08 ` Mike Hearn
2013-08-09 12:17 ` Melvin Carvalho
2013-08-09 11:59 ` Wendell
2013-08-09 12:18 ` Melvin Carvalho [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKaEYh+7fH9DSDc-nFn_Fp4tEPpnkLcNHx1ank05Jk4S-mp2Eg@mail.gmail.com \
--to=melvincarvalho@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=w@grabhive$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox