[Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

Hello,

I've written a draft BIP description of an authentication protocol based on
Bitcoin public address.

By authentication we mean to prove to a service/application that we control
a specific Bitcoin address by signing a challenge, and that all related
data and settings may securely be linked to our session.

The aim is to greatly facilitate sign ups and logins to services and
applications, improving the Bitcoin ecosystem as a whole.

https://github.com/bitid/bitid/blob/master/BIP_draft.md

Demo website :
http://bitid-demo.herokuapp.com/

Classical password authentication is an insecure process that could be
solved with public key cryptography. The problem is that it theoretically
offloads a lot of complexity and responsibility on the user. Managing
private keys securely is complex. However this complexity is already being
addressed in the Bitcoin ecosystem. So doing public key authentication is
practically a free lunch to bitcoiners.

I've formatted the protocol description as a BIP because this is the only
way to have all major wallets implementing it, and because it completely
fits in my opinion the BIP "process" category.

Please read it and let me know your thoughts and comments so we can improve
on this draft.

Eric Larcheveque
elarch@gmail.com

[-- Attachment #2: Type: text/html, Size: 1652 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

This comes up every few months. I think the problem you are trying to solve
is already solved by SSL client certificates, and if you want to help make
them more widespread the programs you need to upgrade are web browsers and
not Bitcoin wallets. There are certainly bits of infrastructure you could
reuse here and there, like perhaps a TREZOR with a custom firmware
extension for really advanced/keen users, but overall Bitcoin and website
authentication are unrelated problems.


On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch@gmail.com> wrote:

> Hello,
>
> I've written a draft BIP description of an authentication protocol based
> on Bitcoin public address.
>
> By authentication we mean to prove to a service/application that we
> control a specific Bitcoin address by signing a challenge, and that all
> related data and settings may securely be linked to our session.
>
> The aim is to greatly facilitate sign ups and logins to services and
> applications, improving the Bitcoin ecosystem as a whole.
>
> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>
> Demo website :
> http://bitid-demo.herokuapp.com/
>
> Classical password authentication is an insecure process that could be
> solved with public key cryptography. The problem is that it theoretically
> offloads a lot of complexity and responsibility on the user. Managing
> private keys securely is complex. However this complexity is already being
> addressed in the Bitcoin ecosystem. So doing public key authentication is
> practically a free lunch to bitcoiners.
>
> I've formatted the protocol description as a BIP because this is the only
> way to have all major wallets implementing it, and because it completely
> fits in my opinion the BIP "process" category.
>
> Please read it and let me know your thoughts and comments so we can
> improve on this draft.
>
> Eric Larcheveque
> elarch@gmail.com
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3029 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 4011 bytes --]

What I'm trying to achieve, is to have a very simple way of authenticating
yourself with one Bitcoin address from your wallet.
For most of the people using Bitcoin, their wallet is on their phone.

The UX is clear and simple :
1. click on "connect with Bitcoin" (the audience is normal people)
2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
3. accept the authentication request (same style than OpenID or Facebook
connect)
4. user is autologged and identified by the chosen Bitcoin public address

It makes sense only if major wallets are supporting the protocol. If you
need to install a plugin or download a third party software, no one will do
it.
I see only benefits for the entire ecosystem, and if I'm working on such a
proposition it is because I really need this feature.

Of course, it can be done without a BIP, I just need to convince wallet
developpers one by one to implement the feature.
But I thought it was much better to start the "official" way, so all wallet
could easily find and implement the same authentication mechanism.

>  Bitcoin and website authentication are unrelated problems

I respectfully disagree. Many services require your Bitcoin address, and to
do that they artificially request an email/password to store it.
This is not about authentication as an identity (as "I'm Eric
Larcheveque"), but as in "I'm proving to you that I control this address".

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.

Eric



On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike@plan99.net> wrote:

> This comes up every few months. I think the problem you are trying to
> solve is already solved by SSL client certificates, and if you want to help
> make them more widespread the programs you need to upgrade are web browsers
> and not Bitcoin wallets. There are certainly bits of infrastructure you
> could reuse here and there, like perhaps a TREZOR with a custom firmware
> extension for really advanced/keen users, but overall Bitcoin and website
> authentication are unrelated problems.
>
>
> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch@gmail.com> wrote:
>
>> Hello,
>>
>> I've written a draft BIP description of an authentication protocol based
>> on Bitcoin public address.
>>
>> By authentication we mean to prove to a service/application that we
>> control a specific Bitcoin address by signing a challenge, and that all
>> related data and settings may securely be linked to our session.
>>
>> The aim is to greatly facilitate sign ups and logins to services and
>> applications, improving the Bitcoin ecosystem as a whole.
>>
>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>>
>> Demo website :
>> http://bitid-demo.herokuapp.com/
>>
>> Classical password authentication is an insecure process that could be
>> solved with public key cryptography. The problem is that it theoretically
>> offloads a lot of complexity and responsibility on the user. Managing
>> private keys securely is complex. However this complexity is already being
>> addressed in the Bitcoin ecosystem. So doing public key authentication is
>> practically a free lunch to bitcoiners.
>>
>> I've formatted the protocol description as a BIP because this is the only
>> way to have all major wallets implementing it, and because it completely
>> fits in my opinion the BIP "process" category.
>>
>> Please read it and let me know your thoughts and comments so we can
>> improve on this draft.
>>
>> Eric Larcheveque
>> elarch@gmail.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 6005 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 5188 bytes --]

Using a bitcoin address repeatedly is something we're trying to move away
from.

And using a bitcoin address as a persistent identity key feels like the
wrong direction to me.

Better to use something like client certificates, the FIDO alliance's
(new!) specs:
  http://fidoalliance.org/specifications/download

... or Steve Gibson's proposed SQRL system:
  https://www.grc.com/sqrl/sqrl.htm

If one of those systems gets critical mass and actually starts being
successful, then I think it would make sense to specify a standard way of
using a HD wallet's deterministic seed to derive a key used for the FIDO or
SQRL systems.




On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchevêque <elarch@gmail.com> wrote:

> What I'm trying to achieve, is to have a very simple way of authenticating
> yourself with one Bitcoin address from your wallet.
> For most of the people using Bitcoin, their wallet is on their phone.
>
> The UX is clear and simple :
> 1. click on "connect with Bitcoin" (the audience is normal people)
> 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
> 3. accept the authentication request (same style than OpenID or Facebook
> connect)
> 4. user is autologged and identified by the chosen Bitcoin public address
>
> It makes sense only if major wallets are supporting the protocol. If you
> need to install a plugin or download a third party software, no one will do
> it.
> I see only benefits for the entire ecosystem, and if I'm working on such a
> proposition it is because I really need this feature.
>
> Of course, it can be done without a BIP, I just need to convince wallet
> developpers one by one to implement the feature.
> But I thought it was much better to start the "official" way, so all
> wallet could easily find and implement the same authentication mechanism.
>
> >  Bitcoin and website authentication are unrelated problems
>
> I respectfully disagree. Many services require your Bitcoin address, and
> to do that they artificially request an email/password to store it.
> This is not about authentication as an identity (as "I'm Eric
> Larcheveque"), but as in "I'm proving to you that I control this address".
>
> 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.
>
> Eric
>
>
>
> On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> This comes up every few months. I think the problem you are trying to
>> solve is already solved by SSL client certificates, and if you want to help
>> make them more widespread the programs you need to upgrade are web browsers
>> and not Bitcoin wallets. There are certainly bits of infrastructure you
>> could reuse here and there, like perhaps a TREZOR with a custom firmware
>> extension for really advanced/keen users, but overall Bitcoin and website
>> authentication are unrelated problems.
>>
>>
>> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch@gmail.com>wrote:
>>
>>> Hello,
>>>
>>> I've written a draft BIP description of an authentication protocol based
>>> on Bitcoin public address.
>>>
>>> By authentication we mean to prove to a service/application that we
>>> control a specific Bitcoin address by signing a challenge, and that all
>>> related data and settings may securely be linked to our session.
>>>
>>> The aim is to greatly facilitate sign ups and logins to services and
>>> applications, improving the Bitcoin ecosystem as a whole.
>>>
>>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>>>
>>> Demo website :
>>> http://bitid-demo.herokuapp.com/
>>>
>>> Classical password authentication is an insecure process that could be
>>> solved with public key cryptography. The problem is that it theoretically
>>> offloads a lot of complexity and responsibility on the user. Managing
>>> private keys securely is complex. However this complexity is already being
>>> addressed in the Bitcoin ecosystem. So doing public key authentication is
>>> practically a free lunch to bitcoiners.
>>>
>>> I've formatted the protocol description as a BIP because this is the
>>> only way to have all major wallets implementing it, and because it
>>> completely fits in my opinion the BIP "process" category.
>>>
>>> Please read it and let me know your thoughts and comments so we can
>>> improve on this draft.
>>>
>>> Eric Larcheveque
>>> elarch@gmail.com
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 7960 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

On Fri, Apr 4, 2014 at 3:22 PM, Eric Larchevêque <elarch@gmail.com> wrote:

> I see only benefits for the entire ecosystem, and if I'm working on such a
> proposition it is because I really need this feature.
>

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.


> 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?

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!

[-- Attachment #2: Type: text/html, Size: 2644 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 5878 bytes --]

> Using a bitcoin address repeatedly is something we're trying to move away
from.

This is indeed a flaw of the proposed protocol. However it really depends
in the end of the usage : you could use an auth just once, to redeem a good
you paid, or multiple times if this makes a sense (mining pool app for
instance).

> And using a bitcoin address as a persistent identity key feels like the
wrong direction to me.

What would be really the difference between artificially create a
certificate for identity and selecting one address for identity?

> Better to use something like client certificates, the FIDO alliance's
(new!) specs:
>   http://fidoalliance.org/specifications/download
> ... or Steve Gibson's proposed SQRL system:
>   https://www.grc.com/sqrl/sqrl.htm

The proposal is nothing more than sqrl scoped to Bitcoin keys.

> If one of those systems gets critical mass and actually starts being
successful, then I think it would make sense to specify a standard way of
using a HD wallet's deterministic seed to derive a key used for the FIDO or
SQRL systems.

This could be a very interesting approach. But I think the system which
would get critical mass is the one which would be implemented into major
Bitcoin wallets.

Why adding another app or software when you already have all you need?

>
>
>
>
> On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchevêque <elarch@gmail.com> wrote:
>>
>> What I'm trying to achieve, is to have a very simple way of
authenticating yourself with one Bitcoin address from your wallet.
>> For most of the people using Bitcoin, their wallet is on their phone.
>>
>> The UX is clear and simple :
>> 1. click on "connect with Bitcoin" (the audience is normal people)
>> 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
>> 3. accept the authentication request (same style than OpenID or Facebook
connect)
>> 4. user is autologged and identified by the chosen Bitcoin public address
>>
>> It makes sense only if major wallets are supporting the protocol. If you
need to install a plugin or download a third party software, no one will do
it.
>> I see only benefits for the entire ecosystem, and if I'm working on such
a proposition it is because I really need this feature.
>>
>> Of course, it can be done without a BIP, I just need to convince wallet
developpers one by one to implement the feature.
>> But I thought it was much better to start the "official" way, so all
wallet could easily find and implement the same authentication mechanism.
>>
>> >  Bitcoin and website authentication are unrelated problems
>>
>> I respectfully disagree. Many services require your Bitcoin address, and
to do that they artificially request an email/password to store it.
>> This is not about authentication as an identity (as "I'm Eric
Larcheveque"), but as in "I'm proving to you that I control this address".
>>
>> 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.
>>
>> Eric
>>
>>
>>
>> On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike@plan99.net> wrote:
>>>
>>> This comes up every few months. I think the problem you are trying to
solve is already solved by SSL client certificates, and if you want to help
make them more widespread the programs you need to upgrade are web browsers
and not Bitcoin wallets. There are certainly bits of infrastructure you
could reuse here and there, like perhaps a TREZOR with a custom firmware
extension for really advanced/keen users, but overall Bitcoin and website
authentication are unrelated problems.
>>>
>>>
>>> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch@gmail.com>
wrote:
>>>>
>>>> Hello,
>>>>
>>>> I've written a draft BIP description of an authentication protocol
based on Bitcoin public address.
>>>>
>>>> By authentication we mean to prove to a service/application that we
control a specific Bitcoin address by signing a challenge, and that all
related data and settings may securely be linked to our session.
>>>>
>>>> The aim is to greatly facilitate sign ups and logins to services and
applications, improving the Bitcoin ecosystem as a whole.
>>>>
>>>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>>>>
>>>> Demo website :
>>>> http://bitid-demo.herokuapp.com/
>>>>
>>>> Classical password authentication is an insecure process that could be
solved with public key cryptography. The problem is that it theoretically
offloads a lot of complexity and responsibility on the user. Managing
private keys securely is complex. However this complexity is already being
addressed in the Bitcoin ecosystem. So doing public key authentication is
practically a free lunch to bitcoiners.
>>>>
>>>> I've formatted the protocol description as a BIP because this is the
only way to have all major wallets implementing it, and because it
completely fits in my opinion the BIP "process" category.
>>>>
>>>> Please read it and let me know your thoughts and comments so we can
improve on this draft.
>>>>
>>>> Eric Larcheveque
>>>> elarch@gmail.com
>>>>
>>>>
>>>>
------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>
>>
>>
------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> --
> Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 7876 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Jeff Garzik]

On Fri, Apr 4, 2014 at 9:43 AM, Mike Hearn <mike@plan99.net> wrote:
> 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.

This is precisely why SINs use a different version byte from bitcoin
addresses.  There should never be any confusion between money/payments
and identity.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

>
> 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?
>

Oh, if these seem too abstract, also consider bitbanks. In an ideal world
nobody would outsource running of their Bitcoin wallet, but sadly people
do, so then they don't control the private keys at all.

The goal of writing a BIP seems to be to get lots of different wallet
authors to write lots of code for you - but I *am* a wallet author, and I
don't think that's the right way to get traction with a new scheme. For
instance the TREZOR guys would have to support your new protocol otherwise
if I paid my hotel bill with my TREZOR I couldn't open the door when I got
there! But they probably have better things to be doing right now.

The key difference between just generating a client certificate and using a
Bitcoin address is that the client certificate is something that is used
*specifically* for identification. It leaves no trace in the block chain,
so no weird privacy issues, it doesn't matter how you manage your wallet,
and you don't have to persuade lots of people to support your idea because
it was already done >10 years ago and basically every browser/web server
supports it.

Some reasons client certs aren't more widely used boil down to:

   1. People like passwords. In particular they like forgetting them and
   then having friendly people assist them to get it back. Client certs can
   support this use case, but only if apps are checking the identity in them
   and not the key.
   2. The UI for managing client certs in browsers is pretty horrible.
   There's little incentive to improve it because of (1).
   3. Cross-device sync doesn't work very well. Apple are starting to
   tackle this with their iCloud Keychain Sync service but then of course,
   Apple has all your keys and you may well just sign in to things with your
   Apple account (if it were to be supported). Cross-device sync where the
   server *doesn't* get your keys is supported by Chrome for passwords, but
   not client certs, because (1)

None of the above issues have any obvious fix lurking within Bitcoin.

[-- Attachment #2: Type: text/html, Size: 2679 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 2973 bytes --]

>
> The goal of writing a BIP seems to be to get lots of different wallet
> authors to write lots of code for you - but I *am* a wallet author, and I
> don't think that's the right way to get traction with a new scheme.
>

I started without a BIP and the feedback I got is that I should to a BIP.
We cannot write all the code for all the wallets ; this is after all a
communauty project.
However we have and we will propose bounties for each wallet to support
natively the protocol.


> For instance the TREZOR guys would have to support your new protocol
> otherwise if I paid my hotel bill with my TREZOR I couldn't open the door
> when I got there! But they probably have better things to be doing right
> now.
>

Yes you are right. But if the concept of authenticating yourself gets
traction, they will probably do it.


> The key difference between just generating a client certificate and using
> a Bitcoin address is that the client certificate is something that is used
> *specifically* for identification. It leaves no trace in the block chain,
> so no weird privacy issues, it doesn't matter how you manage your wallet,
> and you don't have to persuade lots of people to support your idea because
> it was already done >10 years ago and basically every browser/web server
> supports it.
>

My view on this is mainly about the UX and the fact everyone in Bitcoinland
has a wallet.
It's a approach leveraging this fact, with the possibility to build
interesting apps combining address auth and the blockchain.

I understand the problems related to multisig, contracts etc,
There is no such thing as a from address in a transaction, however many
services still take first tx as the return address.
People will always find way of building and doing stuff (cf the message in
the blockchain debate).


> Some reasons client certs aren't more widely used boil down to:
>
>    1. People like passwords. In particular they like forgetting them and
>    then having friendly people assist them to get it back. Client certs can
>    support this use case, but only if apps are checking the identity in them
>    and not the key.
>    2. The UI for managing client certs in browsers is pretty horrible.
>    There's little incentive to improve it because of (1).
>    3. Cross-device sync doesn't work very well. Apple are starting to
>    tackle this with their iCloud Keychain Sync service but then of course,
>    Apple has all your keys and you may well just sign in to things with your
>    Apple account (if it were to be supported). Cross-device sync where the
>    server *doesn't* get your keys is supported by Chrome for passwords,
>    but not client certs, because (1)
>
> None of the above issues have any obvious fix lurking within Bitcoin.
>

There is also the benefit of revocation with certificate and central
authority.

But, again, you already have a wallet and a Bitcoin address.
So if you add a simple auth protocol, people will use it at no cost.

Eric

[-- Attachment #2: Type: text/html, Size: 4331 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

>
> My view on this is mainly about the UX and the fact everyone in
> Bitcoinland has a wallet.
>

Well, yes, but we also have browsers too :)

I don't want to suggest the problem is unimportant - I'd love it if the
world could move beyond passwords. But I have many scars from my time in
the Google account swamps. We had a big team, lots of resources and even
just getting people to use their phone as a second factor - *the simplest
second factor possible* - was a huge uphill battle that most users just
didn't care about. People like passwords. If you can find a way to make
something that's better than a password but just as convenient, fantastic!
But I don't think Bitcoin addresses are such a thing.

[-- Attachment #2: Type: text/html, Size: 1100 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn <mike@plan99.net> wrote:

>  My view on this is mainly about the UX and the fact everyone in
>> Bitcoinland has a wallet.
>>
>
> Well, yes, but we also have browsers too :)
>
>
Yes, but no one will ever install a plug in.
And all will update their wallets with the last version, including the auth
protocol.


> I don't want to suggest the problem is unimportant - I'd love it if the
> world could move beyond passwords. But I have many scars from my time in
> the Google account swamps. We had a big team, lots of resources and even
> just getting people to use their phone as a second factor - *the simplest
> second factor possible* - was a huge uphill battle that most users just
> didn't care about. People like passwords. If you can find a way to make
> something that's better than a password but just as convenient, fantastic!
> But I don't think Bitcoin addresses are such a thing.
>

I perfectly understand all the objections, and they are very good points.

I have at least two wallets enthousiastic about the project so the protocol
will be implemented and it will give some room to experiment.
The BIP came from the idea we should formalize the standard so all wallets
could participate, and it felt more logical to come forward with it.

Maybe a better strategy would be to start "privately" with a few wallets
and services using the protocol, and to come back to the BIP there is
usability and traction.

Eric

[-- Attachment #2: Type: text/html, Size: 2752 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[slush]

[-- Attachment #1: Type: text/plain, Size: 4027 bytes --]

I'm cracking my head for many months with the idea of using TREZOR for web
auth purposes. Unfortunately I'm far from any usable solution yet.

My main comments to your BIP: Don't use bitcoin addresses directly and
don't encourage services to use this "login" for financial purposes. Mike
is right, mixing authentication and financial services is wrong. Use some
function to generate other private/public key from bitcoin's seed/private
key to not leak bitcoin-related data to website.

Cheers,
Marek


On Fri, Apr 4, 2014 at 4:42 PM, Eric Larchevêque <elarch@gmail.com> wrote:

>  The goal of writing a BIP seems to be to get lots of different wallet
>> authors to write lots of code for you - but I *am* a wallet author, and
>> I don't think that's the right way to get traction with a new scheme.
>>
>
> I started without a BIP and the feedback I got is that I should to a BIP.
> We cannot write all the code for all the wallets ; this is after all a
> communauty project.
> However we have and we will propose bounties for each wallet to support
> natively the protocol.
>
>
>> For instance the TREZOR guys would have to support your new protocol
>> otherwise if I paid my hotel bill with my TREZOR I couldn't open the door
>> when I got there! But they probably have better things to be doing right
>> now.
>>
>
> Yes you are right. But if the concept of authenticating yourself gets
> traction, they will probably do it.
>
>
>> The key difference between just generating a client certificate and using
>> a Bitcoin address is that the client certificate is something that is used
>> *specifically* for identification. It leaves no trace in the block
>> chain, so no weird privacy issues, it doesn't matter how you manage your
>> wallet, and you don't have to persuade lots of people to support your idea
>> because it was already done >10 years ago and basically every browser/web
>> server supports it.
>>
>
> My view on this is mainly about the UX and the fact everyone in
> Bitcoinland has a wallet.
> It's a approach leveraging this fact, with the possibility to build
> interesting apps combining address auth and the blockchain.
>
> I understand the problems related to multisig, contracts etc,
> There is no such thing as a from address in a transaction, however many
> services still take first tx as the return address.
> People will always find way of building and doing stuff (cf the message in
> the blockchain debate).
>
>
>> Some reasons client certs aren't more widely used boil down to:
>>
>>    1. People like passwords. In particular they like forgetting them and
>>    then having friendly people assist them to get it back. Client certs can
>>    support this use case, but only if apps are checking the identity in them
>>    and not the key.
>>    2. The UI for managing client certs in browsers is pretty horrible.
>>    There's little incentive to improve it because of (1).
>>    3. Cross-device sync doesn't work very well. Apple are starting to
>>    tackle this with their iCloud Keychain Sync service but then of course,
>>    Apple has all your keys and you may well just sign in to things with your
>>    Apple account (if it were to be supported). Cross-device sync where the
>>    server *doesn't* get your keys is supported by Chrome for passwords,
>>    but not client certs, because (1)
>>
>> None of the above issues have any obvious fix lurking within Bitcoin.
>>
>
> There is also the benefit of revocation with certificate and central
> authority.
>
> But, again, you already have a wallet and a Bitcoin address.
> So if you add a simple auth protocol, people will use it at no cost.
>
> Eric
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6011 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[slush]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn <mike@plan99.net> wrote:
>
> I don't want to suggest the problem is unimportant - I'd love it if the
> world could move beyond passwords. But I have many scars from my time in
> the Google account swamps. We had a big team, lots of resources and even
> just getting people to use their phone as a second factor - *the simplest
> second factor possible* - was a huge uphill battle that most users just
> didn't care about. People like passwords. If you can find a way to make
> something that's better than a password but just as convenient, fantastic!
> But I don't think Bitcoin addresses are such a thing.
>
>
With all respect to your experience, I think you're wrong, for one reason.

2fa auth doesn't *remove* the need of password. It actually *adds* yet
another layer, which complicates stuff for average user. Common user, which
is not paranoid enough (like me) simply don't think he has anything to
hide, so they simply don't see why they should *complicate* their live with
2fa, backing up their phone etc.

In the oposite, authentication based on bitcoin wallet could make the
process much easier and remove the need of passwords at all, because people
*already* care about safe storage of their coins.

Marek

[-- Attachment #2: Type: text/html, Size: 1841 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

>
>
> 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

[-- Attachment #2: Type: text/html, Size: 4596 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Fri, Apr 4, 2014 at 4:56 PM, slush <slush@centrum.cz> wrote:

> I'm cracking my head for many months with the idea of using TREZOR for web
> auth purposes. Unfortunately I'm far from any usable solution yet.
>
> My main comments to your BIP: Don't use bitcoin addresses directly and
> don't encourage services to use this "login" for financial purposes. Mike
> is right, mixing authentication and financial services is wrong. Use some
> function to generate other private/public key from bitcoin's seed/private
> key to not leak bitcoin-related data to website.
>
>
I'm probably very naive, but the fact that the authentication key is your
Bitcoin address was for me a great feature :)
What are the risks associated of id yourself with a bitcoin address you
plan to use on the website for transaction ?

I mean, what is the difference between doing that, and id with a login/pass
and add your bitcoin address in a settings field ? (knowing you could
always find a mechanism to transfer the account to another bitcoin address
if needed)

Eric

[-- Attachment #2: Type: text/html, Size: 1583 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[slush]

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchevêque <elarch@gmail.com> wrote:

> On Fri, Apr 4, 2014 at 4:56 PM, slush <slush@centrum.cz> wrote:
>
>> I'm cracking my head for many months with the idea of using TREZOR for
>> web auth purposes. Unfortunately I'm far from any usable solution yet.
>>
>> My main comments to your BIP: Don't use bitcoin addresses directly and
>> don't encourage services to use this "login" for financial purposes. Mike
>> is right, mixing authentication and financial services is wrong. Use some
>> function to generate other private/public key from bitcoin's seed/private
>> key to not leak bitcoin-related data to website.
>>
>>
> I'm probably very naive, but the fact that the authentication key is your
> Bitcoin address was for me a great feature :)
> What are the risks associated of id yourself with a bitcoin address you
> plan to use on the website for transaction ?
>
>
Ideally you should not reuse the address, so the website will need more
addresses or bip32 xpub anyway.

By using wallet address and accidentally using such address in some
transaction, you may be leaking your identity with with other business -
think about Silkroad (sorry Mike :-).

 By using derived key, you can be sure your identity won't be linked with
any other activity on the internet.

I mean, what is the difference between doing that, and id with a login/pass
> and add your bitcoin address in a settings field ? (knowing you could
> always find a mechanism to transfer the account to another bitcoin address
> if needed)
>
> *) You can change address in settings field. It's not so easy when address
== your identity.
*)  There's plenty of websites which do need authentication but don't need
to know your bank account / bitcoin address at all. Facebook, Gmail,
Twitter ...

Ideally, the user should not care about "what address do I use for this
service", because in the future user should not care about addresses at all
(handling of private keys is already eliminated by bip32, handling of raw
addresses may be eliminated soon by bip70 or similar solutions).

I can imagine that the private/public data will be derived automatically
from some secret master key (ideally derived from bip32 seed, which is
already secured well by the user) and the URL of the service.

Marek

[-- Attachment #2: Type: text/html, Size: 3591 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins then
we have a problem :) But regardless, actually like I said, you don't need a
plugin. Browsers do it all already. With the <keygen> tag they even create
a private key and upload the public part to be signed for you, it's
seamless for the user. I wanted to give you a link to a demo site, but I
can't find it anymore :(

So there's not even a need for people to upgrade anything! It's all there,
already, for everyone.

If you were to make some upgrades, then you'd want to focus on key
management, which indeed is something the Bitcoin world is trying hard to
solve.  But that's a small subcomponent.  Making a modified version of
Chrome or Firefox that can take their key from a BIP32 hierarchy or
12-words scheme is certainly possible, but then you could still reuse all
the rest of it.

Something I'd really like to see is TREZOR supporting a simple
request/response protocol that a server can trigger, via the USB plugin,
that would allow a server to display some arbitrary text and get a
confirmation. Slush and I talked about it before. There are a LOT of places
that don't care about Bitcoin but do need some kind of safe second factor
auth where users know what they are confirming (e.g. at Google!). If TREZOR
could be used for these things too, that'd increase demand and help push
down prices for Bitcoin users.



On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchevêque <elarch@gmail.com> wrote:

> On Fri, Apr 4, 2014 at 4:56 PM, slush <slush@centrum.cz> wrote:
>
>> I'm cracking my head for many months with the idea of using TREZOR for
>> web auth purposes. Unfortunately I'm far from any usable solution yet.
>>
>> My main comments to your BIP: Don't use bitcoin addresses directly and
>> don't encourage services to use this "login" for financial purposes. Mike
>> is right, mixing authentication and financial services is wrong. Use some
>> function to generate other private/public key from bitcoin's seed/private
>> key to not leak bitcoin-related data to website.
>>
>>
> I'm probably very naive, but the fact that the authentication key is your
> Bitcoin address was for me a great feature :)
> What are the risks associated of id yourself with a bitcoin address you
> plan to use on the website for transaction ?
>
> I mean, what is the difference between doing that, and id with a
> login/pass and add your bitcoin address in a settings field ? (knowing you
> could always find a mechanism to transfer the account to another bitcoin
> address if needed)
>
> Eric
>
>

[-- Attachment #2: Type: text/html, Size: 3607 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[slush]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn <mike@plan99.net> wrote:

> Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins
> then we have a problem :) But regardless, actually like I said, you don't
> need a plugin.
>

I see the plugin as a temporary solution and we'll eliminate the plugin
once there'll be any way to talk to USB HID directly from browser (which is
not possible yet, but there's some effort already).

Marek

[-- Attachment #2: Type: text/html, Size: 821 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

>
> Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins
> then we have a problem :) But regardless, actually like I said, you don't
> need a plugin. Browsers do it all already. With the <keygen> tag they even
> create a private key and upload the public part to be signed for you, it's
> seamless for the user. I wanted to give you a link to a demo site, but I
> can't find it anymore :(
>
>
If you buy a TREZOR you will of course install the plugin :)

What I mean is that normal people are lazy : if the solution is already in
their hand they will use it, if they need to install/configure something,
they won't do it.

I'm not trying to propose a solution to solve the auth on the web, but to
ease the sign up / login on the Bitcoin ecosystem websites and apps.
More sign ups to new services (whatever the services) = more usage =
expanding ecosystem = more global value to Bitcoin

Wallets are a key element of the equation because :
- everyone has one (desktop or mobile)
- everyone (in theory) has already taken all steps to backup and secure
their keys
- id yourself with a Bitcoin address often makes sense on a Bitcoin related
service

Eric

[-- Attachment #2: Type: text/html, Size: 1591 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Troy Benjegerdes]

I have to play dissenter here again..

Using a bitcoin address as a persistent identity key is the first real-world
use of Bitcoin that I can imagine will make it a 'killer app' that everyone
and their grandma will want to use.

If you think 'certificates' are a good solution, then there is some way in
which we have dramatically divergent goals.

I like distributed, decentralized systems in which anyone can download the 
code and be free to participate in the things they want to securely and 
reliably.

As soon as I hear 'certificate', I see a system in which one must pay at toll
to speak, and which puts the listeners at risk because a certificate issuer
is such a high-value target for malicious attack.

Self-signed certificates are great for techno-wizards, but grandma has no
idea if the self-signed cert was signed by her grandson, or by the hacker
trying to redirect her social security check.

"This is your bitcoin address, it's your money AND your key to log into 
your bank website securely, so don't lose it. If you want our address
protection insurance service that will be $20 per month, and if you do lose
it, we'll fix it. If you keep losing it, then your rates will go up, just 
like car insurance if you keep crashing"


On Fri, Apr 04, 2014 at 09:32:40AM -0400, Gavin Andresen wrote:
> Using a bitcoin address repeatedly is something we're trying to move away
> from.
> 
> And using a bitcoin address as a persistent identity key feels like the
> wrong direction to me.
> 
> Better to use something like client certificates, the FIDO alliance's
> (new!) specs:
>   http://fidoalliance.org/specifications/download
> 
> ... or Steve Gibson's proposed SQRL system:
>   https://www.grc.com/sqrl/sqrl.htm
> 
> If one of those systems gets critical mass and actually starts being
> successful, then I think it would make sense to specify a standard way of
> using a HD wallet's deterministic seed to derive a key used for the FIDO or
> SQRL systems.
> 
> 
> 
> 
> On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchevêque <elarch@gmail.com> wrote:
> 
> > What I'm trying to achieve, is to have a very simple way of authenticating
> > yourself with one Bitcoin address from your wallet.
> > For most of the people using Bitcoin, their wallet is on their phone.
> >
> > The UX is clear and simple :
> > 1. click on "connect with Bitcoin" (the audience is normal people)
> > 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
> > 3. accept the authentication request (same style than OpenID or Facebook
> > connect)
> > 4. user is autologged and identified by the chosen Bitcoin public address
> >
> > It makes sense only if major wallets are supporting the protocol. If you
> > need to install a plugin or download a third party software, no one will do
> > it.
> > I see only benefits for the entire ecosystem, and if I'm working on such a
> > proposition it is because I really need this feature.
> >
> > Of course, it can be done without a BIP, I just need to convince wallet
> > developpers one by one to implement the feature.
> > But I thought it was much better to start the "official" way, so all
> > wallet could easily find and implement the same authentication mechanism.
> >
> > >  Bitcoin and website authentication are unrelated problems
> >
> > I respectfully disagree. Many services require your Bitcoin address, and
> > to do that they artificially request an email/password to store it.
> > This is not about authentication as an identity (as "I'm Eric
> > Larcheveque"), but as in "I'm proving to you that I control this address".
> >
> > 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.
> >
> > Eric
> >
> >
> >
> > On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike@plan99.net> wrote:
> >
> >> This comes up every few months. I think the problem you are trying to
> >> solve is already solved by SSL client certificates, and if you want to help
> >> make them more widespread the programs you need to upgrade are web browsers
> >> and not Bitcoin wallets. There are certainly bits of infrastructure you
> >> could reuse here and there, like perhaps a TREZOR with a custom firmware
> >> extension for really advanced/keen users, but overall Bitcoin and website
> >> authentication are unrelated problems.
> >>
> >>
> >> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch@gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> I've written a draft BIP description of an authentication protocol based
> >>> on Bitcoin public address.
> >>>
> >>> By authentication we mean to prove to a service/application that we
> >>> control a specific Bitcoin address by signing a challenge, and that all
> >>> related data and settings may securely be linked to our session.
> >>>
> >>> The aim is to greatly facilitate sign ups and logins to services and
> >>> applications, improving the Bitcoin ecosystem as a whole.
> >>>
> >>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
> >>>
> >>> Demo website :
> >>> http://bitid-demo.herokuapp.com/
> >>>
> >>> Classical password authentication is an insecure process that could be
> >>> solved with public key cryptography. The problem is that it theoretically
> >>> offloads a lot of complexity and responsibility on the user. Managing
> >>> private keys securely is complex. However this complexity is already being
> >>> addressed in the Bitcoin ecosystem. So doing public key authentication is
> >>> practically a free lunch to bitcoiners.
> >>>
> >>> I've formatted the protocol description as a BIP because this is the
> >>> only way to have all major wallets implementing it, and because it
> >>> completely fits in my opinion the BIP "process" category.
> >>>
> >>> Please read it and let me know your thoughts and comments so we can
> >>> improve on this draft.
> >>>
> >>> Eric Larcheveque
> >>> elarch@gmail.com
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>>
> >>
> >
> >
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> 
> 
> -- 
> --
> Gavin Andresen

> ------------------------------------------------------------------------------

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Ricardo Filipe]

2014-04-07 21:08 GMT+01:00 Troy Benjegerdes <hozer@hozed.org>:
> I have to play dissenter here again..
>
> Using a bitcoin address as a persistent identity key is the first real-world
> use of Bitcoin that I can imagine will make it a 'killer app' that everyone
> and their grandma will want to use.
>

I am of the same opinion, although i understand Gavin's point. Would
the multisig seed work for this purpose?
I have been toying with this idea and I think that for this BIP to
make sense it would require a "root" key as your login. Then if you
need to make transfers the system would request you to create and
associate a new key to your account for each purchase (signing the new
key with the root one for example).

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Martindale]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

This is toying with the economics of cryptofinance in a way that needs to
be understood before being put under consideration for implementation in
Bitcoin.  This is an opportunity for an altcoin to explore the implications
of these proposals prior to changing the properties of an already
precarious system.

Eric Martindale
Developer Evangelist, BitPay
+1 (919) 374-2020
On Apr 7, 2014 2:55 PM, "Ricardo Filipe" <ricardojdfilipe@gmail.com> wrote:

> 2014-04-07 21:08 GMT+01:00 Troy Benjegerdes <hozer@hozed.org>:
> > I have to play dissenter here again..
> >
> > Using a bitcoin address as a persistent identity key is the first
> real-world
> > use of Bitcoin that I can imagine will make it a 'killer app' that
> everyone
> > and their grandma will want to use.
> >
>
> I am of the same opinion, although i understand Gavin's point. Would
> the multisig seed work for this purpose?
> I have been toying with this idea and I think that for this BIP to
> make sense it would require a "root" key as your login. Then if you
> need to make transfers the system would request you to create and
> associate a new key to your account for each purchase (signing the new
> key with the root one for example).
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2380 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Jeff Garzik]

On Fri, Apr 4, 2014 at 10:56 AM, Eric Larchevêque <elarch@gmail.com> wrote:
> Yes, but no one will ever install a plug in.

This is quite true.  I said the same about KryptoKit.  Incredibly cool
to do bitcoin + PGP in client...  but ultimately plugins reach 0.01%
of the user population.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

I'd be careful with swift generalisations. It depends a lot on the value of
your product. I didn't have any hangups about installing a plugin to use my
TREZOR:  compared to the cost and effort involved with the rest of it,
installing a plugin was by far the easiest part.

Another example. Back in 2005 people also used to say that nobody wanted to
download apps anymore. Then I started working on Google Earth, which got
~400 million installs. Obviously, that was cool enough that people were
willing to download and install a giant hulking ugly Qt app :)

[-- Attachment #2: Type: text/html, Size: 684 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Jeff Garzik]

On Tue, Apr 8, 2014 at 4:13 AM, Mike Hearn <mike@plan99.net> wrote:
> I'd be careful with swift generalisations. It depends a lot on the value of
> your product. I didn't have any hangups about installing a plugin to use my

-You- are irrelevant, as am I.  We don't mind such things.

But based on personal observations as well as Mozilla and other
browser data, the user populace in general does not install plugins.
Flash is the LONE exception to that ironclad general rule.

PS. Google Earth is not a plugin :)

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Jan Møller]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

The reason why client side certificates have never gained traction because
it is a pain to safely store/backup secrets.
In bitcoinland we are forced to solve the problem of safely storing
secrets, and over the years we have come up with software and hardware
solutions to make this safer and easier to manage for ordinary people.
Solving this is paramount to the success of Bitcoin, and nobody has solved
it before on a grand scale.

I see no reason for forcing end users to use two different mechanisms for
safely managing secrets.

I agree that using a bitcoin address for authentication purposes might be
confusing and potentially linking your funds with your identity. So I am
all for using something else than bitcoin addresses and bitcoin private
keys.

With bip32 we have finally agreed on a mechanism for generating a hierarchy
of bitcoin private keys from a master seed. A similar approach can be used
for generating a parallel hierarchy for authentication purposes.

- Jan

[-- Attachment #2: Type: text/html, Size: 1174 bytes --]

Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

[Eric Larchevêque]

[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]

The development of BitID has had some progress, and we have now a working
wallet prototype based on Android Bitcoin Wallet (bitoinj).
The user flow is quite nice and if you are curious here is a short video
demonstration :
https://www.youtube.com/watch?v=3eepEWTnRTc

By default, each new first auth request will create and save a new address
(SQRL like). It could be based on BIP32, but this works also without.
This requires to add metadata to addresses, as described here :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md

It open also the fields for decentralized 2FA as well as "pay as guest"
checkout in conjonction with BIP70 payment request.

Eric



On Tue, Apr 22, 2014 at 8:34 AM, Jan Møller <jan.moller@gmail.com> wrote:

> The reason why client side certificates have never gained traction because
> it is a pain to safely store/backup secrets.
> In bitcoinland we are forced to solve the problem of safely storing
> secrets, and over the years we have come up with software and hardware
> solutions to make this safer and easier to manage for ordinary people.
> Solving this is paramount to the success of Bitcoin, and nobody has solved
> it before on a grand scale.
>
> I see no reason for forcing end users to use two different mechanisms for
> safely managing secrets.
>
> I agree that using a bitcoin address for authentication purposes might be
> confusing and potentially linking your funds with your identity. So I am
> all for using something else than bitcoin addresses and bitcoin private
> keys.
>
> With bip32 we have finally agreed on a mechanism for generating a
> hierarchy of bitcoin private keys from a master seed. A similar approach
> can be used for generating a parallel hierarchy for authentication
> purposes.
>
> - Jan
>
>
>

[-- Attachment #2: Type: text/html, Size: 2628 bytes --]