diff options
| author | Eric Larchevêque <elarch@gmail.com> | 2014-04-04 17:03:20 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-04 15:03:48 +0000 |
| commit | 4b2f3a4c9782e9f561675ef7db795634922f1d82 (patch) | |
| tree | bd238d4c070e86f9aff668634c44d832be5d1fcc | |
| parent | 316d11e7afc465387f98ad7ee808c9593a4b8e89 (diff) | |
| download | pi-bitcoindev-4b2f3a4c9782e9f561675ef7db795634922f1d82.tar.gz pi-bitcoindev-4b2f3a4c9782e9f561675ef7db795634922f1d82.zip | |
Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address
| -rw-r--r-- | aa/097436cb4cf0a6e26a1362b980d5475ddcc07d | 231 |
1 files changed, 231 insertions, 0 deletions
diff --git a/aa/097436cb4cf0a6e26a1362b980d5475ddcc07d b/aa/097436cb4cf0a6e26a1362b980d5475ddcc07d new file mode 100644 index 000000000..2eaa9bb45 --- /dev/null +++ b/aa/097436cb4cf0a6e26a1362b980d5475ddcc07d @@ -0,0 +1,231 @@ +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 <elarch@gmail.com>) id 1WW5em-0002NQ-1t + for bitcoin-development@lists.sourceforge.net; + Fri, 04 Apr 2014 15:03:48 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.217.175 as permitted sender) + client-ip=209.85.217.175; envelope-from=elarch@gmail.com; + helo=mail-lb0-f175.google.com; +Received: from mail-lb0-f175.google.com ([209.85.217.175]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WW5ek-0005aY-Sx + for bitcoin-development@lists.sourceforge.net; + Fri, 04 Apr 2014 15:03:48 +0000 +Received: by mail-lb0-f175.google.com with SMTP id w7so2588053lbi.34 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 04 Apr 2014 08:03:40 -0700 (PDT) +X-Received: by 10.152.36.73 with SMTP id o9mr8955321laj.30.1396623820262; Fri, + 04 Apr 2014 08:03:40 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.112.31.165 with HTTP; Fri, 4 Apr 2014 08:03:20 -0700 (PDT) +In-Reply-To: <CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com> +References: <CA+WZAEp3HsW5ESGUZ7YfR1MZXGC5jd+LucUt_MUP8K94Xwhuhg@mail.gmail.com> + <CANEZrP0KVyp2Va7Wyy=t0qYkLNK9BDUaSzBfuzQss+=weLJ1Fw@mail.gmail.com> + <CA+WZAEqYKv8T1OMCKhOJvf5FAy=WujJ=OhtsYP9aBf=4ZPNxmw@mail.gmail.com> + <CANEZrP0DTYqobECBbw6eZqdk+-TR_2jhBtOviN08r31EQGmZHQ@mail.gmail.com> +From: =?ISO-8859-1?Q?Eric_Larchev=EAque?= <elarch@gmail.com> +Date: Fri, 4 Apr 2014 17:03:20 +0200 +Message-ID: <CA+WZAErj0KJ0ptHF+EVFxhpkPzUw32t6ztYgwNh=fVL0Wu3vmQ@mail.gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=089e0160adf8b1134804f638d23b +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 + (elarch[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: 1WW5ek-0005aY-Sx +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Draft BIP for seamless website + authentication using Bitcoin address +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, 04 Apr 2014 15:03:48 -0000 + +--089e0160adf8b1134804f638d23b +Content-Type: text/plain; charset=ISO-8859-1 + +> +> +> Why do you need it? Because you don't want to implement a login system? +> Very, very few websites are the sort of place where they'd want to +> authenticate with only a Bitcoin address. If for no other reason than +> they'd have no way to email you, and if you lost your wallet, you'd lose +> all your associated data. +> + +Well, the major difference is that you could sign up effortlessy to a +service, and associate your email later. +If more people sign up to more services, it's a good thing for the +ecosystem. + + +> +> +>> Without such a standard protocol, you could never envision a pure Bitcoin +>> physical locker rental, or booking an hotel room via Bitcoin and opening +>> the door through the paying address. +>> +> +> In future there often won't be a simple paying address. For instance, if +> my coins are in a multi-sig relationship with a risk analysis service, +> there will be two keys for each input and an arbitrary number of inputs. So +> does that mean the risk analysis service gets to open my locker? Why? +> + + +> What if I do a shared spend/CoinJoin type tx? Now anyone who took part in +> the shared tx with me can get into my hotel room too? +> +> + +In a perfect world, you would pay your locker with a "normal" transaction. +The same way you shouldn't play satoshi dice from a shared wallet. + +But your point is totaly valid, and I don't have answer to that except that +I'd love to have a Bitcoin authenticated locker in our Bitcoin co working +office. + + +> +> +> These are the kinds of problems that crop up when you mix together two +> different things: the act of paying, and the act of identifying yourself. +> You're assuming that replacing a password people can remember with a +> physical token (their phone) which can be stolen or lost, would be seen as +> an upgrade. Given a choice between two physical lockers, one of which lets +> me open it with a password and one of which insists on a cryptographic +> token, I'm going to go for the former because the chances of me losing my +> phone is much higher than me forgetting my password. +> +> All the tools you need already exist in the form of client certificates, +> with the advantage that web servers and web browsers already support them. +> The biggest pain point with them is backup and cross-device sync, which of +> course wallets suffer from too! +> + + +Bitcoin users are normaly already paying some effort to securise and backup +their wallets / keys. So it's just about leveraging that. + +I would myself pick a crypto locker, because I'm the kind of guy who +Facebook connects and I follow the easiest path, even if it has long term +costs :) + +Eric + +--089e0160adf8b1134804f638d23b +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= +-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi= +ng-left:1ex"> + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div= + class=3D""><div><br></div></div><div>Why do you need it? Because you don&#= +39;t want to implement a login system? Very, very few websites are the sort= + of place where they'd want to authenticate with only a Bitcoin address= +. If for no other reason than they'd have no way to email you, and if y= +ou lost your wallet, you'd lose all your associated data.</div> + +<div class=3D""> +<div></div></div></div></div></div></blockquote><div><br></div><div>Well, t= +he major difference is that you could sign up effortlessy to a service, and= + associate your email later.</div><div>If more people sign up to more servi= +ces, it's a good thing for the ecosystem.</div> + +<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= + 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left= +-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">= +<div class=3D"gmail_quote"> + +<div class=3D""><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= +204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div>= +<div> +<span style=3D"font-family:arial,sans-serif">Without such a standard protoc= +ol, you could never envision a pure Bitcoin physical locker rental, or book= +ing an hotel room via Bitcoin and opening the door through the paying addre= +ss.</span></div> + + +</div></blockquote><div><br></div></div><div>In future there often won'= +t be a simple paying address. For instance, if my coins are in a multi-sig = +relationship with a risk analysis service, there will be two keys for each = +input and an arbitrary number of inputs. So does that mean the risk analysi= +s service gets to open my locker? Why?</div> + +</div></div></div></blockquote><div>=A0</div><blockquote class=3D"gmail_quo= +te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col= +or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l= +tr"> + +<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>What if I do a s= +hared spend/CoinJoin type tx? Now anyone who took part in the shared tx wit= +h me can get into my hotel room too?</div><div><br></div></div></div></div> + +</blockquote><div><br></div><div><br></div><div>In a perfect world, you wou= +ld pay your locker with a "normal" transaction.</div><div>The sam= +e way you shouldn't play satoshi dice from a shared wallet.</div><div> + +<br></div><div>But your point is totaly valid, and I don't have answer = +to that except that I'd love to have a Bitcoin authenticated locker in = +our Bitcoin co working office.</div><div>=A0</div><blockquote class=3D"gmai= +l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef= +t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> + +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"> +<div><br></div><div><br></div><div>These are the kinds of problems that cro= +p up when you mix together two different things: the act of paying, and the= + act of identifying yourself. You're assuming that replacing a password= + people can remember with a physical token (their phone) which can be stole= +n or lost, would be seen as an upgrade. Given a choice between two physical= + lockers, one of which lets me open it with a password and one of which ins= +ists on a cryptographic token, I'm going to go for the former because t= +he chances of me losing my phone is much higher than me forgetting my passw= +ord.</div> + + +<div><br></div><div>All the tools you need already exist in the form of cli= +ent certificates, with the advantage that web servers and web browsers alre= +ady support them. The biggest pain point with them is backup and cross-devi= +ce sync, which of course wallets suffer from too!</div> + + +</div></div></div> +</blockquote></div><br></div><div class=3D"gmail_extra"><br></div><div clas= +s=3D"gmail_extra">Bitcoin users are normaly already paying some effort to s= +ecurise and backup their wallets / keys. So it's just about leveraging = +that.</div> + +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I would mys= +elf pick a crypto locker, because I'm the kind of guy who Facebook conn= +ects and I follow the easiest path, even if it has long term costs :)</div> + +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Eric</div><= +/div> + +--089e0160adf8b1134804f638d23b-- + + |